Comment Re:Umm... (Score 1) 585
Addressing the last bit, about the user, first, while anyone can make a claim, it's extremely unlikely that a claim against a mere user based on violation of the GPL would stand up in court, because the intent (and wording, it seems to me, but IANAL) is clear that a user may do what they want, including modification, linking with whatever proprietary program, etc, as long as they don't distribute the result. Thus it is that mere users of proprietary kernel modules don't have to worry about linking them into the kernel, but distributions have to be very careful about what they distribute, and of course the authors of those proprietary kernel modules have something to worry about, with the trend toward stricter and occasional threats of legal action but nothing serious yet.
Thus while you are correct that such a thing would cause an uproar in the community, it's not realistic that the case against said user would get very far -- and I expect the FSF would end up on the user's side against whatever "insane" author, as well.
As for the coder and linker against the GPL library, ultimately, that comes down to how derived (from copyright code, US code in consideration for GPLv2, more general international code for v3) the new code is found to be. For static linking, the answer is pretty simple as the GPL library will then be shipped as part of the binary. For dynamic linking, the case is blurrier. However, answering your question, consider that the headers needed to compile the code against the library can be argued to be part of the GPLed code as well, tho with some limits as to the extent that can be taken (I know there's limits there but won't attempt to define them as I'm a bit vague on that end of things myself). Using that definition, anyone using the headers to link against would be creating derived code.
But perhaps that wouldn't ordinarily be seen as a correct interpretation. Still, by downloading and using the libraries and their headers on a system, thus making copies of them, something forbidden by copyright law without the code owner's permission (as here granted by the GPL), a developer will be going beyond mere copyright. Again, for a mere user that's not a problem, as the GPL is explicit in unconditionally allowing that, and a mere user doesn't even have to agree to it either, as the license at that point is covered under the automatic grant to recipients under the same conditions clause. But it's the GPL that allows it, absent other permission, since copyright code forbids it, and once someone starts distributing it (or a derived work, see below), then they must accept the GPL themselves in ordered to do so.
Further, just doing the development and not distributing anything isn't a violation. But as soon as the developed code linking to that GPL library is distributed, THEN the derivation question comes into play.
And again, under ordinary circumstances, that's a logical and legitimate question, one that hasn't been definitively settled in court, AFAIK. HOWEVER, and this is where my previous comment enters the picture, when developers start looking at the actual logistics of defending themselves, it quickly becomes apparent that by questioning the author's intended and specifically stated definition of "derived", one is starting to saw notches into the branch they're legally sitting on, that branch being the validity of the GPL that gave them the rights to copy and code agains the library in the first place.
Thus, the rare appearance of the GPL in actual court, because by trying to argue about the definitions of derived, the whole legal foundation the developer is standing on is being eroded.
It's also worth pointing out the effect of a severability clause and the fact that the GPL (at least v2, which I'm most familiar with) has what could be considered a NEGATIVE severability clause in effect -- that if it's impossible to satisfy patent and other legal requirements and the GPL, then distribution must cease entirely. Again, by trying to poke holes in the definition of derived, the accused violator quickly finds they are poking holes in the whole legal justification for their use of the work in the first place.
It is at this point that the reasonable offer of little more than correcting the violation going forward plus expenses, begins to look rather inviting, especially when faced with the possibility of the thing spiraling entirely out of the developer's control, possibly including a no-ship injunction (maybe complete with recall of already in-channel units) while the case proceeds, the threat alone of which is generally enough to get the accused looking to settle, even if they think they'd ultimately win the court case. Against that, opening the source or very quickly finding a replacement library so as to continue uncontested shipping while additionally paying little more than to-date expenses, looks VERY good indeed!
Of course, it also helps that AFAIK, there's a 100% success record (with one mild variance against the FSF GPL FAQ in regard to trade secrets, but it dealt with enforceability of them, not of the GPL) in not only settlements, but in the few cases that HAVE gone to court, now several, including in in Israel, several in Germany, and a couple here in the US. That's going to be STRONG encouragement to settle as well, thereby keeping the accused in control of the terms and continued distribution ability, let alone avoiding the now even worse odds of actually winning the case in court.
But even so, yes, the question of just what's derived remains, as does the fact that so far, every potential violator has decided to settle rather than risk an unfavorable resolution. (Then again, the FSF and others have never pressed the riskiest cases, either. That's one reason proprietary kernel modules continue to ship, and the threats that have happened tend to be against Linux distributions, not the module developers themselves, as the distributions tend to be far more sensitive to community PR effects in addition to the normal legal issues and thus much more likely to back down nearly instantly.)