Message-Id: <200706150127.18069.dhazelton@enter.net>
Date:	Fri, 15 Jun 2007 01:27:17 -0400
From:	Daniel Hazelton <dhazelton@...er.net>
To:	Michael Poole <mdpoole@...ilus.org>
Cc:	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@...g.hm" <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 23:04:37 Michael Poole wrote:
> Daniel Hazelton writes:
> > On Thursday 14 June 2007 22:13:13 Michael Poole wrote:
> >> The fundamental reason for this is that neither the executable code
> >> nor the digital signature serves the desired function alone.  The user
> >> received a copy of the executable for a particular purpose: to run the
> >> program on a particular platform.  With DRM signatures, only the
> >> combination of program and signature will perform that function, and
> >> separating the two based on strictly read legal definitions is risky.
> >
> > I agree.
> >
> >> The question of whether DRM signatures are covered by the license must
> >> be resolved before one can determine whether Tivo gave "*EXACTLY*" the
> >> same rights to object-code recipients as Tivo received.  GPLv2 is
> >> worded such that the answer to this does not depend on whether one is
> >> in file A and the other in file B, or whether one is on hard drive C
> >> and the other is in flash device D, as long as they are delivered as
> >> part of one unit; it *might* matter if, say, one is received on
> >> physical media and the other is downloaded on demand.
> >
> > I have read the GPLv2 at least three times since it was pointed out that
> > I had forgotten part of it. At no point can I find a point where Tivo
> > broke the GPLv2 requirement that they give the recipients of the object
> > code the same rights they received when they acquired a copy of the
> > object or source code.
>
> I am trying to reconcile your responses to those two paragraphs.
>
> If the DRM signature and program executable are coupled such that they
> are not useful when separated, the implication to me is that they form
> one work that is based on the original Program.  This is beyond the
> GPL's permission for "mere aggregation".
>
> If they are one work, and the original Program was licensed under the
> GPLv2, the combined work must also be licensed under the terms of the
> GPLv2.
>
> The input files required to generate a DRM-valid digital signature are
> part the preferred form for modifying that work.
>
> If those bits are not distributed along with the rest of the GPL'ed
> work, the distributor is either not giving the same rights to the end
> user, not distributing the source code for the work, or both.  Which
> is it?

Following your logic it would be a "failure to distribute the source code for 
a work".

However, since the signing is an automated process it cannot generate a "new" 
work - at least, not under the laws of the US - so the signature itself 
cannot have a copyright at all.

DRH
PS: This is the exact same reason that the GPL cannot apply to a Bison 
generated parser in the US. The "input" file that causes Bison to generate 
the output can have a copyright, but not the output - no matter what RMS or 
anyone else wants, and no matter what the GPL says about it.

>
> Michael Poole



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