Re: How long is it acceptable to leave *undistributable* files in the kernel package?
Thiemo Seufer wrote:
> Brian Thomas Sniffen wrote:
>>as to why the GPL prohibits
>>distributing linkages of GPL'd and GPL-incompatible code.
>
> It doesn't. If some work includes a GPL'ed work and is distributed,
> then the whole work must be GPL compatible. This doesn't extend to a
> collection of works.
>From the GPL:
> These requirements apply to the modified work as a whole. If
> identifiable sections of that work are not derived from the Program,
> and can be reasonably considered independent and separate works in
> themselves, then this License, and its terms, do not apply to those
> sections when you distribute them as separate works. But when you
> distribute the same sections as part of a whole which is a work based
> on the Program, the distribution of the whole must be on the terms of
> this License, whose permissions for other licensees extend to the
> entire whole, and thus to each and every part regardless of who wrote it.
Note the last sentence, and note in particular that it does not refer to
a "derived work" but instead to a "work based on the Program". This
phrase is defined earlier:
> 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 and/or translated into another language.
While the first part of the definition says "derivative work under
copyright law", the second part clarifies what that is intended to mean:
anything that contains part or all of the Program, modified or not. I
suspect they simply assumed that no interpretation of "derivative work"
could possibly exclude two things compiled into the same binary, or two
things closely linked together. While the issue of whether dynamic
linking creates a derived work is heavily debated (personally, I think
it clearly does), I have never seen any doubt that statically linking
two things into the same binary creates a derived work, until this
discussion. Furthermore, I have never seen debian-legal participants
argue so vehemently to ignore a licensor's interpretation of their
license before, especially not to support non-free software in doing so.
In the next section of the GPL, the intent becomes even more clear:
> Thus, it is not the intent of this section to claim rights or contest
> your rights to work written entirely by you; rather, the intent is to
> exercise the right to control the distribution of derivative or
> collective works based on the Program.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This explicitly covers the case you mention.
Switching from the GPL back to your mail:
> For some binary driver, you have to show why a bunch of kernel modules
> is included in the kernel, and why the fact you can drop them easily
> from a compilation doesn't reinforce the idea it's a collection of
> works.
When they are linked into the kernel binary, the resulting binary is
clearly a derivative of both the kernel and the drivers; to use your
description, they are no longer easily separable. Furthermore, kernel
modules interface heavily with the kernel. They include kernel header
files, call kernel functions, and modify kernel data structures. That
most definitely makes them derivatives of the kernel, based on the above
definition from the GPL.
> For some firmware, you have to explain how this provision becomes
> relevant, that is why the definition of "source" makes sense for it,
> why the presence of this firmware constitutes an inclusion when it's
> only use is to be loaded in a separate device, and how exactly
> moving it to a userland file makes a difference.
Firmware embedded as a binary C array in a driver becomes either part of
the kernel binary or part of the module binary. In either case, unless
you happen to know the exact offset and length of the array in the
binary, the works are inseparable. In addition, one (the driver) will
not function without the other (the firmware). So while the firmware is
not necessarily a derivative work of the kernel driver, the kernel
driver is definitely a derivative work of the firmware. The kernel
driver is clearly a derivative work of the kernel as well (see above),
so at a minimum, this either makes the kernel driver non-distributable
(unless the GPL is extended to the firmware, which would make the
firmware non-distributable since it has no source to satisfy the GPL
with). Furthermore, if the driver is compiled into the kernel, the
kernel binary is derived from the driver. I would argue that most of
this also applies when the driver is in source form, as well, based on
the definitions in the GPL and based on the fact that the driver does
significantly more interfacing with the firmware than just loading it to
the device.
>>I would be much more convinced if I saw an argument from the
>>GPL-incompatible-firmware-is-OK side
>
> I don't say "GPL incompatible" firmware is OK. I say I can't prove it's
> _not_ OK, while its copyright holder claims it is. Without proof to the
> contrary, I'd rather follow his idea of what his work actually is.
The copyright holder of what? The copyright holder of the firmware
often hasn't given any permission at all to that firmware, or has given
permissions such as the GPL that are not satisfiable without source,
which they don't provide. The copyright on the kernel is held by many
different people, some of which strongly believe GPL-incompatible and/or
binary-only firmware violates their copyright.
- Josh Triplett
Reply to: