Re: How long is it acceptable to leave *undistributable* files in the kernel package?
@ 18/06/2004 11:25 : wrote Brian Thomas Sniffen :
>Humberto Massa <humberto.massa@almg.gov.br> 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
Reply to: