GPL violations threat is quite real [LWN.net]

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:

The firmware is distributed separately
The firmware is distributed as part of a collective work with GPL'd code
The firmware is merely aggregated onto a volume of a storage or distribution medium with the GPL'd code

In case #2 we have to distribute the firmware under GPL too, with source code in the "preferred form for modification". But not in case #1 and #3.

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!