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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <MDEHLPKNGKAHNMBLJOLKMEDNEMAC.davids@webmaster.com>
Date:	Wed, 20 Jun 2007 19:53:25 -0700
From:	"David Schwartz" <davids@...master.com>
To:	<mdpoole@...ilus.org>
Cc:	<linux-kernel@...r.kernel.org>
Subject: RE: Dual-Licensing Linux Kernel with GPL V2 and GPL V3


> I believe compilation copyrights do bear on GPL-licensed software, by
> virtue of the GPL's sentence "[...] rather, the intent is to exercise
> the right to control the distribution of derivative _or collective_
> works based on the Program." (emphasis added).

Ahh, good. So there's no problem with the GPL. I already thought it the most
sensible reading that it included collective works (and it's clear that it
can legally do so), but that makes it clear.

I didn't mean that compilation copyrights have no relevance to GPL issues in
general, just none to the issue of GPLv2 versus GPLv3 and Tivoization. Are
you going to argue that there's a compilation copyright justified by
combining a kernel binary with a signature for that binary? That seems
untenable to me.

> There is a lot of grey and/or arguable area about what constitutes a
> GPL-encumbered collective work versus mere aggregation.

I think it's technically/legally clear what the standards are, but certainly
arguable whether particular works meet that standard. If the choice of works
to combine is sufficiently creative (above and beyond any choices dictated
by functional considerations), it's a GPL-encumbered collective work.

I don't think it's arguable that a signature shipped along with a binary is
a collective work. In any event, if that were true, I think we should be
able to agree that Linus would be required to release his kernel signing
keys.

> Although I
> disagree, I understand and respect that some believe that the kernel
> plus a digital signature over it is "mere aggregation".

It clearly is. What else could it be? The digital signature is a separate
item, a pure number for which there is no copyright interest, that is simply
appended to the kernel. It does not contain significant protected elements
of the kernel. No creative process is used to generate it or attach it. The
decision to append is dictated by purely functional considerations (nobody
creatively picks which signature to bundle with which kernel).

> I would like
> to focus the discussion on that question, though, rather than whether
> the GPL is worded to control the rights to compilations-in-general
> that include GPLed works.

If the kernel plus a digital signature over it is not mere aggregation, then
Linus is violating the GPL by shipping kernel plus digital signatures but
not including the "source code" to produce the signatures. If the
ridiculousness of that is not sufficiently obvious, I'm not sure what else
to say. Where is the outcry that Linus is keeping his signing key secret,
failing to include the source code that he used to build the Linux kernel
distibution?

The past few times this has come up, every possible irrelevent side issue
was raised. For example, that the signature in the case of Linux is not
functional. These considerations do not have anything to do with whether the
combination is mere aggregation or not.

Ironically, this case is even clearer than linking. The two works are quite
literally stapled together. There is no intermingling at all.

DS


-
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