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: <ory7ijhu4q.fsf@oliva.athome.lsd.ic.unicamp.br>
Date:	Sun, 17 Jun 2007 05:17:57 -0300
From:	Alexandre Oliva <aoliva@...hat.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	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

On Jun 17, 2007, Ingo Molnar <mingo@...e.hu> wrote:

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

>> On Jun 15, 2007, Ingo Molnar <mingo@...e.hu> wrote:
>> 
>> >>> it irreversibly cuts off certain people from being to distribute
>> >>> GPLv3-ed software alongside with certain types of hardware that 
>> >>> the FSF's president does not like.
>> >>>
>> >> That's not true.  They can just as well throw the key away and 
>> >> refrain from modifying the installed software behind the users' 
>> >> back.
>> 
>> > uhm, so you claim that my argument is false, and your proof for that 
>> > is a "non-upgradeable Tivo"?? <sarcasm> That is a _great_ idea. Not 
>> > being able to patch security holes. Not being able to fix bugs. Not 
>> > being able to add new features. Makes complete sense.
>> 
>> Oh, so you think patching security holes, fixing bugs and adding new 
>> features are good ideas?  What if you can't do it in your TiVo?

> this has to be one of the most bizarre arguments i've read in this 
> thread as of date. Are you seriously questioning the notion that it's a 
> good and legitimate idea for a hardware vendor to make the system 
> fixable, patchable and upgradable?

No.  I'm questioning why the vendor could keep this privilege to
itself.

> Are you seriously suggesting that for a hardware vendor to be able
> to offer such a solution, if they are under the unescapable
> restriction of content providers that the system itself must be
> tamper-proof, it should not be able to use a GPL-ed kernel at all?

No, and I've already explained how I believe this can be accomplished
with the wording in the GPLv3dd4, although IANAL to tell whether
that's correct.

Just make the tivoization machinery require two keys: one that the
vendor keeps, one that the vendor gives to the user (maybe without
ever knowing it).  Neither one can install modifications alone, but
the user can approve modifications by the vendor, and the vendor can
approve modifications by the user.  This is still not ideal, but it at
least doesn't permit the vendor to remove features from under the
user.

> Because that is what your arguments lead to, and that is what the 
> GPLv3 implements.

You haven't really read that bit of dd3 or dd4, have you?

Or the various portions of this thread in which I showed your
assumptions are utterly broken?

> RMS _does not want the Tivo to use a GPLv3 kernel_,

I know you're not stupid, but I can't tell whether you're malicious or
just misinformed.

RMS does not want TiVo (or anyone else) to disrespect users' freedoms,
and installing technical measures to prevent users from adapting the
software to suit their needs and running their modifications is
disrespecting users freedoms.

That he is not opposed to the idea of TiVo using a GPLv3 kernel is
easy to see, if you take the time to read the draft instead of
spreading false assumptions about it:

  this requirement does not apply if neither you nor any third party
  retains the ability to install modified object code on the User
  Product

> Hint: it's not some friendly suggestion of cooperation and working
> together ;)

Hey, wouldn't this be just tit-for-tat? ;-)

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