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:	Fri, 15 Jun 2007 12:07:41 -0400
From:	Michael Poole <mdpoole@...ilus.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Daniel Hazelton <dhazelton@...er.net>,
	Alexandre Oliva <aoliva@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Lennart Sorensen <lsorense@...lub.uwaterloo.ca>,
	Greg KH <greg@...ah.com>,
	debian developer <debiandev@...il.com>,
	"david\@lang.hm" <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

Ingo Molnar writes:

> * Michael Poole <mdpoole@...ilus.org> wrote:
>
>> > I.e. you cannot just cleverly define "source code" to include 
>> > something unrelated and then pretend that it's all in one work. And 
>> > that's exactly what the GPLv3 does: it creatively defines the 
>> > hardware's key into the 'source code' of the software and then asks 
>> > for that to be provided _not_ because somehow the key derives from 
>> > the software (it clearly does not), but as a "compensation" for the 
>> > right to redistribute! I.e. it's trying to extend its scope to some 
>> > item that is not part of the software. See?
>> 
>> No.  The GPL does not care about the hardware's key, as I pointed out 
>> in the part of my email that you cut out.  The GPL cares about the key 
>> used to generate an integral part of the executable form of the GPLed 
>> work.  The executable does not function properly if it lacks that 
>> part. [...]
>
> it is a false statement on your part that the executable "does not 
> function properly" if it lacks that part. Try it: take out the harddisk 
> from the Tivo (it's a bog standard IDE harddisk), put into a nice Linux 
> PC, mount it, modify a bit in the kernel image header and it will likely 
> still boot just fine on that PC.

Tivo did not program or sell the hard drive to be used in an arbitrary
Linux PC.  They sold the hard drive to be used in their hardware, with
a Linux kernel specifically modified for that.  Without the right
digital signature, it does not do the same thing: it is *incomplete*.
That is eminently a software issue.  Hardware limitations -- whether
they be RAM size or requirement for a certain digital signature -- are
beside the point.

The requirement that I "modify a bit in the kernel image header" is
also one of the most pathetic cop-outs I have seen.  What makes that
binary format the preferred form for modification of Linux?

Michael Poole
-
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