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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
