Debating Continues Over Possible Kernel GPL Violation

[Zardoz]

Why would they as a company develop something that was not useful to them?

There's a big difference between not useful to them and useful just for OSX. Valve helping driver development is not useful just to Valve, while Apple contributing a BSD licensed Objective-C wrapper to KHTML is useful just to Apple.

[Syke]

Some people believe that their code will become automatically GPL licensed if they touch GPL software. I don't know how Syke meant it, but Microsoft and others have been running a FUD campaign about "viral" GPL relicensing your code for many years now.

If you create a GPL-derived work, you either GPL your modifications, or you are in violation of the GPL. They can keep their code non-GPL, but the consequence of them doing so puts them in violation of the GPL and the holders of the Linux copyrights will terminate their license to distribute Linux.

[XorEaxEax]

Actually it's the GPL's hostility to DRM that prevents it being published. Other FLOSS licenses don't have a problem with it.

Well obviously GPL is incompatible with DRM as GPL explicitly state that you may make as many copies as you want of said software while Apple enforces an artificial limit on how many copies you may make.

Still Microsoft solved this by simply stating that an OSI licence will take precedence over Microsofts own licence terms in their app store, so GPL is no problem there. Apple could do the same but they haven't.

[XorEaxEax]

Actually Apple forked khtml and created Webkit where the changes appear in a timely manner.

erhm...
http://appleinsider.com/articles/11/...evelopers.html

[squirrl]

"Quick put a hundred in the box, we need to grease the snitch!"

--southpark

[ryao]

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.

Dave.

I took a second look at the Android graphics stack situation, specifically with regard to my LG Optimus V. It seems that the userland drivers are blobs. It also seems that the bit needed for video acceleration is a blob. Various Android hackers have claimed that it is a kernel component, but none of them have replied to my requests for information. These were not recent requests. After your reply, I poked around to try to find out what they did not tell me, but unfortunately, the graphics stack is not my area, so that did not end well. Anyway, you are right that things are not as bad as I made them sound. However, we still have blobs in the graphics stack and they are still a pain. As far as I know, few of these companies have released programming documentation, so even if we did have source code, most of us would be unable to do anything more than trivial fixes. Programming documentation is what we really need, but sadly, no license requires that. I am not even sure if it is possible for a license to require it.

I did look into the reported matter a little more. First off, when companies refuse to release source code, it is usually because they would lose customers if others could review the code. In this situation, the code involved has an open source version called LIO (as was reported) and unfortunately, LIO appears to lack barrier support. I examined the code earlier this year after a user in IRC reported data loss and I could not find any hint of barrier support. Maybe I did not look hard enough, but I read enough code to convince myself that it was not there. Unless I am wrong, anyone using LIO is putting their data at risk until barrier support is implemented. Anyway, Redhat feels that the proprietary version puts them at a disadvantage, which is the only reason anyone cares:

http://www.muktware.com/4820/red-hat...e#.UKR8n5tssjN

With that said, it would be nice if someone would get programming documentation for the networking hardware used by the Asus RT-N66U. I know for a fact that it uses a binary kernel module because I spent days tearing apart the published firmware in an attempt to port Gentoo to the router. I shelved the port because hacking around the 11MB binary blob took too much time. As I recall, the blob required special attention from userland in order for the networking stack to function properly. I doubt that I would have time to fix something that broken even if I had the code. Programming documentation would be nice because then multiple people could work together to make something that I could package in Gentoo without breaking virtually every QA rule that I know.

[Ansla]

If you create a GPL-derived work, you either GPL your modifications, or you are in violation of the GPL. They can keep their code non-GPL, but the consequence of them doing so puts them in violation of the GPL and the holders of the Linux copyrights will terminate their license to distribute Linux.

You don't have to GPL your modifications, you can release them under any FSF aproved licence. That includes some BSD licences among others.

[LightBit]

You don't have to GPL your modifications, you can release them under any FSF aproved licence. That includes some BSD licences among others.

But you can't use any other copyleft license (like CDDL).
And compiled binary is under GPL.

[Ansla]

There are LGPL and eCos that are copyleft and compatible with GPL.

LE: about the "compiled binary", if you are refering to a distinct kernel module or so, then no, it's under the license you choose, if the code you wrote is linked togheter with the GPL code the resulting binary is under BOTH lincences.

[Ex-Cyber]

You don't have to GPL your modifications, you can release them under any FSF aproved licence.

Any GPL-compatible license. The FSF does approve of some GPL-incompatible licenses under some circumstances (e.g. for APSL 2.0 "We recommend that you not use this license for new software that you write, but it is ok to use and improve the software released under this license.").