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: <20070617075748.GB6267@elte.hu>
Date:	Sun, 17 Jun 2007 09:57:48 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Alexandre Oliva <aoliva@...hat.com>
Cc:	Scott Preece <sepreece@...il.com>, Rob Landley <rob@...dley.net>,
	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:

> > if the manufacturer believes that it cannot legally allow software 
> > modification, all the restriction does is force them either to make 
> > the software unmodifiable (which advances freedom not at all) or to 
> > use software under a different license (which advances freedom not 
> > at all).
> 
> Right.
> 
> But if the manufacturer believes that it can legally allow it, and 
> wants to be able to install, software modifications, then it must 
> decide between giving that up and letting the user do it as well.  And 
> this is where the users interests may prevail.

with the little tiny problem that this is not what the GPLv3 actually 
implements. Our point from the very beginning: the GPLv3 "outlaws" 
certain hardware restrictions _even if they are fully legitimate_. Yes, 
of course, it also outlaws 'bad' uses of DRM. The GPLv3 tries to carve 
out some known 'good' uses of DRM (to stop the GPLv3 from being 
_totally_ unusable in vast areas of the marketplace), but that limited 
opt-in approach can in no way be the right solution (think about it as a 
whitelist - wouldnt you want to be able to _add_ to that whitelist?? The 
GPLv3 hardcodes it.)

In other words: i dont want the police to start shooting innocent people 
in the streets, in their pursuit of criminals. Yes, this means criminals 
have an easier job getting away - but _that_ is the price of freedom!

and all these problems of the GPLv3 DRM language derives from the same 
root issue: RMS is trying to make a manual call about what _technology 
use_ is 'good' and what is 'evil'. For some of these calls we might even 
agree. But most fundamentally, a license should _never_ get into the 
business of trying to 'judge' what _use_ is 'good' and what is 'evil'. 
As you can see it on this list alone, some people see Tivo's intentions 
as legitimate, they did the DRM to stay in business but still be able to 
use free software, employ free software developers, show Mythbox how to 
do this stuff on Linux, etc. But the GPLv3 completely destroys Tivo's 
ability to use Linux, were Linux to be under the GPLv3. And by doing 
that, those contested provisions of the GPLv3 itself become a tool 
against "freedom".

You tried to find a workaround for that, by suggesting the 'dont do 
security fixes then', 'use a split key', 'use a rent model' solutions, 
but dont you realize that by suggesting those you are explicitly against 
the intent of RMS, who wants to _stop_ Tivo from being able to do DRM? 
Dont you think it speaks volumes of the GPLv3's quality that you have to 
go out and search for a _workaround_, for a _back door in the license_, 
you have to _go against the intent of RMS_, to be able to implement 
something simple as upgradability? And that even after several attempts 
you have yet to find a solution that actually enables the Tivo? (and 
that is not an accident: RMS _does not want_ the Tivo to use a GPLv3'd 
kernel, and the GPLv3 is structured that way.)

	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