WizardStan
Mega GP Mania
- Joined
- May 24, 2008
- Messages
- 16,731
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.
Hardware license terms
- Thread starter Luke-Jr
- Start date
Dimacus
Member
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.
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 suppose that it shouldn't be too far away from here https://github.com/torvalds/linux/tree/master/drivers/gpu/drm/etnaviv
Dimacus
Member
Yes, that's the new drm, but what I haven't been able to find is the original open vivante drm sources (no vivante tree in the repository as far as I can see), the ones that are supposed to be along the lines of 60.000 lines of code mentioned in https://www.phoronix.com/scan.php?page=news_item&px=Etnaviv-DRM-2016-Update
Letalis Sonus
Advanced Member
- Joined
- Mar 5, 2009
- Messages
- 1,530
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.
Letalis Sonus
Advanced Member
- Joined
- Mar 5, 2009
- Messages
- 1,530
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:
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:
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.
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
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:
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.
levi
Still fresh, damnit!
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
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
Letalis Sonus
Advanced Member
- Joined
- Mar 5, 2009
- Messages
- 1,530
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.
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.
levi
Still fresh, damnit!
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.
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.
Letalis Sonus
Advanced Member
- Joined
- Mar 5, 2009
- Messages
- 1,530
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.
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.
