Non-free (or dubious) firmware in linux driver modules, a lengthy analysis.
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".
(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.
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.
=> 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.
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.
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 ?
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.
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.
=> 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.
Very disturbing isn't it. Once could claim that the GPL 3 exception :
(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.
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.
=> 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.
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.
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 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.
b) firmware without source code with the needded right for distribution.
c) firmware without source code but without the needed right to distribute
them.
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.
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.
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.
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.
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.
Friendly,
Sven Luther
Reply to: