[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87vedpxktu.fsf@graviton.dyn.troilus.org>
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