Message-Id: <200706142139.07720.dhazelton@enter.net>
Date:	Thu, 14 Jun 2007 21:39:07 -0400
From:	Daniel Hazelton <dhazelton@...er.net>
To:	Alexandre Oliva <aoliva@...hat.com>
Cc:	Florin Malita <fmalita@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Adrian Bunk <bunk@...sta.de>,
	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 Thursday 14 June 2007 17:39:32 Alexandre Oliva wrote:
<snip>
>
> And since the specific implementation involves creating a derived work
> of the GPLed kernel (the signature, or the signed image, or what have
> you) and refraining from providing the corresponding sources to that
> derived work (the key and the signature "build scripts"), I still
> think this specific case is a violation of the letter of the GPLv2,
> even if the FSF doesn't take this position.

Not entirely correct. If TiVO is making a change to the binary to include the 
signature, then it *could* be considered a derivative work. If the signature 
is stored in another place - say a bit of Flash or a separate file on the 
disc - then there is no way for it to be considered a derivative work. (Under 
US law, IIRC and I I've interpreted it (and the related cases) properly then 
the change would have to be to the source of the program for it to be 
considered a "derivative". But, as you say often and I should make clear 
myself, IANAL) 

>
> > It seems pretty obvious that the only right Tivo is withholding is the
> > right to install new versions on the device
>
> Actually, no.  They withhold the right to run versions that they don't
> authorize themselves.

And this is relevant to a software license in which way? In particular how is 
this relevant to the GPL, which has always *only* guaranteed access to the 
source if you have access to the binary, the right to distribute your own 
versions and the right to modify the code.

Since the "right to run code" was never guaranteed it *cannot* be a violation. 
It might be in conflict with what RMS intended when he wrote the first 
version of the GPL and in conflict with the intent of the people that 
contributed to GPLv2 but that doesn't matter. However, I will not use (or 
recommend) the GPLv3 in its current form because I feel it makes unnecessary 
restrictions. The fact that you have to "allow additional rights" to make it 
equal to the GPLv2 makes a functional (and spiritual) difference to me.

(Why? Because I'm opposed to "In order to protect freedom X we have to 
restrict freedom Y. Its happening in the US *RIGHT* *NOW* and I have been 
doing what I can to fight that. Now the same faulty logic is being applied by 
the FSF with GPLv3)

> Back when GPLv2 was written, the right to run was never considered an
> issue.  It was taken for granted, because copyright didn't control
> that in the US (it does in Brazil), and nobody had thought of
> technical measures to stop people from running modified copies of
> software.  At least nobody involved in GPLv2, AFAIK.

Why isn't it in the US? Because the binary form of a program does not and 
cannot have a separate copyright than the source code. Since it is the 
*SOURCE* that is actually copyright (mechanical translation cannot create a 
new work, only a new form of an already copyrighted work) guaranteeing 
the "right to run" is pointless.

And you are wrong about that "Nobody thought of it" thing - what you mean is 
that "Nobody that had a hand in drafting and ratifying the GPLv2 thought of 
it". The "NSA Guidelines for Trusted Systems" (aka "The Orange Book") talks 
about methods of preventing the execution of code.

What you and the rest of the FSF is doing in response to "tivoization" is 
saying "we don't care if it wasn't designed to do X, we want to be able to 
make it do that anyway *AND* the manufacturer has to help us do it". There is 
no legal way for you to make that demand of a hardware manufacturer. Instead 
you've gone with the only legal recourse - saying "If you want to use my 
copyrighted work under license X, you have to do Y".  I have no problem with 
that, and if the FSF wants that, it's fine by me. But, as I said, I could 
care less where and/or if something I release under the GPL is used. This 
makes the GPLv2 perfect for me.

> The landscape has changed, and GPLv3 is meant to defend this freedom
> that was taken for granted.
>
> > they never do (and really never could) "modify" the physical copy on
> > your device (which is your main argument).
>
> Qualifying it as the main argument is a bit of an exaggeration.  I
> have a number of different arguments.  The one about incomplete
> sources is the most solid IMHO.

Yes, it is. But your argument about the TiVO is "they can modify the copy on 
it but I can't". Hence it is your main argument. And remember, replace != 
modify.

> >> What do you think you do when you save a modified source file in your
> >> editor?
> >
> > Don't skip the part where the in-memory version started as an exact
> > copy of the original being replaced. Notice the difference? ;)
>
> Sorry, I really don't follow.  Both versions of the kernel binary also
> started from a common source ancestor.  Were you trying to make a
> distinction on these grounds?

No. He was making a distinction that I have seen made a number of times. That 
is, a copy of a copyright work in a computers RAM is a *distinct* copy, 
separate from the file on disc it started as. (And that has actually been 
argued in a court case. I don't recall the specifics, but I do recall that 
the argument was held as valid)

DRH

-- 
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
-
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