* Re: How long is it acceptable to leave *undistributable* files in the kernel package? [not found] <o0_liB.A.TFG.4fu0AB@murphy> @ 2004-06-18 13:55 ` Humberto Massa 2004-06-18 15:35 ` Raul Miller 2004-06-19 0:12 ` David Schwartz 0 siblings, 2 replies; 6+ messages in thread From: Humberto Massa @ 2004-06-18 13:55 UTC (permalink / raw) To: debian-legal; +Cc: debian-kernel, debian-devel, linux-kernel 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 <ica2_ts@csv.ica.uni-stuttgart.de> 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: How long is it acceptable to leave *undistributable* files in the kernel package? 2004-06-18 13:55 ` How long is it acceptable to leave *undistributable* files in the kernel package? Humberto Massa @ 2004-06-18 15:35 ` Raul Miller 2004-06-18 15:51 ` William Lee Irwin III 2004-06-19 0:12 ` David Schwartz 1 sibling, 1 reply; 6+ messages in thread From: Raul Miller @ 2004-06-18 15:35 UTC (permalink / raw) To: debian-legal, debian-kernel, debian-devel, linux-kernel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: How long is it acceptable to leave *undistributable* files in the kernel package? 2004-06-18 15:35 ` Raul Miller @ 2004-06-18 15:51 ` William Lee Irwin III 2004-06-18 16:50 ` Brian M. Carlson 0 siblings, 1 reply; 6+ messages in thread From: William Lee Irwin III @ 2004-06-18 15:51 UTC (permalink / raw) To: Raul Miller; +Cc: debian-legal, debian-kernel, debian-devel, linux-kernel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: How long is it acceptable to leave *undistributable* files in the kernel package? 2004-06-18 15:51 ` William Lee Irwin III @ 2004-06-18 16:50 ` Brian M. Carlson 2004-06-18 17:11 ` William Lee Irwin III 0 siblings, 1 reply; 6+ messages in thread From: Brian M. Carlson @ 2004-06-18 16:50 UTC (permalink / raw) To: debian-legal, debian-kernel, debian-devel, linux-kernel -----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----- ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: How long is it acceptable to leave *undistributable* files in the kernel package? 2004-06-18 16:50 ` Brian M. Carlson @ 2004-06-18 17:11 ` William Lee Irwin III 0 siblings, 0 replies; 6+ messages in thread From: William Lee Irwin III @ 2004-06-18 17:11 UTC (permalink / raw) To: Brian M. Carlson; +Cc: debian-legal, debian-kernel, debian-devel, linux-kernel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: How long is it acceptable to leave *undistributable* files in the kernel package? 2004-06-18 13:55 ` How long is it acceptable to leave *undistributable* files in the kernel package? Humberto Massa 2004-06-18 15:35 ` Raul Miller @ 2004-06-19 0:12 ` David Schwartz 1 sibling, 0 replies; 6+ messages in thread From: David Schwartz @ 2004-06-19 0:12 UTC (permalink / raw) To: debian-legal; +Cc: linux-kernel > 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-06-19 0:13 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <o0_liB.A.TFG.4fu0AB@murphy>
2004-06-18 13:55 ` How long is it acceptable to leave *undistributable* files in the kernel package? Humberto Massa
2004-06-18 15:35 ` Raul Miller
2004-06-18 15:51 ` William Lee Irwin III
2004-06-18 16:50 ` Brian M. Carlson
2004-06-18 17:11 ` William Lee Irwin III
2004-06-19 0:12 ` David Schwartz
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox