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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ