Weekly Edition
Return to the Kernel page
| |||||||||||||
Moving the firmware outIt seems that David Woodhouse had a bit of an ulterior motive when he recently reworked the kernel firmware loader. That is not to say the work is not useful in its own right, but one of his goals is more apparent now: removing all of the firmware from the kernel source tree. By making it easy to separate the firmware blobs—while still allowing them to be statically built into kernels—he has provided a possible path for all firmware needed by any Linux driver to live in a single place. The firmware issue is somewhat contentious, with licensing and political issues that tend to annoy the kernel developers. Arguments about the "legality" of distributing firmware with the kernel flare up from time to time. Separate from that, there are some good reasons why it makes sense to keep the firmware in its own place: some distributions need or want to distribute their kernels without firmware blobs and some hardware manufacturers will not allow their firmware to be distributed with the kernel because of concerns about the GPL. The current situation makes it harder for both users and distributors. Woodhouse brought up the idea of pulling the firmware out of the kernel in a post to linux-kernel and ksummit-2008-discuss. The agenda for this year's Kernel Summit is under discussion, so he proposed that it be discussed there. He is clearly trying to anticipate the technical concerns that others might have:
By the time the kernel summit comes around, we should have made decent
progress on moving _all_ the firmware blobs to the firmware/ directory.
And at that point I'd like to remove them completely, to a separate git
tree and tarball. Those who really want to build them in to their static
kernel would still be able to, but it wouldn't be the default behaviour.
Unsurprisingly, there are some fairly strenuous objections. David Miller is quite annoyed:
Sorry, that's taking things too far. I've fought, like, forever, to
keep the tg3 driver with it's firmware in-tree. I refuse to let the
driver get broken like that, it's staying working, and that means
in-tree and linked into the driver.
If debian or whoever else have these concerns and want to rip the firmware out, it is one hundred percent their problem to patch things out of the kernel tree they use. But there are other reasons to collect firmware in one single place, as Arjan van de Ven notes:
Right now it's a royal pain for users to get all the right pieces of
firmware.... having ONE place to put all that would go a long way of making
that
side of things easier.
If you want to argue that that should be in the kernel tarball itself, you won't hear me complain. But others will... and for that a 2nd tarball might well be the answer. Just we shouldn't need 100 tarballs. There is a very real concern, though, that putting firmware without source into the kernel is a GPL violation. It is impossible to know for sure without a court decision, which is something that no one wants to have to deal with. Companies—and their lawyers—tend to be very conservative when it comes to inviting lawsuits, so removing unrelated, possibly actionable code from the kernel sources is of great benefit to them. As Woodhouse says:
And it isn't just the nutters. Fedora also wants to ship the firmware in
a separate package from the kernel -- since the alleged GPL violation is
such a _gratuitous_ risk given that we always use an initrd anyway, and
because people want to be able to do 'Free' spins which don't feature
the firmware at all, even in the source packages.
By making it easier to put all of the firmware in one non-GPL tree, hardware vendors—and their lawyers—may be willing to allow the firmware to be distributed. If Woodhouse's plan for supporting both compile-time and runtime loading of the firmware is successful and reasonably transparent, there should be little difference for kernel developers, but big improvements for users and distributors. It is unclear whether this is something that will be resolved in email, as Woodhouse hopes, or will require a discussion at the Kernel Summit in September, but it's an idea with a lot of merit that may find its way into the mainline at some point. (Log in to post comments)
GPL violations threat is quite real Posted Jun 5, 2008 6:57 UTC (Thu) by khim (subscriber, #9252) [Link] Actually legal aspect is quite real. Translation of English to English of I refuse to let the driver get broken like that, it's staying working, and that means in-tree and linked into the driver is we have driver which contains GPLed software and non-GPLed software so closely intertwined that it's practically impossible to separate them - and THIS is clearly GPL violation. Here it explained quite well: The more that people claim it would be such a burden to split the firmware from their driver because they're so closely interrelated, the more they are arguing against the 'mere aggregation' defence, which was tenuous enough in the first place... and it's also the only defense for inclusion of said firmware in kernel in first place! I do not believe tg3 is so closely intertwined with it's firmware blob that it's impossible to separate them but if it's actually the case - the whole thing should be ripped out. Firmware can be kept in tree for "convenience" but it's different then "necessity". There are only two choices:
GPL violations threat is quite real Posted Jun 5, 2008 16:39 UTC (Thu) by PaulMcKenney (subscriber, #9624) [Link] Hmmm... I officially don't have an opinion about where firmware blobs should or should not go, but I do believe that there are way more than two possibilities here. To see this, let's consider an analogous situation with user programs and the Linux kernel. Suppose that a given proprietary user program could only be run on specific versions of the Linux kernel. This could happen for any of the following reasons: 1. The program relied on a new kernel feature. 2. The program relied on a long-standing bug being fixed. 3. The program relied on a bug -not- being fixed. 4. The program could not operate without a performance improvement that was available only in specific versions of the kernel. Would any of these reasons imply that the program be licensed under GPL? If not, couldn't similar issues arise between drivers and firmware? Thanx, Paul (my opinions, not necessarily those of my employer)
GPL violations threat is quite real Posted Jun 5, 2008 17:00 UTC (Thu) by dwmw2 (subscriber, #2063) [Link] "Would any of these reasons imply that the program be licensed under GPL?"No, because the kernel explicitly grants an exception for userspace: NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work".We have no such exception for firmware.
GPL violations threat is quite real Posted Jun 5, 2008 18:51 UTC (Thu) by zlynx (subscriber, #2285) [Link] Firmware is a bit weird. You don't even know that it's code. It could be FPGA config or a particular set of switch settings just like setting registers but all in a lump. It's always seemed a bit dishonest to me to claim firmware must be GPL'd or out while at the same time accepting driver code that uses NDA provided or reverse engineered register settings. Those register settings could be in some way also code. Just think of it as register settings and card state, no different than sending a mysterious 32 byte blob that you don't understand but the VGA output doesn't work without it.
GPL violations threat is quite real Posted Jun 6, 2008 7:20 UTC (Fri) by njs (guest, #40338) [Link] If a particular blob is just a bunch of switch settings, then it's unlikely that it's copyrightable -- both because there's nothing expressive about it, and because it's required to achieve a given functionality (there's no other way to set up the card except to send those particular bytes). Similarly, information provided under an NDA is not protected by copyright (because information is never protected by copyright, only expression). In this case, there's no GPL issue. Most firmware, though, is far more complex than that, and clearly copyrightable, and thus copyrighted. In this case, there may be a GPL issue. Any particular blob falls into one or the other of these cases, and *which* case it falls into is determined entirely by the law, the particular circumstances, and, ultimately, a judge. The result may or may not be "dishonest", but it is what it is; how we decide to "think of it" just doesn't matter, unfortunately...
GPL violations threat is quite real Posted Jun 5, 2008 19:11 UTC (Thu) by PaulMcKenney (subscriber, #9624) [Link] So you are arguing that it is impossible for a driver to rely on a feature that is present only in specific versions of the firmware? Or that it is impossible that a driver might need a workaround for a bug that is present only in specific versions of the firmware? Or are we talking past each other here? Please keep in mind that I am questioning the OP's assertion that there are only two possible reasons why firmware and driver might be version-dependent. As noted in my earlier comment, I officially have no opinion on whether or not firmware blobs must be GPLed. Sincerely, Paul E. McKenney (my opinions, not my employer's)
GPL violations threat is quite real Posted Jun 5, 2008 23:43 UTC (Thu) by dwmw2 (subscriber, #2063) [Link] So you are arguing that it is impossible for a driver to rely on a feature that is present only in specific versions of the firmware? Or that it is impossible that a driver might need a workaround for a bug that is present only in specific versions of the firmware?Of course those things are possible. And while userspace has an explicit exception from GPL 'infection', firmware does not. Or are we talking past each other here?Perhaps. Sorry; I'm not entirely sure how to parse khim's post, or your response. The interesting question at the heart of the issue is whether the inclusion of the firmware is a violation of the GPL -- and you both seem to be either digressing or just losing me. I thought we were all operating the assumption that the firmware is an independent and separate work in its own right. If it's not, then the issues are fairly clear-cut anyway -- the only interesting case for debate is where it's independent, isn't it? So having made that assumption, we have other options:
I'm planning to get us to situation #1 where we distribute the firmware separately. Currently, I believe us to be in situation #2, where we are violating the GPL. There are those who believe that actually we are in situation #3 -- where we're excused by the "mere aggregation on a volume of a storage or distribution medium" clause, which covers things like CDs of gratis or shareware software which might be found on magazine covers. Personally, I don't see any way that clause can cover the combination of driver and firmware into a vmlinux, when each of them is useless without the other. It's a collective work and not just a happy coincidence that they're sitting together on the CD. But that's just my opinion, not a court ruling. Shipping the firmware separately solves the probable GPL violation, while the work I've already done lets people continue to build arbitrary firmware blobs into the kernel if they really want to -- so it's not a regression for them. Normally we err on the side of caution when it comes to legal matters, and I see no reason why this should be the exception.
We were in fact talking past each other Posted Jun 6, 2008 0:18 UTC (Fri) by PaulMcKenney (subscriber, #9624) [Link] OK, we were talking past each other. I was responding to case 1 and 2 in your original posting, pointing out that bugs, features, and performance issues might cause two independent works to nevertheless be related -- not in the GPL/copyright derived-works sense, but rather in the sense that not all possible pairs of versions of the two works could be expected to work together correctly. As I said before, I don't have an opinion on the placement of firmware blobs. If I was attempting to argue for firmware blobs being placed in the kernel tree, I would likely use analogies with (1) gcc, which is permitted to compile and link proprietary code, and (2) ftp, where a proprietary client is permitted to interoperate with a GPLed server. But I was not attempting this argument, rather, I was probing your cases 1 and 2 in your original posting. Sincerely, Paul E. McKenney (my opinions, not my employer's)
We were in fact talking past each other Posted Jun 6, 2008 0:50 UTC (Fri) by dwmw2 (subscriber, #2063) [Link] OK, we were talking past each other. I was responding to case 1 and 2 in your original posting, ...Khim's original posting, not mine? ...pointing out that bugs, features, and performance issues might cause two independent works to nevertheless be related -- not in the GPL/copyright derived-works sense, but rather in the sense that not all possible pairs of versions of the two works could be expected to work together correctly.True, except where you say "not in the GPL sense". The GPL has implications which go further than just derived works -- it explicitly extends to sections of a combined work which, when distributed separately, would be considered independent and separate works in themselves. The only thing that lets you distribute that combination of non-GPL'd and GPL'd stuff is if it's "mere aggregation on a volume of a storage or distribution medium", like two programs which both happen to be on that shareware CD I mentioned earlier. The existence of a close relationship such as the one you hypothesise would tend to indicate that this is not "mere aggregation on a volume of a storage or distribution medium". And that, I think, is what Khim was talking about. It's certainly what I was talking about in the post he quotes.
We were in fact talking past each other Posted Jun 6, 2008 14:35 UTC (Fri) by PaulMcKenney (subscriber, #9624) [Link] You are correct, I was indeed responding to khim's original comment. And please note I did -not- say "not in the GPL sense", but rather "not in the GPL/copyright derived-works sense". The legal complexities and uncertainties alluded to by your response to your modified version of my statement is indeed one reason why I don't have an opinion on how drivers and firmware blobs should be distributed. The main point I am trying to make -- which you appear to agree with -- is that there is good and sufficient motivation to provide users with some mechanism that automatically matches up the Linux-kernel driver with the corresponding device firmware. This is I believe that point that Dave Miller was getting at in the original article. And -of- -course- we must do this automatic matching in a way that honors the GPL and other relevant licenses and laws. But we must do the automatic matching of driver and firmware, one way or another. Sincerely, Paul E. McKenney (my opinions, not those of my employer)
We were in fact talking past each other Posted Jun 6, 2008 14:49 UTC (Fri) by dwmw2 (subscriber, #2063) [Link] The main point I am trying to make -- which you appear to agree with -- is that there is good and sufficient motivation to provide users with some mechanism that automatically matches up the Linux-kernel driver with the corresponding device firmware. This is I believe that point that Dave Miller was getting at in the original article.It's not particularly hard to do this -- and we get it right in many situations already, where the firmware is either in ROM/Flash or extracted from a Windows or other driver -- and thus we have to cope with the various versions we might encounter. You work out what version of the firmware you have, and you cope accordingly. Alternatively, for firmware which can be shipped in the linux-firmware tree, we can actually ship both old and new versions simultaneously by appending a version number to the filename (think of it a bit like an soname in libraries). That makes it easier, because older kernels would continue to request and use the older firmware blobs. I don't think it's a particularly serious concern. The firmware blobs just don't change that often -- they're a black box which we can't tweak for ourselves, and if we're really lucky the manufacturer might throw and improved version over the wall occasionally, but it isn't anywhere near as frequent as we'd like.
We were in fact talking past each other Posted Jun 6, 2008 18:30 UTC (Fri) by nix (subscriber, #2304) [Link] If we're really lucky the firmware is generated at build time from the GPLed source :) I doubt you're moving the sym53c8xx firmware; it's not a blob (it has actual comments and everything).
We were in fact talking past each other Posted Jun 6, 2008 18:41 UTC (Fri) by PaulMcKenney (subscriber, #9624) [Link] That is certainly the best case -- very nice when it works out this way!
Moving the firmware out Posted Jun 5, 2008 9:42 UTC (Thu) by tzafrir (subscriber, #11501) [Link] Are there drivers in the kernel with firmwares and GPL-compliant source for the firmware?
Moving the firmware out Posted Jun 5, 2008 12:25 UTC (Thu) by cladisch (✭ supporter ✭, #50193) [Link] drivers/usb/serial/keyspan_pda.S and xircom_pgs.S are the firmware source code files for the keyspan_pda driver.
Moving the firmware out Posted Jun 5, 2008 17:27 UTC (Thu) by nix (subscriber, #2304) [Link] The Symbios 53c8xx firmware in drivers/scsi/sym53c8xx_2/sym_fw*.h is GPLed. (It even has a GPLed relocation engine :) )
Moving the firmware out Posted Jun 5, 2008 21:27 UTC (Thu) by iabervon (subscriber, #722) [Link]
I like the comment about getting the right assembler: "Get as31 from {URL}, and hack on it a
bit to make it build."
Moving the firmware out Posted Jun 6, 2008 18:58 UTC (Fri) by giraffedata (subscriber, #1954) [Link] By making it easier to put all of the firmware in one non-GPL tree, hardware vendors—and their lawyers—may be willing to allow the firmware to be distributed. I just don't get this. Under what possible theory based on the Linux copyright would the hardware vendor think it's a bad idea to permit people to distribute its firmware? The implication I take is that some hardware vendors don't allow me take their firmware object code, bind it up with the Linux kernel, and give it to someone else. While there's an obvious theory that I would be violating Linux authors' copyright doing that, how could it hurt the hardware vendor?
Firmware distribution Posted Jun 7, 2008 14:22 UTC (Sat) by man_ls (guest, #15091) [Link] I can see strategic, logistic and practical considerations against distributing the firmware with the Linux kernel.A hardware vendor may (misguidedly of maliciously) think that it is a bad idea that Linux distributions carry its firmware blob. One trivial cause might be that the vendor wants its users to upgrade to the latest hardware. We have seen something similar with proprietary graphics drivers which do not support older cards, and with Vista drivers too. Stupid (new customers would not exactly come running to our door), but possible. Also, a malicious party (say, SCO) may buy the copyrights from a hardware vendor with the sole intent of bringing a copyright dispute against the kernel. While the firmware can be ripped out in a matter of hours from the current version, it would cause a logistic nightmare to take it out of all distributed kernels. No matter how stupid it is (since firmware is there to be distributed), but we have seen how meritless cases can drag on for years. Even if all vendors agree, you need written permission to distribute copyrighted material. Linux contains a lot of firmware binary blobs. Now, are all permissions stored in the kernel tree? How can a distribution make sure that it has permission for all binary blobs? What about redistribution rights? This is even before considering the problem with GPL linking that others have pointed out. These issues may not have a solid basis, but people have been known to do dumber things. Even we watching from the sidelines can surely understand how e.g. a Red Hat lawyer might be worried to see these gray blobs in their distribution.
Firmware distribution Posted Jun 7, 2008 15:55 UTC (Sat) by giraffedata (subscriber, #1954) [Link] I can see strategic, logistic and practical considerations against distributing the firmware with the Linux kernel. Those are all good reasons, but they don't seem to have anything to do with the post to which you replied, which asks the question: Under what possible theory based on the Linux copyright would the hardware vendor think it's a bad idea to permit people to distribute its firmware? Some of the reasons you give are motiviations for people other than the hardware vendor to oppose having firmware distributed in the kernel. The others are reasons not based on the Linux copyright. The article implied that there are hardware vendors who don't want their firmware distributed with the Linux kernel, but would be OK with it being distributed in a package which is copyright-licensed more liberally.
Firmware distribution Posted Jun 7, 2008 16:32 UTC (Sat) by jake (editor, #205) [Link] > The article implied that there are hardware vendors who don't want their > firmware distributed with the Linux kernel, but would be OK with it being > distributed in a package which is copyright-licensed more liberally. The lkml thread seems to indicate there are some hardware vendors who are unwilling to let their firmware be distributed with the kernel. Perhaps they are concerned (rightly or wrongly) that allowing that would subject _their_ code to the GPL. jake
Firmware distribution Posted Jun 15, 2008 11:12 UTC (Sun) by Duncan (guest, #6647) [Link] This would, from my (non-lawyer) understanding, be correct. At least as I understand US law (other nations may be different), it would be impossible to force them to reveal sources, since you can't do that with someone else's code. However... It's entirely possible, even probable given enough time and the hair brained legal theories some come up with (the GPL is an anti-trust violation, riiiggghhttt, glad the Judge thought the same and threw out that case), that someone (say a competitor) claiming copyright interest in the kernel might decide to try to force the code out of these people based on it shipping with the kernel for so long. As I said above, according to my understanding and by US law at least, that wouldn't be possible. However, should someone get the hair-brained idea to try it, given the right circumstances (see SCO), it could drag out forever, costing the hardware company in question all sorts of money it would certainly rather be spending elsewhere. Not everyone has the resources of an IBM. Thus, while it shouldn't be a legal danger in the end, it's enough of an economic risk thru exposure to simple legal threat, even if ultimately unsuccessful, that I can easily see a company's accountants and lawyers combining to veto any permission to ship firmware with the kernel. But separate it into a non-GPL entangled tarball, and the legal threat gets much less. All that said, the threat is really the reverse, as explained by others, that a SCO could ultimately hold the kernel (at least current and past shipping and supported versions, and thus everyone using them) hostage, with things as-is, due to the "if you can't ship it and comply, you can't ship it" wording), not anyone doing any more than tying up a few legal resources up for awhile trying to get the code out of the firmware folks. Thus, while it may be a bit of an economic risk for the firmware folks, it's a SERIOUS risk for those depending on the kernel, all the more reason to get the separation done as expeditiously as possible. I'm glad someone's now attacking the issue, as it /is/ a danger, there are SCOs in the world, and as such, it needed addressed. Duncan
|
|||||||||||||