Re: Non-free (or dubious) firmware in linux driver modules, a lengthy analysis.
Sven, the comments I will make here are more or less a compilation of
many things I have said before on d-l and various other places on the
Net.
Sven Luther wrote:
>Hello,
>
>I write this to obtain clarification of the linux kernel firmware
situation,
>since it is quite similar to the firmware-flash program i mentioned
earlier.
>
>First a few definition and explanations to make sure the rest of the
document
>is clear:
>
> A firmware in this case is a bit of code, that is run by a processor
> embedded on the target device the driver is for.
>
>The actual problematic is multiple. We need to examine if the presence of
>non-free firmware in the GPLed driver module in the linux kernel
consitutes a
>violation or not of the GPL of all the other linux kernel authors. Then we
>need to examine if the actual firmware is distributable at all,
independent of
>the above GPL violation or not, and if so if it needs to go in non-free or
>somewhere else. Furthermore we should consider if the
>http://www.nl.debian.org/vote/2004/vote_004 GR does allow you to keep
those
>firmware blobs in the sarge kernel for now or not. And finally see
what would
>be the technical solution we can bring to this problem.
>
>1) Does the presence of firmware in linux kernel drivers constitute a GPL
>violation or not.
>
>This is as far as i see a dual problem. First we have to consider if
the mere
>presense of the actual firmware non-free code in the linux driver is
enough to
>make it a derived work or constitute mere aggregation. Second we have
to see
>if the way the firmware and the driver interact does make one a
derived work
>of the other or not.
>
>1.1) Is distributing two totally separate things in the same binary
enough to
>make them derived work the one from the other.
>
>I say thing here, because i don't want to go into the differentiation
between
>binary, executable and data, not sure what the right term is.
>
>For that let's examine two sections of the GPL :
>
> (GPL 0, first paragraph) 0. This License applies to any program or other
> work which contains a notice placed by the copyright holder saying
it may be
> distributed under the terms of this General Public License. The
"Program",
> below, refers to any such program or work, and 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.
(Hereinafter,
> translation is included without limitation in the term "modification".)
> Each licensee is addressed as "you".
In this paragraph of the GPL we do have a serious problem, the following
contradiction: first it defines a "work based on the Program" as
"either the Program or any derivative work under copyright law", then
it contradicts most jurisdictions' copyright law by "clarifying": "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.
You see, a work *containing* "the Program or a portion of it" can be:
. An independent work, using "the Program or a portion of it" under the
fair use limitations (basically three keywords: quote, research,
satire); in this case, not a derivative work.
. A derivative work, something that is a novel intellectual creation,
but is the result of a (non-automated, intelligent) *transformation* of
the "Program or a portion"; for instance, if I write a program and you
port it to another platform, then your work is a derivative work of
mine.
Mind you, the extent of the copyrights over a work are
approximately the following: if I write work A, my copyrights
are the exclusive rights to my work and any derivative work;
when I authorize you to write a work B derivative from the work
A, the copyrights of the work B -- to the extent that it's a
derivative work -- are both yours and mine, under the terms of
the license that authorized you to create the derivative work in
the same place.
The GPL *tries* not to expand on existing copyright law, but
with the intent of not letting you link a proprietary program
with a GPLd library, it goes just a little bit too far, by doing
the "dictionary redefinition" it does in section 0.
The problem is, when you approach the copyrights dependency-mesh
that is the Linux kernel, for example, what you get is one big,
fluid mass of copyrights, owned by everyone as a collective and
approximately nobody as an individual. And *that* is why the GNU
project (and others) insist on copyrights assignment to put
something on the "official" tree. You can fork GNU as much as
you like, but if you want your sources to appear on
http://www.gnu.org/ then you have to assign the rights, so
indubitably the rights to the whole thing belong to the FSF.
Finally, I would like to repeat that the only legally
established way of determining if one work is derived from
another is the "Abstraction / Filtration / Comparison" method.
. a "collective", "compilation", or "anthology" work: this is a kind
of work that is *NOT* derivative -- it's defined as the work where the
real, intellectual, work done (pun intended) is to select and order the
works of others. Distros are tipically this kind of work. But even the
Linux kernel can be considered IRT some of the works included to be this
kind of work, too, especially if you can construe that no transformation
was executed in the original work, but it was only *included* in the
kernel.
> (GPL 2, last paragraph) : In addition, mere aggregation of another
work not
> based on the Program with the Program (or with a work based on the
Program)
> on a volume of a storage or distribution medium does not bring the other
> work under the scope of this License.
This clause seems to exempt entirely the "anthology work" case: it's
stating something that is already part of copyright law, that the
license does not "bleed" to other non-derivative works in the same
anthology.
>Here we see that the Program (in this case the linux kernel, or the
individual
>driver module), is the work, and that a derived work is something which
>contains it, or if we follow the FSF interpretation, a work which
makes use of
>another work, like a library and such.
>
>I think we can all agree on the fact that if the firmware was
separated both
>in source and in a separate binary file, there would be no problem,
but this
>is not the case, as most often, for ease of use and maintenance, the
actual
>firmware is present as a binary blob in the actual source code of the
GPLed
>drivers, altough in a clearly identifiable way, and the resulting binary
>module contains it too.
>
>So, first the easy part, is distributing the firmware together with
the actual
>module in the same binary module enough to make it a derived work. I
believe
>that this is not the case, because of the mere agregation mentioned in
the GPL
>2 snipplet above. There is nothing fundamentaly different between an iso
>binary with different files included in it, and an elf binary with
different
>sections, or any other of mere agregation of two different things into a
>single binary file.
So, IMHO, in conclusion:
. Is distributing the firmware together with the actual module in the
same binary module enough to make it a derived work?
No. A derived work is something defined in copyright law as
resulting of an intellectual, and novel, transformation.
Distributing things together constitutes a "collective", not a
"derivative".
. Same question, with a "gotcha" variation: Is distributing the firmware
together with the actual module in the same binary module enough to make
it a "work based on the Program" on the terms of GPLv2 Section 0?
(And this is the problem) Possibly _yes_. Albeit the "mere
aggregation" clause *seems* to exempt those, it mentions
explicitly "on a volume of storage or distribution medium" which
is an expression that can or not be interpreted as encompassing
"on the same (source|ELF) file"
> => if this would not be the case, the following examples would
>constitute derived works and thus potential GPL violations :
>
> a) a file compressed with a auto-uncompressor. Is the
>auto-uncompressor executable a derived work of the file, or vice-versa.
>
> b) an elf kernel (like the powerpc/chrp zImage.chrp), with a builtin
>initrd in a elf .initrd section. putting non-free programs into the initrd
>would be problematic.
Yes and yes, so the question can be translated roughly as: (A) can the
GPL rule the rights over anthology works (*)? and (B) if so, is the "mere
aggregation" clause considering a single source file or a single ELF
binary as being "a volume of storage or distribution medium"?
The answer to (B) should not only be given by the GNU people, but by
each and every copyright holder that licenses his works under the GPL.
IRT the Debian project, we could further elaborate this unto:
IF the GPL CANNOT rule over anthology works, THEN it's not a copyright
violation to add binary firmware blobs in the kernel; OTHERWISE they
should be yanked ASAP pending ALL kernel copyright owners clarify that
they consider the binary firmware blobs as begin in fact encompassed by
the "mere aggregation" clause.
(*) I, personally, don't believe so. The rules for anthology works in my
jursidiction are worded so that licenses don't "bleed" inside the anthology.
>Furthermore, it is clear that the actual firmware is a separate thing,
since
>one could easily enough imagine somehow moving the firmware elsewhere, and
>have the actual module load it from disk or network or whatever, and
upload it
>to the device.
>
>The source code situation is more awkward, but provided the firmware
blob is
>clearly identified, and the copyright and licence notice clearly
mention that
>it doesn't apply to said firmware, it can be considered as a convenience
>distribution of two separate entities in the same file.
>
> => So, can we conclude that if the source code copyright and licence
>notice clearly exclude the clearly identifiable firmware blob, that the
>firmware in question is a separate work from the actual driver, which
happens
>for convenience reason to be shiped in the same source file, and ends
up in
>the same binary module ? Given the above analysis, i do believe so.
I do believe so, too.
>1.2) Does the firmware once uploaded to the device, constitute a different
>work from the driver ? In other words, that they communicate in a
clean and
>well determined way ?
I have no doubt.
>So, first notice that the GPL per see doesn't mention anything clearly
>on the case of two pieces of software running on different
>cpus/machines, as this is the case. The GPL FAQ provides a bit of
>clarification :
>
>
>(http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLInProprietarySystem)
> ... However, in many cases you can distribute the GPL-covered
> software alongside your proprietary system. To do this validly, you
> must make sure that the free and non-free programs communicate at
> arms length, that they are not combined in a way that would make
> them effectively a single program. ...
>
>(http://www.fsf.org/licensing/licenses/gpl-faq.html#MereAggregation)
> ... What constitutes combining two parts into one program? This is
> a legal question, which ultimately judges will decide. We believe
> that a proper criterion depends both on the mechanism of
> communication (exec, pipes, rpc, function calls within a shared
> address space, etc.) and the semantics of the communication (what
> kinds of information are interchanged).
> . If the modules are included in the same executable file, they
> are definitely combined in one program. If modules are designed to
> run linked together in a shared address space, that almost surely
> means combining them into one program.
> . By contrast, pipes, sockets and command-line arguments are
> communication mechanisms normally used between two separate
> programs. So when they are used for communication, the modules
> normally are separate programs. But if the semantics of the
> communication are intimate enough, exchanging complex internal data
> structures, that too could be a basis to consider the two parts as
> combined into a larger program.
>
>Mmm, come to think of it, the "If the modules are included in the same
>executable file" may be a counter argument for 1.1), but let's ignore
>this here, especially as we live in a lower level than what is usually
>the application field of the above remark.
What we should note that this all assumes that ((A) above) the GPL can
govern siblings inside the same anthology.
>So the crux of the differentiation is going to be that the exchange
>mechanism between the module and the device running the firmware needs
>to be clearly identified, and since the above speaks about userland
>stuff, it mentions pipes and sockets and the like, while the firmware
>and his drivers live on a lower level, where the communication methods
>are system buses (PCI, USB, ethernet, and so on).
>
>I believe that the communication process is enough different, often
>based on standard interfaces, or at least on interfaces described in
>the GPLed driver, and which could be used without the firmware blob
>ever being uploaded, as would be the case if the firmware blob was in a
>prom on the device for example.
I agree with you 100%.
> => If this would not be the case, we are faced with very unnice
>cases:
>
> a) would then the driver be a derivative work of the firmware
>included in the rom of some extension devices (like pci cards or usb
>devices)? What about the rom of a router or such which is attached to
>the ethernet bus?
>
> b) would then the whole linux kernels, or boot-loaders like grub,
>lilo or yaboot, be derivative works of the bios of the computers we
>use? The same goes for embedded devices running linux and their boot
>code.
>
> c) binary driver modules would be derived works from the linux
>driver, making stuff like the nvidia (or others) proprietary a GPL
>violation.
All of those are false, because if you Abstract, Filter and Compare all
of those, it seems obvious at least IMHO that they are *NOT* at all
derived works.
>Very disturbing isn't it. Once could claim that the GPL 3 exception :
Yeah, it would be :-)
> (GPL 3, last part of second-to-last paragpraph) However, as a special
> exception, the source code distributed need not include anything that
> is normally distributed (in either source or binary form) with the
> major components (compiler, kernel, and so on) of the operating
> system on which the executable runs, unless that component itself
> accompanies the executable.
>
>would cover these cases, but we run into the exception of the exception
>when we face distribution of pre-installed linux machines, either
>desktop computers, or embedded devices like those linux-running
>routers.
The problem, also worth noticing, is that Debian *is* the "operating
system on which the executable runs" :-) so this exemptions falls down,
because "this component itself accompanies the executable". At least in
the case of some d-i or live CD.
>I personally would like to say that this is the case, and make
>binary-only modules as well as x86-binary only extension devices GPL
>violations, but i have serious doubts that this would stand before a
>judge.
Yeah, I doubt it would stand too.
> => So, in conclusion we can say that, for the low level case we are
>speaking at, the communication process between a driver module, and the
>firmware-running processor on the embedded device is clearly defined
>ans separated, and does then not constitute a reason to make the
>firmware a derived work of the driver and vice-versa.
Agreed.
>So, given the two above argumentations, the firmware and driver
>uploading it and communicating with the device running it are not
>derived works the one from the other, and that inclusion and
>distribution of them in the linux kernel source code or binary version
>doesn't represent a GPL-violation per se.
Agreed. Running the risk of repeating myself, I don't believe that in
any sane jurisdiction the GPL could govern sibling works living in the
same anthology, independently of this anthology being represented in a
volume or in a single ELF file.
>2) Are the individual firmware blob distributable at all ?
>
>But the above doesn't tell us that those firmware blobs are free, just
>that they can be distributed together with the linux kernel, either as
>source code or as binary modules or even builtin the kernel. This is
>clearly something that needs to be examined on a case per case basis.
I.e, they can be distributed together with the kernel IF AND ONLY IF
they can be distributed *at* *all*.
>I have not examined all the firmwares in details, others can maybe fill
>in here, but i believe the problematic cases are the following
>
> a) firmware with source code, but some DFSG-non-freeness in the
>licence on them.
As per the SC and the recent resolutions, these could be in the kernel
until post-sarge, when they would have to go to "non-free".
> b) firmware without source code with the needded right for
>distribution.
Idem.
> c) firmware without source code but without the needed right to
>distribute them.
This one, not only must be yanked from the kernel, but -- unless rights
to distribute are acquired -- must be yanked now to protect Debian users
and mirror network from possible lawsuits from the copyright owners of
the firmware.
>All but c) can currently go in the non-free section of our archive, and
>we will need to do that.
>
>3) Can we ship them in sarge's kernel in main ?
>
>The GR http://www.nl.debian.org/vote/2004/vote_004 does say :
>
> The Debian Project,
>
> affirming its commitment to principles of freeness for all works it
> distributes,
>
> but recognizing that changing the Social Contract today would have
>grave consequences for the upcoming stable release, a fact which does
>not serve our goals or the interests of our users,
>
> hereby resolves:
>
> 1. that the amendments to the Social Contract contained within the
>General Resolution Editorial Amendments To The Social Contract (2004
>vote 003) be immediately rescinded; 2. that these amendments, which
>have already been ratified by the Debian Project, will be reinstated
>immediately after the release of the next stable version of Debian,
>without further cause for deliberation.
>
>Some would claim that :
>
> a) we used to ship those firmware blobs in the kernel in previous
>versions of the archive.
>
> b) it is a bit latr now in the sarge release process to remove them
>properly, and thus it is meaningful to keep them for the sarge kernel
>in main ?
>
>I am not entirely sure about the details, especially as said changes to
>the social contract got disguissed in 'Editorial Ammendements', but i
>believe that they included parts that where considered to be data and
>not programs (like fonts, documentation, dictionaries, geographical
>data and so on). I don't believe that those firmware blobs in question
>can be in any way described as data, since they are clearly programs
>destined to be run on the device cpu. It is true though that removing
>them would have "grave consequences for the upcoming stable release, a
>fact which does not serve our goals or the interests of our users", but
>i don't believe this is enough to make us invoke the above GR to
>include them in the sarge main kernel.
I disagree with you on this. I think that as the 2004v003 was intended
to the social contract, and (your (a) above) the SC was apparently being
interpreted in the opposite way in earlier versions of Debian, then
2004v004 construes a way of saying "yes, the old interpretation was
different then the new and we will go with the old one until after
sarge".
>4) Technical solution ...
>
>So, given the above we need to make sure of the following :
>
> a) Firmware included in drivers in the same source file as the
>drivers are clearly identified as such, and the copyright notice of
>said file should clearly mention that the firmware in question is not
>subject to the GPL, and only aggregated there for convenience. Ideally
>the firmware in question should be in a separate file.
Yes. If possible, the exact terms of the copyright license to the
firmware should be added to the same place.
> b) The individual modules containing the firmware are GPL compatible
>and thus DFSG free, they can thus be shipped in main if the firmware is
>stripped from them, or in non-free if the firmware is included.
As I said before, this item I believe should be after done sarge.
> c) Should the modules be stripped of their firmware and kept in main,
>or simply moved to non-free, which would be way easier? I believe
>moving the whole of the binary modules into non-free would be better.
It depends. IIRC some modules (A) do not work at all without loading the
firmware in the device; some (B) work with severe limitations; some (C)
work with the same level of quality, give or take a bug or two. At least
in the cases B and C, I see as useful maintaing the module in main.
My "neatness alert" would want to separate all firmware, put the
non-free ones in non-free, etc. But that's just me.
> d) Can we keep the non-free firmware in the kernel-source in main,
>and have only the non-free binary modules moved to non-free ? I believe
>that this is more possible, since if we don't produce the binary
>modules from them, the firmware blobs are only data, but it is limit.
I have no strong opinion about this, except to say that in the ideal,
neat world, nothing non-free should come from main... :-)
>Friendly,
>
>Sven Luther
In the hope that I contributed to this discussion,
Massa
Reply to: