Debating Continues Over Possible Kernel GPL Violation

[Nuc!eoN]

I think "GPL nazis" is a very fitting description in this case. Actually I really like the GPL license because it lets software be free and remain free. However I think that these accusations would neither be in the sense of the Free Software Foundation - or at least my understanding of freedom, nor will Linux benefit from such extremistic behaviour. The GPL was made for freedom - not for restriction, or even hindering development as is the case here. I think it is obvious that VMware uses this code for compatibility reasons: they need this code to better interact with the kernel. In the USA and Europe, there is a clause assuring that decompiling proprietary software (even if forbidden explicitly in the license) is legal, as long as the code is used to assure interoperability with the decompiled software. I think this exeption also very similary applies to the situation VMware is in. However in this case, the software (the kernel) isn't even proprietary but claimed to be free.
But isn't that shocking?! On and on, free software fanatics critisize Microsoft for their immoral, restricting policy. But now, they are doing the exact same thing to VMware: Hindering proper development. They are dissapointing my dreams

The GPL is not meant to be used as a "patent" - meaning hindering proprietary softwares development, but rather supporting free software.

Unfortunately some people always get it wrong, people that do not see the world from human (social) eyes, but lawyers (cold, merciless, unbending) eyes and the consequences are plain -> Oracle, GPL licensed "Liberation" fonts, patent accusations all over the world .......... Well, but thats a social problem.


Should this really come in before court, I hope that the Free Software Foundation comes to similar conclusion and in this case makes an exception, as they are allowed to do (aren't they?).

best regards
Nuc!eoN

[Sidicas]

And people wonder why we have binary blobs. No sane person would contribute code if doing so implies surrendering any rights that they can reasonably expect as a copyright owner. Incidents like this are a great way to drive companies either away from Linux or toward creating binary blobs.

I think it's pretty clear.. The company *OWNS* the copyright over the code. 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.

The Red Hat developer made a mistake in his claim.

QT was dual-licensed for a long time, they had a proprietary license and a GPL license. If you didn't want to deal with the restrictions of the GPL license, you could pay money and get a proprietary license which, ironically, gave you more freedom to do whatever you liked with the code. Specifically including, keeping derivative works CLOSED source which the GPL does NOT allow you to do.

If you own the copyright to something, you're welcome to license it out any way you like, under as many licenses as you like. *INCLUDING* keeping a proprietary licensed version in house that they have no obligation to release the source code to.

The GPL has no strength against the original copyright owners of the work. This is where the Red Hat developer goofed up his claim.. The GPL only applies to people who DO NOT have copyright over the work. That is why it is called a "license". If you have a sole copyright over the work, then you sure as hell don't need a license as you can do whatever you like with it since it's yours.

[bridgman]

That's why the LGPL was created and why many OSS libraries use LGPL instead of the GPL.

There is also an explicit exception in the Linux kernel's GPL license allowing applications to access kernel functions via normal system calls without being considered derivative works of the Linux kernel.

[airlied]

I think it's pretty clear.. The company *OWNS* the copyright over the code. 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.

The Red Hat developer made a mistake in his claim.

QT was dual-licensed for a long time, they had a proprietary license and a GPL license. If you didn't want to deal with the restrictions of the GPL license, you could pay money and get a proprietary license which, ironically, gave you more freedom to do whatever you liked with the code. Specifically including, keeping derivative works CLOSED source which the GPL does NOT allow you to do.

If you own the copyright to something, you're welcome to license it out any way you like, under as many licenses as you like. *INCLUDING* keeping a proprietary licensed version in house that they have no obligation to release the source code to.

The GPL has no strength against the original copyright owners of the work. This is where the Red Hat developer goofed up his claim.. The GPL only applies to people who DO NOT have copyright over the work. That is why it is called a "license". If you have a sole copyright over the work, then you sure as hell don't need a license as you can do whatever you like with it since it's yours.

Ah good a GPL expert in the house. not one thing you said in that is true. No wonder people are confused about the GPL with idiots like you trying to explain it.

If I take the Linux kernel and I write any code that requires the Linux kernel, then that code needs to be under the GPL. It doesn't matter a shit if I have all the copyrights or not.

This isn't like QT, or mysql.

The GPL has plenty of strength against the original copyright owners of *derived* works. Could you shut up now and stop thinking you understand something you clearly have no idea about.

Dave.

[airlied]

So, the caveat is that since their product won't run using a generic kernel, the kernel they ship must include non-disclosed modifications. Did I understand that correctly?

No nothing to do with generic kernel, or products.

If they write code that the kernel userspace GPL exception applies to, all good, if they write code that links to the kernel via modules, then they are in derived work territory. If they then distribute that work (GPL only applies to distribution), you have the makings of a GPL violation.

Dave.

[airlied]

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

That doesn't make much sense to me. There are plenty of examples of programs such as HTTP servers and FTP servers being developed as kernel modules. Linux is an oddball in that its developers are fairly hostile to this practice, but writing programs as kernel modules is a legitimate use case and it is not fundamentally different from writing programs that rely on the syscall interface from the perspective of theoretical computer science. You still have code running on a CPU and some kind of monitor that provides services so you don't have to write drivers for them. The advent of virtual memory made it somewhat easier to make a distinction and people have tried to enforce it through licensing semantics, but I do not see a theoretical difference. Law is rarely logical so theory might not help the legal situation, but I am more concerned with theory in this instance.

With that said, I consider the concept of a derived work to be questionable in the context of the Google versus Oracle lawsuit and concepts such as ReactOS. 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? Granted, you do not always have the other side of the interface implemented, but the logical necessity of this seems similar to the necessity of displaced water when demonstrating the buoyant force. FreeBSD's kernel does implement some Linux kernel interfaces. Had the company in question foreseen this situation, they could have done their work on FreeBSD and produced either the same result or a similar result for Linux.

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.

[airlied]

Sorry if that may sound stupid but wouldn't that mean that if a GPL application links against a non-GPL application/library it would violate the GPL? Or is this a one-way thing?

Maybe a bad example, but: as soon as a non GPLed program uses a GUI it links against X, which is MIT, so no problem. But as soon as I start a GPL program with a GUI it links to X, too. So both, the GPLed and non-GPLed are indirectly linked.

But you name it: GPL doesn't allow non-GPL code to link against it. Let's remember that for later[¹].

Is this really legal or do you just not care / can't do anything against it?

Do they? What is this product you are talking about? Again: I thought kernel.org and distributions like Debian, Ubuntu, ... distribute the kernel.

Maybe:

I don't know the kernel interfaces nor BSD good enough so I can't tell if BSD has _all_ they need, but, well, ...

Yes, but every app has this to some point, else devs would write Windows apps.

Much more important for me: When they asked for inclusion, did they tell that codes where copy&pasted from the proprietary version? The phoronix article isn't clear about that but it almost reads like so.

Which they told they did not. Of course many people say much all the day, but there isn't more they can do atm, or is there?

the phoronix article reads like they don't know:



Well... Now I see you drawing a line. Why exactly there?
Yes, the nVidia driver was build from the windows driver, but what makes this a real difference? It's still violating the GPL if I understand you correctly. Also it clearly couldn't be used as is for the linux kernel. All changes have been made to make it a derivative work of the kernel and nVidia knew exactly what they did. The step to port it to linux was made with the same minds/thinkings/feelings/whatever Rising Tide Systems had when creating this SCSI thing. So why not sue nVidia and every distribution shipping their driver? Would make more sense then all that "Fuck you nVidia!" hype last time.
And for AFS: So if I build a table and after that you finished the chair for your table I'm allowed to steal it cause "my table was first, so I clearly didn't steel your chair for it".

What? So it's not allowed to use non_GPL as long as your code doesn't grow to much? That doesn't make any sense at all[¹].


BTW: Don't get me wrong, I don't want to be rude, I just want to understand better and am tired like hell, so if something sounds more rude than it should I'm sorry.

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.

[89c51]

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.
.

How they get away with the Graphics drivers?? Are they implemented in userspace -thats OK i think right?-

ie smartphone makers put the whole thing (kernel, 3d gpu drivers etc) in the phone.

[airlied]

How they get away with the Graphics drivers?? Are they implemented in userspace -thats OK i think right?-

ie smartphone makers put the whole thing (kernel, 3d gpu drivers etc) in the phone.

They implement a lowlevel GPL driver to control the hardware, and put the major pieces in userspace, to which the GPL doesn't apply.

But thats pretty much how all GPU drivers are done on any OS, in terms of functionality placement.

There are arguments that the userspace driver in a lot of these situations could still be considered a derived work of the kernel, and a good lawyer might even convince a judge.

(the userspace exception clearly states things that interact via normal syscall interface, drivers generally use driver specific ioctls that could be argued to be non part of the standard syscall interface).

Dave.

[pingufunkybeat]

I think it's pretty clear.. The company *OWNS* the copyright over the code. 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.

So far so good...

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.