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: <20070614195517.GA4933@elte.hu>
Date:	Thu, 14 Jun 2007 21:55:17 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Alexandre Oliva <aoliva@...hat.com>
Cc:	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

* Alexandre Oliva <aoliva@...hat.com> wrote:

> On Jun 14, 2007, Ingo Molnar <mingo@...e.hu> wrote:
> 
> > I think the proper limit is the boundary where the limit of the 
> > software is - because that's the only sane and globally workable way 
> > to stop the power-hungry.
> 
> But see, I'm not talking about getting permission to hack the 
> hardware.  I'm only talking about getting permission to hack the Free 
> Software in it.
> 
> It's your position that mingles the issues and permits people to use 
> the hardware to deprive users of freedom over the software that 
> they're entitled to have.

where does this false sense of entitlement come from? The hardware maker
ows you nothing but what is written into the GPLv2. Not more, not less.

(In fact, most hardware makers that utilize free software today give
back _substantially more_ to the community than the license requires!
For example they are currently the largest employers of free software
developers - although nothing in the license forces them to do so. Why?
Because the economic rules that the GPLv2 creates are healthy.)

you are not "entitled" to dictate the hardware's design (or any other 
copyrighted work's design), even if the license gives you the power to 
do so. By your argument we'd have to put the following items into the 
license too:

 - free on-site training for free software developers about the 
   hardware's inner workings. (It is justified to teach free software
   the same know-how as in-house engineers of the hardware maker. 
   Without this, users are hindered in their freedom to use and 
   effectively modify (fix) the software.)

 - free access to all the hardware diagnostics tools that the hardware 
   maker has. (Without that it might be impossible to modify the 
   software as efficiently as the hardware maker's own engineers can do 
   it.)

 - free samples of the hardware to be sent to free software developers,
   upon request. (The hardware maker's own engineers have free access to 
   samples. Otherwise free software users might not get the same level 
   of driver support as the hardware maker can achieve.)

 - free access to the hardware manufacturing equipment. (If i wish to 
   modify the free software in a way that requires more RAM than the 
   hardware has, i need access to the manufacturing equipment to produce 
   a new version of the hardware that can run that free software. The 
   hardware maker has this right and flexibility to modify the software, 
   so i should have that same right too.)

see how quickly your argument becomes totally ludicrous, if brought to 
its logical conclusion?

This "right to modify" and "have the same rights as the hardware maker" 
arguments are _totally_ bogus, they were made up after the fact, just 
because quite apparently RMS had a fit over Tivo and started this verbal 
(and legal) vendetta. The FSF is now attempting to rewrite history and 
pretends that this "always was in the GPLv2" and applies this newly 
thought up concept to the GPLv3 in a way that substantially departs from 
the spirit of the GPLv2. Which spirit the GPLv2 explicitly promised to 
uphold in Section 9. Which could make any contrary section of the GPLv3 
unenforceable, when applied to "GPLv2 or later" licensed software.

	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/