Re: How long is it acceptable to leave *undistributable* files in the kernel package?
Michael Poole wrote:
> Josh Triplett writes:
>>Mere aggregation only applies to independent works, and only when they
>>are distributed "on a volume of a storage or distribution medium".
>>Separate, non-interdependent programs on Debian CDs fit both criteria.
>
> They are part of a Debian system. That makes them neither separate
> nor entirely independent, especially when you look at the packaged
> versions.
They are part of a Debian system only because they are both packaged.
With the qualification "non-interdependent", which excludes programs
which have Depends or other relationships that would change their status
under the GPL, distributions of different packages in Debian fall under
"mere aggregation of another work not based on the Program with the
Program"; neither program is based on the other, and they are simply
distributed on the same media.
>>Firmware images embedded in kernel drivers fit neither.
>
> Please, demonstrate why the firmware is not an independent work. No
> one has done so yet. Then define "interdependent programs" and
> explain why that concept is relevant to the embedded firmware.
First of all, note that I am _not_ arguing that the firmware is derived
from the kernel driver.
The compiled kernel driver includes both the firmware image and the
kernel driver code other than the firmware. This already makes it more
than "mere aggregation", because compiled binaries are not "a volume of
a storage or distribution medium". Furthermore, the compiled kernel
driver is clearly a work based on the Program (meaning the kernel driver
in source form, and arguably by extension the rest of the kernel since
the kernel driver is based on the kernel). Therefore, the compiled
kernel driver falls under section 3 of the GPL:
> 3. You may copy and distribute the Program (or a work based on it,
> under Section 2) in object code or executable form under the terms of
> Sections 1 and 2 above provided that you also do one of the following:
[snip 3a, 3b, and 3c, all ways of providing "the complete corresponding
machine-readable source code"]
> The source code for a work means the preferred form of the work for
> making modifications to it. For an executable work, complete source
> code means all the source code for all modules it contains, plus any
> associated interface definition files, plus the scripts used to
> control compilation and installation of the executable.
This clearly covers the firmware.
Regardless, it seems like most of this argument is moot, unless we had a
firmware image with full source code under a Free Software license that
happened to be GPL-incompatible. As long as the firmware in question
has no source, and/or is not under a Free Software license, it cannot be
distributed in main anyway, whether or not it is part of the kernel.
>>>Some people disagree with Linus that inclusion as a binary blob is
>>>mere aggregation. However, five years passed between the first binary
>>>blob that I know of and the first complaint that I know of (setting
>>>aside the other issues with that complaint); that suggests that a fair
>>>number of kernel developers agree with Linus or at least accept his
>>>opinion on it.
>>
>>Or they were simply unaware of the presence of binary-only firmware in
>>what was supposedly an entirely Free, GPLed kernel.
>
> "There are none so blind as those who will not see." In one prominent
> case, a contributor who has alleged copyright infringement made the
> allegedly infringed contributions to a component where more than a
> quarter of the files (and almost half of the code bytes) were firmware
> headers -- before he contributed to it. I am still waiting for him to
> explain why anyone should accept his claims, since he made no comment
> about the headers when he offered the contribution.
In which case you are still arguing that Debian should ignore the
copyright-holder's interpretation of the license, just using a different
justification for doing so.
- Josh Triplett
Reply to: