| |||||||||||||
GPL violations threat is quite realGPL violations threat is quite realPosted Jun 5, 2008 23:43 UTC (Thu) by dwmw2 (subscriber, #2063)In reply to: GPL violations threat is quite real by PaulMcKenney Parent article: Moving the firmware out
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.
(Log in to post comments)
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!
|
|||||||||||||