I apologize for the cross-posting to linux-kernel, but this seems
relevant to me (even if it comes from debian- lists) to the kernel
developers as a whole.
@ 18/06/2004 10:02 : wrote Brian Thomas Sniffen :
>Thiemo Seufer <[email protected]> writes:
>
>>The firmware typically wasn't patched, and nothing is derived from
>>it.
>
>
>Isn't the kernel containing the firmware derivative of it? If not,
>why can't I put some GPL-incompatible x86 code into the kernel,
>load it into a device in my system -- the main memory -- and then
>issue a command to the processor to execute it?
>
>That is, doesn't your interpretation allow arbitrary linking of
>GPL'd programs?
>
>I would be much more convinced if I saw an argument from the
>GPL-incompatible-firmware-is-OK side as to why the GPL prohibits
>distributing linkages of GPL'd and GPL-incompatible code.
>
>-Brian
>
you see, I was starting to have doubts myself in the "no non-GPL
linkage" clause of the GPL (yes, it's there, it is the last
paragraph of http://www.gnu.org/licenses/gpl.txt -- and is
authoritative because of the other arguments below, read on...)
What rights do the GPL'd software recipient have? The GPL grants
some rights not granted by copyrights law. I made an extensive
document and posted it to d-l, but no-one seemed to listen or to
understand. All ok. IRT making derived works, the recipient has the
right of making *some* derived works (respecting 2a and 2c) and to
redistribute those derived works under the terms of the GPL itself.
It seems not to permit anthology (collective) works, until you see
the "mere aggregation" clause (section 2 third paragraph) /which/
appears to cover anthology works.
So now, we have to decide where is the line dividing where the "mere
aggregation" is "compiling" (in the "making an anthology" sense) and
not "deriving". But wait, in the "how to use the GPL" thing, the
very last paragraph explains that linking is to be considered making
a derived work.
This bears none or almost none consequence for a single copyright
holder, but for a multi-copyrighted, multi-type (original, derived,
anthologic) work like the Linux kernel, it explains that if you want
a license to the kernel, *and* your work links to the kernel, *and*
your work is not original [1], *then* you will consider your work a
derivative work of the kernel.
[1] perfectly possible case of a BSD LKM that does not need glue
code in the Linux kernel to link, possibly because the needed glue
code was already there for some _other_ reason. The other
(controversial) example is the nvidia drivers, that distribute under
the GPL the glue code and use a binary (non-derived-from-the-kernel)
driver as the workhorse.
But wait; firmware is *not* linking with the kernel, as the icons
are *not* linking with emacs. Or are they? What is linking? If you
consider linking to give names fixups and resolving them, well, the
char tg3_fw[] = ... is linked with the kernel all right. If you
consider that a call (as in the asm CALL opcode sense) must be made,
it's not. The firmware does not "execute", at least in the main CPU.
Anyway, the non-GPL-compatibly-licensed icon in your previous emacs
example is *most* *certainly* not linking with emacs (in the
ld-or-ld.so sense) and it's OK.
The (simplified) answer: the GPL "do not link" is weak because of
the "mere aggregation clause" and because of the dichotomy between
derivative and anthology works; it's weaker in the case of the
binary kernel modules, especially if they are not distributed with
the kernel (the linking is done at the end user, where many things
are possible); it's even weaker in the case of firmware (because
firmware does not /properly/ link in the software sense, even if it
*does* link in the ld-or-ld.so sense); it's really faint in the case
of an accompanying icon or image (or movie: eMovix comes to mind).
Please refer to
http://lists.debian.org/debian-legal/2004/06/msg00361.html
for an explanation of how IMHO are the original/anthology/derivative
relations are formed to get to the current linux kernel.
I hope I have helped this discussion.
--
br,M
On Fri, Jun 18, 2004 at 10:55:47AM -0300, Humberto Massa wrote:
> What rights do the GPL'd software recipient have? The GPL grants
> some rights not granted by copyrights law. I made an extensive
> document and posted it to d-l, but no-one seemed to listen or to
> understand. All ok. IRT making derived works, the recipient has the
> right of making *some* derived works (respecting 2a and 2c) and to
> redistribute those derived works under the terms of the GPL itself.
> It seems not to permit anthology (collective) works, until you see
> the "mere aggregation" clause (section 2 third paragraph) /which/
> appears to cover anthology works.
That clause only deals with some anthology works, not all. It's an
exception to <<a "work based on the Program" means either the Program or
any derivative work under copyright law: that is to say, a work containing
the Program or a portion of it, either verbatim or with modifications...>>
It's pretty clear that the linux kernel is not a mere aggregation of
works on some volume of storage.
--
Raul
On Fri, Jun 18, 2004 at 11:35:43AM -0400, Raul Miller wrote:
> That clause only deals with some anthology works, not all. It's an
> exception to <<a "work based on the Program" means either the Program or
> any derivative work under copyright law: that is to say, a work containing
> the Program or a portion of it, either verbatim or with modifications...>>
> It's pretty clear that the linux kernel is not a mere aggregation of
> works on some volume of storage.
Any chance you guys could come to some kind of consensus on this so I
know what has to be done for the debian package?
Thanks.
-- wli
-----BEGIN PGP SIGNED MESSAGE-----
On Friday 18 June 2004 15:51, William Lee Irwin III wrote:
> On Fri, Jun 18, 2004 at 11:35:43AM -0400, Raul Miller wrote:
> > That clause only deals with some anthology works, not all. It's an
> > exception to <<a "work based on the Program" means either the Program or
> > any derivative work under copyright law: that is to say, a work
> > containing the Program or a portion of it, either verbatim or with
> > modifications...>> It's pretty clear that the linux kernel is not a mere
> > aggregation of works on some volume of storage.
>
> Any chance you guys could come to some kind of consensus on this so I
> know what has to be done for the debian package?
>
> Thanks.
If it's undistributable, it obviously doesn't belong in main. So please
remove the undistributable stuff. Second, if it's non-free, it doesn't
belong in the kernel, which is in main. So remove anything that is
non-free from the kernel-source. It's really not rocket science, and I
don't know why people insist upon talking about collective versus
derivative works, because none of this stuff belongs in main anyway.
If you need help in determining whether something is free or not, please send
a message to debian-legal (preferably in a new thread) asking that question.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iQEVAwUBQNMdSOWR/8lWBVPnAQFdPQf+P4lhAJpZ4Em1SByzalfDUQSkBvDoEM3a
YP7mAHV1i3cUWwVM0oWJnvOd2v9ZYmvDFk2VzXFh9SYz2wHnYGE0cs85jiKOtnjo
pItvmhry1/GZDQNVSHnAwX0hUl3K8VF8jWyOwXdYRYxlYYTmTd4tJYlaN9HTomhn
THCBCOF7ZY04qdoC4gslHVJAJm4CVBex6gfRz3O+ExkJC5TO5fT81D+vg+uQOs+N
ITGTI10ZjvmISTkYHaCRuTPwd6+S/AjPozoYzGyNOnVNoydX81VXIvHJtm+6mBuM
v/OmWflwUI0Y39Dm+NestF0HmIdjNMl7pm59V7PBXreldB02feibxQ==
=v2xr
-----END PGP SIGNATURE-----
On Fri, Jun 18, 2004 at 04:50:08PM +0000, Brian M. Carlson wrote:
> If it's undistributable, it obviously doesn't belong in main. So please
> remove the undistributable stuff. Second, if it's non-free, it doesn't
> belong in the kernel, which is in main. So remove anything that is
> non-free from the kernel-source. It's really not rocket science, and I
> don't know why people insist upon talking about collective versus
> derivative works, because none of this stuff belongs in main anyway.
> If you need help in determining whether something is free or not, please send
> a message to debian-legal (preferably in a new thread) asking that question.
I have a blacklist of things to remove already I'm stuck carrying and
continuing to remove from what we call "pristine" upstream sources, but
I didn't see any specific suggestion for additions to it or removals
from it. So at the moment I don't have anything to go on as far as what
this thread tells me to do. I'm bothered somewhat by the fact that this
all sounds alarming, but doesn't seem to have anything specific to be
done about it, which is why I asked the participants in this discussion
to try to come to some kind of actual conclusion I could act on.
-- wli
> But wait; firmware is *not* linking with the kernel, as the icons
> are *not* linking with emacs. Or are they? What is linking? If you
> consider linking to give names fixups and resolving them, well, the
> char tg3_fw[] = ... is linked with the kernel all right. If you
> consider that a call (as in the asm CALL opcode sense) must be made,
> it's not. The firmware does not "execute", at least in the main CPU.
> Anyway, the non-GPL-compatibly-licensed icon in your previous emacs
> example is *most* *certainly* not linking with emacs (in the
> ld-or-ld.so sense) and it's OK.
>
> The (simplified) answer: the GPL "do not link" is weak because of
> the "mere aggregation clause" and because of the dichotomy between
> derivative and anthology works; it's weaker in the case of the
> binary kernel modules, especially if they are not distributed with
> the kernel (the linking is done at the end user, where many things
> are possible); it's even weaker in the case of firmware (because
> firmware does not /properly/ link in the software sense, even if it
> *does* link in the ld-or-ld.so sense); it's really faint in the case
> of an accompanying icon or image (or movie: eMovix comes to mind).
I think there's a continuum here. If, for example, the firmware in the
Linux kernel is identical to the firmware in the Windows driver and the
Linux kernel contains no special code to talk to this firmware (in other
words, the firmware makes this device look like every other similar device
and the kernel contains a generic driver), then the 'mere aggregation'
argument is persuasive. We have two independently derived works that happen
to be combined in a single file. They each happen to implement the same
interface from opposite sides, but they do so for different reasons and are
not specifically designed to work as a unit.
On the flip side, if the Linux kernel code were developed just to talk to
this firmware and this firmware were developed just to make this device work
with Linux, then the 'mere aggregation' argument seems ludicrous. Each work
is specifically designed to work with the other, they aren't just combined
after the fact. The two had to have been developed together and each has
portions that only make sense in combination with the other.
There are, of course, points in the middle of the continuum.
I personally have no issues with the lack of the preferred form for the
purposes of making modifications. I don't find that fight worth fighting in
any case. I do, however, have major issues with use restrictions and
distribution restrictions. Code that cannot be freely used, reverse
engineered, modified, used on whatever hardware or with whatever software,
or distributed subject only to the GPL restrictions should not be integrated
into the Linux kernel. These restrictions cut to the heart of the very
freedoms the GPL is supposed to protect.
DS
PS: Please CC me on any replies that you wish me to read and possibly reply
to.