> The module was a proprietary binary. Since a kernel module requires interfacing with the kernel API, it could be considered a derivative work and a breach of the GPL license.
I never quite understood this logic: the same (?) binary blob is used for the FreeBSD and Solaris drivers.
Because to make a driver work with Linux you have to add Linux-specific code that typically uses Linux's source code, and that combination of the driver and Linux-specific code could be considered a "derivative".
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.
By that reasoning every program written to run on MS-DOS was a "derived work" of MS-DOS. Such programs were written with MS-DOS in mind, and often mucked around with fundamental internal MS-DOS behavior.
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 quickly get into something similar the ship of theseus (or Trigger's broom) argument. You write some code that must link to a GPL library to functon; that code is now GPL because it's a derivative work of the library.
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?
Your original code is never a derivative work. You retain copyright to the code you wrote yourself, even if it's combined with GPL later. GPL even contains this interesting clause:
> 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.
> Your original code is never 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).
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.
> The license is abundantly clear about this and answers all your questions.
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.
I think one of the matters that confused me about it was the CLISP question. IIRC, CLISP linked to readline, but was released under a non-GPL license.
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.
RMS may have believed or wanted that, but it is my understanding (IANAL!) that the case law has been settled differently. If you are found in violation of the GPL due to a dependency you weren't aware was released under the GPL, you can fix that violation by rewriting your application to avoid the GPL dependency.
CLISP et al cannot be forced to distribute their code under the GPL. It's their code and their choice; contract law cannot compel someone who has never entered into the contract to do something against their will -- CLISP didn't knowingly distribute GPL code, so that distribution doesn't trigger acceptance of the GPL terms. They just have to make the situation right once they're made aware of the violation.
It's more nuanced. If you've included GPL code and modified or redistributed it, then you either have to comply with the GPL to have permission for that use, or you've potentially committed a copyright violation.
To comply with the GPL you only need to publish the one specific snapshot of source code you've combined and redistributed with GPL code, but you don't need to permanently relicense your project if it doesn't contain any code you don't have rights to use. The "tainted" version will be granted as GPLed forever, but other earlier or later versions that don't use any GPL code don't have to.
Or you can go the copyright way, and claim it wasn't a copyright violation (because it was a fair use, or non-copyrightable code) or settle the matter in whatever way the law lets you get away with.
That isn’t any different from what I said though? If someone points out you violated their copyright then you need to (1) fix the issue, and (2) pay appropriate damages. But for open source software the damages are nil, so fixing the violation is the only thing you need to do. And you can do that by either releasing the code as GPL, or removing the dependency. Either would be an acceptable remedy, in the eyes of the law.
Apparently the situation was that CLISP was distributed as `lisp.a` and `libreadline.a` (with source for Readline included) and the end-user linked them together. Haible offered to write a `libnoreadline.a` library, exporting Readline's function but not providing their functionality, but RMS insisted that the result would still be a derived work of Readline.
I’m not a lawyer, but my understanding is that the GPL requires you to make source available upon request to users of your software.
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.
That's an interesting cognitive dissonance that I've always been fascinated by. I've heard people criticize developers who release proprietary drivers for the linux kernel, but never those who release something dual licensed as GPL2/MIT, or those who distribute a dual licensed GPL2/MIT module as if it were solely under the MIT license; surely that would violate the Linux kernel's GPL (in being a derivative work) as much a proprietary module would?
MIT is Ok because MIT is compatible with GPL. GPL has language saying you can't add restrictions, but the combination GPL+MIT is essentially GPL so it's ok.
Dual GPL/MIT essentially means that you as a user can choose whether you to use the code as GPL or as MIT, but if you contribute to the code you must provide the full GPL+MIT rights.
As to why release a driver as GPL/MIT instead of just the GPL, I think the idea is that the BSD's (or other OS'es) can take the code and use it under the terms of the MIT license and port it to their kernels. IIRC there are many drivers in Linux that are dual licensed in this way for that reason.
I'm not sure about the details, but to write a linux kernel module you must include some .h files under the GPL license. You really have to include it because linux ABI is intentionally not stable exactly to prevent proprietary abuse. So, AFAIK, every functional linux kernel driver must be released under the GPL.
The point is: if you want to include a GPL licensed header, your code must comply with its license. Your opinion on the GPL is an entirely different matter.
"Derivate" I think here is red herring. The biggest problem is that the combination of kernel + nvidia modules could never be redistributed, which means that technically no distro should have been able to ship these drivers by default.
I never quite understood this logic: the same (?) binary blob is used for the FreeBSD and Solaris drivers.
* https://www.nvidia.com/en-us/drivers/unix/
So how can it be a 'derivative' of the GPL Linux if it it also used on non-GPL systems?