linux-kernel - RE: how about mutual compatibility between Linux's GPLv2 and GPLv3?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <MDEHLPKNGKAHNMBLJOLKEELNEOAC.davids@webmaster.com>
Date:	Wed, 27 Jun 2007 20:44:21 -0700
From:	"David Schwartz" <davids@...master.com>
To:	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>
Subject: RE: how about mutual compatibility between Linux's GPLv2 and GPLv3?

> Alexandre Oliva writes:
>
> >> Yes, but in the scenario I proposed, the source code *is* in the
> >> preferred form for making modifications, it just so happens to be
> >> behind a barrier you cannot trespass.  This is not different from
> >> shipping binaries and sources in a CD inside a locked box that you
> >> can't open.  You've received both, but how is the fact that you can't
> >> reach the source code (or the binaries) a violation of the GPL in this
> >> case?
>
> > Behind a barrier is not the preferred form for modification.
>
> Where does it state that there must not be a barrier?  I see it saying
> the source must accompany the binary, under 3a.
>
> > Encrypted with a key you don't have is not the preferred form for
> > modification.
>
> Indeed, but why does it matter?  In a CD is not the preferred form for
> making modifications either.  In fact, in the CD, you can't modify it
> at all.  What's *behind* encryption is the source code, along with the
> binary it accompanies.
>
> >> And, if it's not a violation, what is it that makes the case of
> >> shipping programs in a locked enclosure different from shipping them
> >> in a locked computing device?
>
> > I honestly don't see what relevance this could possibly
> > have. Getting access to the source is a fundamental GPL right.
>
> That's the spirit.  But where does the *letter* of the GPL state it?

I stand by my claim that any obstacle to obtaining and modifying any copy of
the source code (and thus encumbering your ability to use it at all) would
be a violation of both the letter and the spirit of the GPL. (As expressed
in section 3.)

Until someplace you can't actually access the software is customarily used
for software interchange, ...

But I fear that your interpretation of section 7 is mostly correct. This is
a defect in the GPL. At least as I understood it, the intent was to force
distributors to remove any code for which there was a patent claim that
might threaten redistribution. Section 7 fails to do that.

While you are granted rights under copyright, section 7 does not prevent
people from using other laws (so long as they don't impose the restrictions
or agree to them) to hamer your right to redistribute (or for those who
receive a distribution from you to lawfully use the work).

It is quite difficult to actually arrange this. You would need something
like a third party to indemnify your customers without your having to agree
to such indemnification.

DS

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/