Hardware license terms


I wasn't able to find anything about a closed source firmware, just the user space driver which used to be closed source but has since been reverse engineered.
 
Ah I see i was a bit too hasty in my searching, when I first searched I couldn't find any statement that it (kernel driver / firmware blob) was actually open (so I assumed closed), neither could I find any actual code.
But I see now the kernel driver is open, still can't find the sources though, but they are probably out there somewhere.
---
Oh, etnaviv is aiming at replacing the open kernel driver as well, no wonder i kept getting etnaviv results when searching for the vivante sources.
 
I didn't know the cgw zero firmware was open, cool !! (even if it's not so clear how much, it's good to see more devices with this characteristic)
 
Last edited:
Any Linux driver which isn't OSS would violate the kernel's GPL.
Nope. You can combine proprietary code with GPL code, the GPL actually has a loophole that is further explained in the GPL FAQ at gnu.org. They simply don't want proprietary kernel code upstream.

Part of the kernel API is GPL-free in the sense that it does not expose internal structures that are considered essential enough to leave that loophole, the kernel sources even include some preprocessor macros for a "non-GPL mode" that'll hide all GPL relevant functions. The proprietary fglrx and nvidia kernel drivers ain't open either, they ship with non-GPL glue code and a pre-compiled kernel-independent blob that will be linked together to create the kernel module. IIRC Nvidia even states in that glue code that you're not even allowed to modify it yourself without getting an explicit approval from Nvidia.
 
Could you specify which "loophole" you are talking about ? Is it the "system library exception" ?
 
Nope. You can combine proprietary code with GPL code, the GPL actually has a loophole that is further explained in the GPL FAQ at gnu.org. They simply don't want proprietary kernel code upstream.

Part of the kernel API is GPL-free in the sense that it does not expose internal structures that are considered essential enough to leave that loophole, the kernel sources even include some preprocessor macros for a "non-GPL mode" that'll hide all GPL relevant functions. The proprietary fglrx and nvidia kernel drivers ain't open either, they ship with non-GPL glue code and a pre-compiled kernel-independent blob that will be linked together to create the kernel module. IIRC Nvidia even states in that glue code that you're not even allowed to modify it yourself without getting an explicit approval from Nvidia.
No, this isn't correct, and nvidia/fglrx are in fact infringing. Just nobody with the relevant copyright has the interest/funds to sue them over it.
 
First of all: out of tree kernel drivers are only to be used as separated modules. Kernel modules are in fact just ELF libraries, i.e. they fully qualify as a dynamically linked binary which is being loaded at runtime, so you can apply the same logics that the GPL FAQ uses for plug-ins. Which means: even with their rather strict perspective there are cases that are considered absolutely legal - a plug-in that by itself does not use any symbols from GPL code is not considered a derivative work. Is it possible to develop a driver that runs all by itself and only interacts with the kernel by having its own functions called? Absolutely! Is it a practical thing to do? With something as complex as a video card, definitely not. Yet those proprietary drivers try to work as isolated as possible. But the point is: it's possible.

But the important part in the whole discussion is the term "derivative work" - not derivative means no GPL-copyleft - which is extensively used by the GPL, but it's being defined solely by copyright laws. That creates some problems:
  • copyright laws are a local matter, it might actually be perfectly legal in some countries because they have a different idea of derivative software
  • copyright laws usually do not cover software detailed enough => too vague to draw a line in these cases
This is a general issue of the GPL and until someone (not necessarily Linux- or even GPL-related!) actually sets anything in motion to enforce a legally binding decision it remains a legally exploitable gray area, no matter what opinion other people have on the issue - it's legal until law explicitly says otherwise. The kernel developers simply follow a more practical interpretation of derivative software - see e.g. the whole DMA-buf/PRIME export discussion.

As far as suing Nvidia/AMD is concerned: It might enforce a decision on the whole matter, but you probably still wouldn't win in this case - as Linus once said in the whole GPL/non-GPL export macro discussion:
The fact is, the law isn't a blind and mindless computer that takes what you say literally. Intent matters a LOT. And using the xxx_GPL() version to show that it's an internal interface is very meaningful indeed.
We'll eventually get a legally binding decision on this matter, but I bet my balls that it'll be far away from what the FSF wants to enforce.

Last but not least: if you don't give the binaries to others, you can still do whatever you want - this also counts for whole companies like Google: they have been using heavily modified Linux kernels on their servers for ages without making those changes public.
 
We've been waiting for a legal case to test the GPL since at least 1992. I don't expect anything any time soon to be honest.

As far as I know, in the mobile space, drivers work by shipping a GPLed shim driver that 'communicates' with a binary blob that actually drives the hardware, presumably defining 'communication' in reference to this FAQ entry: https://www.gnu.org/licenses/gpl-faq.html#NFUseGPLPlugins
 
There's been quite a lot of lawsuits concerning the GPL over the years in the US and Germany, and so far everything I've heard about ended in favor of the GPL.

But in this case the GPL itself ain't the core of the problem, it's the outdated copyright laws - providing a definition for derivative software kinda goes beyond the scope of a software license.
 
Hasn't everything so far ended up in out of court settlements? Perhaps I've been misinformed. Seems the Sitecom Germany case went to a final ruling for an injunction, but that was a straightforward case of redistributing modified binaries, not 'derivative software' in terms of linked software.

It strikes me that not defining 'derivative software' and then using that term in the GPL is a big part of the confusion over what's allowed and what's not; if various supporters of the GPL can't even agree on how it should be defined in this context, then it should have been explicitly defined there in the first place. I guess the FSF's problem in adding it in now is that however you do end up defining it, you're going to upset some people and cause a lot of fallout - for them it may be better to wait for a court case that defines it for them.
 
Hasn't everything so far ended up in out of court settlements?
The news section of gpl-violations.org lists several cases that didn't - e.g. a "clear-cut victory" against D-Link, in which the GPL was explicitly deemed valid under German law, D-Link was bold enough to make an official statement that they did not consider the GPL to be legally binding.

It strikes me that not defining 'derivative software' and then using that term in the GPL is a big part of the confusion over what's allowed and what's not
They use the term "derivative works", which is the general term defined by the copyright laws. By simply providing an own definition of derivative software you might still get into conflicts with copyright laws, some court might end up interpreting things differently.
 
As far as I know, most lawsuits linked with the GPL were about companies not caring at all about the GPL and not about such subtleties.
 
Back
Top