Note that the word "derivative" is used here as defined by the license, not in its plain English meaning.
But one gray area in particular is something like a driver that was
originally written for another operating system (ie clearly not a derived
work of Linux in origin). At exactly what point does it become a derived
work of the kernel (and thus fall under the GPL)?
THAT is a gray area, and _that_ is the area where I personally believe
that some modules may be considered to not be derived works simply because
they weren't designed for Linux and don't depend on any special Linux
behaviour.
Basically:
- anything that was written with Linux in mind (whether it then _also_
works on other operating systems or not) is clearly partially a derived
work.
- anything that has knowledge of and plays with fundamental internal
Linux behaviour is clearly a derived work. If you need to muck around
with core code, you're derived, no question about it.
Then you have things like (Open)ZFS and DTrace.
Same with pre-OS X Mac. Most Mac programs were written with Mac in mind, and it was not uncommon for programs mucked around with OS code and data.
What matters is how copyright law defines derivative work, and in the US that has nothing to do with whether or not your work was written with another work in mind or plays with fundamental internal behavior of another work. What matters is whether or not it incorporates copyrighted elements of another work.
This is the key point, and it is nearly impossible for firmware blobs to depend on any OS behavior, let alone "special Linux behavior". The only way they could do so is via the open-source part, so it should be easy enough to check that.
You rewrite that library under an MIT license, so now your code can link to that and run. Is your original code still a derivative work?
> You are not required to accept this License, since you have not signed it.
So to answer your question: no, unless you've copied bits of GPL library into your code (or similar that would be judged as a copyright violation).
There's also a crappy situation of Oracle vs Google that made APIs copyrightable, so now it's not entirely clear if your code + your rewrite of library is still yours if it uses an API of the GPL library.
> > You are not required to accept this License, since you have not signed it.
> So to answer your question: no, unless you've copied bits of GPL library into your code (or similar that would be judged as a copyright violation).
Actually that clears a lot up for me, and I'd have considered myself reasonably knowledgeable when it comes to copyright in general; I think I had a few conflicting ideas about what it means to be an original work. Thank you.
Which might happen very easily: one #include and you might be there.
It matters who is doing the rewriting and how they got the code in the first place.
The GPL is emphatically not clear about anything. It's a legal minefield precisely because no one has any idea what it means, and everyone has their own interpretation.
> It matters who is doing the rewriting and how they got the code in the first place.
Well, then,... that's about as clear as mud.
RMS contacted them, and asked them to relicense. They suggested either reimplementing a stub readline-library, or rewriting their line editing code against another lib instead. RMS insisted that they would still be a GPL-derivative, resulting in the current license situation.
I may be misremembering the recount of this, as this was way before my time.
So I guess if someone asks you for the source code, you can require them to prove that they actually have a copy of the GPL version, and not the new one.
The license does not contain a definition for "derivative" nor of the similar term "derived" which it also uses.