@ 18/06/2004 11:25 : wrote Brian Thomas Sniffen :
>Humberto Massa <[EMAIL PROTECTED]> writes: > >>No, Raul. The law. USC17, BR copyright law, and probably every >>copyright law following the Geneva convention *does* such a >>distinction. BR copyright law specifically separates the rights of >>derivative works from the rights of a collective (anthology) work. I >>have said it before, but I will repeat: > > >You aren't thinking about enough edge cases. For example, let's >say I take a short story A. I have nine authors write nine >variations of it and publish a collection of these ten works. The >whole book is a derivative work of A. It is also a collective of >A_i. >
No, it's just the collective (anthology) of nine derivative works.
>>now let's say this combined kernel accepts as-is a BSD LKM for >>ppp, p.ex. *and* that it's licensed GPL-compatible >>2-clause-BSD/MIT/X. say Linus includes this in its kernel tree. >> >>now we have: >> >>linux_v0p0ppp == linux_v0 + patch_0 + ppp ===> >> THE ANTHOLOGY CALLED Linux Kernel == (C) Linus Torvalds >> THE PARTS == some parts (C) Linus Torvalds, >> other parts (C) Regents of USC, >> and other parts (C) Linus Torvalds + Kernel Contributor #0 > > >This assumes that module required no adaptation to fit with the >Linux kernel, and the kernel required no adaptation to fit with the >module -- they just cleanly plugged into one another. This seems >unlikely to me. >
Not really. The kernel is filled with utility functions (like sprintf), that could have been imported directly if they were under a GPL-compatible license, and to be used without "adaptation".
Even in the need of adaptation, the "nvidia trick" would be to make the adaptation of the kernel GPL'd and the adaptation of the driver proprietary. The adaptation of the driver would be derivative of the driver, even if its purpose is to permit linking with the kernel, because it's the result of a _transformation_ /on/ /the/ /driver/, and not on the kernel.
Transformation is the keyword.
There is more: the Linux kernel does select and document, by using the macros EXPORT_SYMBOL, EXPORT_SYMBOL_GPL, which symbols, when used, *indicate* the probability of a LKM be a derivative work of the kernel.
>>complicating a litlle bit more: Kernel Contributors #1, #2, and #3 >>patch respectively the kernel, patch_0, and ppp: >> >>linux_v0p3ppp == linux_v0 + patch_0,1,2,3 + ppp ===> >> THE ANTHOLOGY CALLED Linux Kernel == (C) Linus Torvalds >> THE PARTS == some parts (C) Linus Torvalds [1], >> other parts (C) Regents of USC [2], >> other parts (C) Regents of USC + Kernel Contributor #3 [3], >> other parts (C) Linus Torvalds + Kernel Contributor #2 + >> Kernel Contributor #0 [4], >> and other parts (C) Linus Torvalds + Kernel Contributor #1 [5] >> >>[1] the untouched kernel parts >>[2] the (untouched) ppp parts >>[3] the patched by patch_3 ppp parts >>[4] the patched by patch_0 and patch_2 kernel parts >>[5] the patched by patch_1 kernel parts >> >>Easy, huh? extrapolate for ten+ years of patching and aggregating and >>you'll get where we are today. > > >OK... but I am still unconvinced that any object like [2] exists. >Code just isn't that modular. I specifically don't believe that the >firmware blobs fit into that slot. Do you? > >-Brian >
I believe worse. I believe firmware blobs fit in the slot of logo images, independently if kept in their own .png files or embedded in the linux kernel binaries: not a derivative work, under no circumstances. Just, to use the GPL term, merely aggregated.
Mind you, I don't think it's excusable to distribute the un-distributable, as *is* the case with some firmware, just that merely aggregating the distributable-but-GPL-incompatible with some GPL'd work and distributing is valid, as per the GPL section 2 paragraph 3.
-- br,M
