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: <ortzta88x3.fsf@oliva.athome.lsd.ic.unicamp.br>
Date:	Thu, 14 Jun 2007 19:31:52 -0300
From:	Alexandre Oliva <aoliva@...hat.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Adrian Bunk <bunk@...sta.de>, Valdis.Kletnieks@...edu,
	Daniel Hazelton <dhazelton@...er.net>,
	Alan Cox <alan@...rguk.ukuu.org.uk>, 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>, mingo@...e.hu
Subject: Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

On Jun 14, 2007, Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> From the very beginning of Linux, even before I chose the GPLv2 as the 
> license, the thing I cared about was that source code be freely available. 

Ok, the MIT license could get you that.  Even public domain could.

> I didn't want money, I didn't want hardware, I just wanted the
> improvements back.

GPL won't get you that.  You want a non-Free Software license.

It will only as long as people play along nicely and perceive the
benefits of cooperation.  But some players don't.

> So given that background, which license do you _think_ I should have 
> chosen?

I can't morally recommend a non-Free Software license.

> And given that background, do you see why the GPLv2 is _still_ better than 
> the GPLv3?

No.  Honestly, I really don't.  Even when I try and look at it from
your perspective, that you described very beautifully in the rest of
the message that I snipped, it's still a mistery to me why you think
permitting Tivoization could possibly be advantageous to your project.

What is it in the anti-Tivoization provision that gets you any less
improvements back?

If anything, I'd think that, by not permitting TiVO to prohibit users
from running modified versions of your code that they don't authorize
themselves, these users would do *more* than TiVO alone ever could,
and if a fraction of them contributes something back, you're way
better off.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@...dhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@...d.ic.unicamp.br, gnu.org}
-
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/