So what if it was inside the official kernel repo but defaulted to building as a module, and anyone distributing binaries left it on the default? Would that actually satisfy the licenses or are there clauses that would get in the way?
From my mostly second-hand knowledge, in practice even lawyers specializing in IP wouldn't have a solid answer for how to make this distinction, without looking at a specific case in detail. If it came up in a trial, the two sides would make a version of the arguments presented here: one would emphasize that the sources have now been "added to the kernel tree", a unified project managed with close integration etc. etc., while the other side would argue they were merely placed alongside the kernel sources in a version control system, like collecting short stories in an anthology.
Let me ask a slightly different question then. Does the GPLv2 ever try to control anything that is not derived from the GPL source code? Some of the FSF's saber-rattling seems to imply that either the answer is yes, or they're being misleading, or they have a completely ridiculous definition of derivation.
A derivative work is one that extends upon an original work. Thats an simple definition of a derivative work, but doesn't include any clear examples.
The FSF gives the example that linking causes a derivative work, and incorporates that line of thinking into the LGPL. The reason behind it is that a linked work existence is based upon an original work, and can not exist without it. As such, linking is an easy example where the line into derivative work has been crossed.
In the end, it will be up to the courts to decide what is or isn't a derivative work in software. The statutory definition is incomplete and the concept of derivative work is thus interpreted with reference to explanatory case law. Each time a music company wins a lawsuit against remixes, derivative work extends its grasp. Each time a game like WoW wins a lawsuit against bot software, one more step is taken.
In light of the precedential cases, I consider the FSF example of linking to be quite conservative definition of derivation. It might not be true every time and for every possible use of linking, but it should be true enough in the general case. Is there a strong argument against that interpretation?
Don't they claim that the linking rule works via derivation? As far as I understand it, the FSF would tell you that anything linked is always derivative. But that doesn't mean it's true. If you could prove that a particular instance of linking to a library was not derivative, would they still claim your program had to be GPL?
As I understand it, the LGPL exists to 1. provide legal certainty and 2. allow some amount of external derivation if necessary.
And it's easy to create an artificial dynamic-linking case where there is provably no derivation, using multiple libraries with the same API.
Don't they claim that the linking rule works via derivation?
Yes.. it was the closest thing I could think of where the two pieces of software are fairly separated. I mean you could have a huge proprietary program, and a developer calls gsl_pow_int() from the GNU scientific library, and the entire program must be licensed under the GPL.
I think that's about as close as you're going to get.
If you're looking for a case where the FSF said a piece of software had to be licensed under the GPL, even though it was NOT a derivative work, I don't think you'll find it. The reason it must be a derivative is copyright law.. the GPL can't unilaterally change that.
And they do have a requirement if you do so: The only condition is that you cannot release the aggregate under a license that prohibits users from exercising rights that each program's individual license would grant them.
