linux-kernel - Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

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: <20070616103130.GD32405@brong.net>
Date:	Sat, 16 Jun 2007 20:31:30 +1000
From:	Bron Gondwana <brong@...tmail.fm>
To:	Alexandre Oliva <aoliva@...hat.com>
Cc:	Bron Gondwana <brong@...tmail.fm>, Ingo Molnar <mingo@...e.hu>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Daniel Hazelton <dhazelton@...er.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	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

On Sat, Jun 16, 2007 at 05:22:21AM -0300, Alexandre Oliva wrote:
> On Jun 15, 2007, Bron Gondwana <brong@...tmail.fm> wrote:
> 
> > because it could easily be argued that they linked the BIOS with the
> > Linux kernel
> 
> How so?

(I'm going to refer to Linux as GPLix from here on since this argument
 is more general than a specific GPLed operating system)

Er, they installed it in the same piece of equipment, and the kernel
couldn't function without it in that work.  What's more 'linked' than
that.  It's a vital part of the boot process on that piece of hardware
in exactly the same way that the public-key check is a vital part of
the boot process.

If your printer^wPC isn't doing what you want and you know how to
change it to do what you want but it needs a BIOS patch.  Guess what,
you can't do it - your vendor can.  By using GPLix as part of their
boot process along with their non-GPL BIOS, they're subverting the
freedoms that the user should have in being able to control the entire
boot process.

Right?  Or are you unclear about the fact that there's a big grey area
cutting through this part of usage, and Linus sat down pretty clearly on
one side of it while you're arguing that the goalposts should be "where
I feel that my rights to make changes are being infringed".

While the vendor reserves the ability to change components of the
system (post sale, i.e. a BIOS flash update) and doesn't hand those
same rights on to you, they have partially Tivoised (hoover, kleenex,
you've got nothing on these guys for having your name associated with
a concept) the hardware.  By logical extention of your arguments over
the past few days, this denies them the ability to use any GPLed
software in 'the spirit of the licence' anyware on the machine because
they are denying you rights regarding the instance of the product
they shipped to you that they are retaining for themselves.  The very
freedoms you so vocally claim.

Now, the position I'm seeing here is that the above behaviour (every
single hardware manufacturer that has ever shipped a machine with
pre-installed Linux) violates the spirit of the GPL by the "retaining
exclusive freedoms to modify shipped product" rule, and hence their
BIOS is in the doghouse unless they either:

a) offer full source code access and rights per the holy spirit ghost
   of the GPL; or

b) deny themselves the ability to every offer a patch to said BIOS if
   bugs are found 

Point (b) is also exactly on topic for the discussion of enforcing
legal safety obligations in hardware on a peripheral rather than the
software drivers.  It's requiring that these limitations be placed in
a technically inferior location to hack around a legal "bug".  (A bug
is in the eye of the beholder, please wear glasses while cycling, it's
your own responsibility to protect your eyes)

Er, I think I'm done.  Yes.

Executive summary:

a) by not providing the BIOS source code but retaining the right to 
   change the BIOS the vendor is linking the GPLix kernel and the 
   BIOS (you can't run the kernel without it)

b) legislating intent is fraught.

c) by your arguments, (a) is violating the spirit and (b) is necessary
   to get around that.

Bron.
-
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/