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: <20070615205607.GA4996@elte.hu>
Date:	Fri, 15 Jun 2007 22:56:07 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	David Woodhouse <dwmw2@...radead.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Daniel Hazelton <dhazelton@...er.net>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Alexandre Oliva <aoliva@...hat.com>, Greg KH <greg@...ah.com>,
	debian developer <debiandev@...il.com>, david@...g.hm,
	Tarkan Erimer <tarkan@...one.net.tr>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3


* David Woodhouse <dwmw2@...radead.org> wrote:

> On Fri, 2007-06-15 at 22:20 +0200, Ingo Molnar wrote:
> > That boundary is indeed fuzzy, because life is fuzzy too and the 
> > possibilities are virtually unlimited. But one thing is pretty sure: as 
> > long as some component is merely put alongside of a larger body of work, 
> > even if that component has no life of its own without _some_ larger body 
> > of work, that component is not necessarily part of a collective work and 
> > does not necessarily fall under the GPL.
> 
> Not _necessarily_ a collective work. But not necessarily _not_ a
> collective work either.
> 
> > For driver blobs that are shared between Windows and Linux it would be 
> > hard to argue that they are derived from the Linux kernel. 
> 
> You're back to the 'derived work' thing again, which wasn't relevant.

yeah - i keep interchanging the two because they are so closely related. 
(the same goes for modification and derivation - for software the two 
are quite similar.) Depending on how deeply a distributor integrates a 
binary blob, it might or might not fall under the umbrella of a 
collective work, and the GPL (covering other components of the 
collective work) might or might not apply.

> > Merely linking to some larger body of work does not necessarily mean 
> > that the two become a collective work. No matter how much the FSF is 
> > trying to muddy the waters with the LGPL/GPL.
> 
> I think it's quite clear that the intent of the GPL _is_ to 'muddy the 
> waters', as you put it, and to indicate that bundling stuff together 
> _should_ put the non-derived parts under the GPL too; at least in some 
> circumstances. But still, nothing's true until it's ruled by a court.

but it's not up to the GPL to define that! Whether something is a 
collective work is a matter of law (which operates on the specific facts 
of the case), not a matter of licensing.

and that's where the GPLv3 errs: it arbitrarily attempts to "define" 
some work that can _easily_ be completely separate from the GPL-ed work 
to be under the scope of "source code". Yes, it can do that legally 
because its framers knew what they were doing and they did not attempt 
to implement it as a 'this work belongs to us' thing (which would be 
misuse of copyright) but as a 'you got to pay with your work for our 
permission' - but the external communications about this is all false: 
the pretense that the key in the Tivo case somehow belongs to the GPL-ed 
work is just bogus. A key _can_ belong to a GPL-ed work, but it does not 
automatically so. The GPLv3 automatically and unconditionally moves it 
under the scope of the license and that aspect of the GPLv3 is just 
wrong and moves the license closer to a Microsoft EULA contract than 
towards a pure and just copyright license.

	Ingo
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ