If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

But as soon as they distribute a combination linking the GPL-ed Linux kernel together with their closed module, they are in violation of the GPL.

Exactly. They wrote a Linux kernel module and are distributing a Linux kernel with said module. It doesn't matter where the copyright resides, the module became GPL-licensed when they distributed a Linux-derived work.

Open source operating systems that are not GPL-licensed do not seem to have that problem.

Can you point me to another system with anywhere near as many open source drivers as Linux?

And on the flipside Linux has helped the *BSD's by requiring open source drivers as lots of BSD drivers have been reverse engineered from Linux driver source code. Source code which would not have been available had it not been for the Linux kernel developers hard stance on binary blobs.

Reverse engineering against source code is _much_ easier than reverse engineering against a binary black box.

Originally Posted by ryao

If it is fine to be compatible with interfaces, at what point can you call something a derived work if you are able to replace both sides of an interface?

If you implement both sides of an interface then it's not a derived work which is something Oracle vs Google showed, on the other hand if the Linux kernel which is GPL licenced is one side of the interface then unless explicitly stated otherwise it will be a derivative work.

The userspace syscall interface in Linux has an exception that anything using it isn't a derived work, and is free from GPL obligations. It doesn't have this exception for the module interface.

whether its logical or not doesn't matter.

Dave.

You just answered a longstanding question that I had. Thanks.

Originally Posted by XorEaxEax

Can you point me to another system with anywhere near as many open source drivers as Linux?

And on the flipside Linux has helped the *BSD's by requiring open source drivers as lots of BSD drivers have been reverse engineered from Linux driver source code. Source code which would not have been available had it not been for the Linux kernel developers hard stance on binary blobs.

Reverse engineering against source code is _much_ easier than reverse engineering against a binary black box.

I suggest that you read what the OpenBSD developers have to say about Linux and device drivers:

Something that is fairly interesting is that the OpenBSD developers appear to have written a disproportionately large number of reverse engineered drivers, some of which have found their way into Linux. When I say that they did reverse engineering, I mean blobs, not source code. Anyone who claims that people reverse engineer source code has no clue what reverse engineering is, yourself included.

With that said, Linux drivers rarely find their way into *BSD operating systems because of restrictive licensing. The only real exceptions to this are Linux graphics drivers, which are often MIT licensed.

Anyone who shops a prebuilt kernel distributes it, if you build a livecd and give it to your friend you have distributed the Linux kernel.

The debate on the nvidia driver and AFS stuff is borderline, since derived works aren't clearly defined, and generally only a court can decide, and they may take a completely different method of defining it than me or anyone else. Even kernel devs disagree on what constitutes a derived work, and some believe the nvidia driver definitely does.

People have stopped distros and live cd from shipping the nvidia driver on the same media, distros only ship the binary driver separate from the kernel, and cause the user to do the final linking which violates the GPL on that users machine. Also nvidia never distribute the binary driver with a linux kernel attached.

You'll notice for ARM systems most of the kernel drivers are open source for this reason, since they ship them all on one media.

Its not allowed to use the non _GPL symbols unless you are sure your work isn't a derived work, i.e. you have good lawyers who aren't just telling you what you want to hear.

Dave.

Dave, the act of linking does not violate the GPL. The act of distributing something that is linked does. Also, could you define what linking means in this context? As far as I have seen, nothing anyone would associate with a traditional linker seems to be done against the kernel binary until the module is loaded. I did a quick test with a Hello World module:

I would also appreciate it if you would explain how we have an uproar concerning this particular vendor when we have heard relatively little complaint about the numerous other vendors that have been doing this far longer. To cite a specific example, anyone shipping Linux devices using broadcom hardware. If you would prefer, you could talk about this in the context of graphics. There are plenty of Android devices out there with binary graphics drivers being shipped with the kernel. Why is there no uproar over that? Are they not in violation?

I think it's pretty clear.. The company *OWNS* the copyright over the code.

100% true.

Originally Posted by Sidicas

Just because they released a GPL license of it, doesn't mean that their internal proprietary version which contains part of their GPL version needs to be open source.

While that statement is true by itself, that's not the issue here.

The code in question was developed for the Linux kernel, is a Linux kernel module, runs in kernel space, has no use whatsoever without the Linux kernel, and is distributed with a Linux kernel. That makes it a derived work, and as such they agreed to abide by the terms of the Linux kernel license, the GPLv2, which requires that derived works be available under a license compatible with GPLv2.

Dave, the act of linking does not violate the GPL. The act of distributing something that is linked does. Also, could you define what linking means in this context? As far as I have seen, nothing anyone would associate with a traditional linker seems to be done against the kernel binary until the module is loaded.

I would also appreciate it if you would explain how we have an uproar concerning this particular vendor when we have heard relatively little complaint about the numerous other vendors that have been doing this far longer. To cite a specific example, anyone shipping Linux devices using broadcom hardware. If you would prefer, you could talk about this in the context of graphics. There are plenty of Android devices out there with binary graphics drivers being shipped with the kernel. Why is there no uproar over that? Are they not in violation?

Yeah I was only trying to show people why nvidia don't get sued (not distributing a linked object), they actually don't distribute any objects build with kernel headers, they have the user build the files that touch the kernel headers locally. When some distros tried to bypass this and ship a kernel and the final linked nvidia binary, they got told to stop. So yes distributing a linked thing is what triggers the GPL violation. Exactly what consitutes linking is also a bit of lawyer consulation. Currently accepted theory is that creating a kernel module you can load into a running kernel is linking it, again good lawyers might get judges to see things another way.

So the thing is yes there are lots of GPL violators out there, but not as bad as you imply. You'd be surprised how many of the android graphics stacks have fully open source kernel drivers, even if they aren't upstream, they are still released under the GPL, and there are a lot of people doing GPL violation works with those companies in secret.

The reason this one is bigger is (a) it was on lkml, (b) the company alleged to violate also happen to maintain a GPL fork of their code, (c) the company in question stonewalled any polite inquiries in private, (d) it was on lkml. (d) it got into phoronix.

Generally with GPL violations the organisation doing the investigation and the organisation doing the violatiing, talk in private a lot first, and some agreement is hammered out, occasionally it goes to court.

At a guess this one will probably go into the background, until

one of:
a) some rights holder decides to pursue it, whether that be SFLC, Red Hat, or anyone else who holds kernel copyrights
b) the company just releases the source to the bits they didn't before.

Exactly. They wrote a Linux kernel module and are distributing a Linux kernel with said module. It doesn't matter where the copyright resides, the module became GPL-licensed when they distributed a Linux-derived work.

They distributed compiled version of kernel with the module linked in?!

You can also find commits from Apple employees in Clang, CUPS, LLVM, Xorg, WebKit, etcetera. These might not be things that you appreciate, but they do exist and other people do appreciate them. I notice that Dave Airlie is on the forums. You could always ask him about Apple's contributions to Xorg. Of course, that assumes that you actually use Xorg. If you do not, I could understand why you would not care.

I stand corrected.

I assumed that the hostility to FLOSS, displayed most prominently in AppStore cases, was intrinsic to the whole company. Now I can't say there are no contributions, I'll have to say there are no significant contributions ;-)

Exactly. They wrote a Linux kernel module and are distributing a Linux kernel with said module. It doesn't matter where the copyright resides, the module became GPL-licensed when they distributed a Linux-derived work.

The module DID NOT become GPL-licensed, this is a part of the anti-GPL "viral" FUD. You can't relicense other people's code.

What happened is that they violated the GPL at the moment they shipped a combined work which included GPL software. Their options at that point are:

- Stop distributing the thing immediately and lose the right to distribute GPL software in the future, or
- GPL the code they distributed

The module DID NOT become GPL-licensed, this is a part of the anti-GPL "viral" FUD. You can't relicense other people's code.

I had to read this 5 times or so to understand what you are talking about. Simply put, Syke worded it a bit ambiguously and he actually meant "It doesn't matter where the copyright resides, the module must become GPL-licensed when they distribute a Linux-derived work, or else they violate the GPL." No need to make a fuss like that, this is not FUD. Also, there was no relicensing of others' code mentioned anywhere - the module is theirs.