How long is it acceptable to leave *undistributable* files in the kernel package?

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 :

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

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

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

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

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

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.