Debating Continues Over Possible Kernel GPL Violation

[bug77]

They developed code against the kernel and ship a kernel and that code together to make their code work.

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?

[ryao]

Well if they have written the code from which they created their proprietary version all by themselves then they certainly have the rights to provide that proprietary version and continue to develop it as such, they can also re-licence it under other terms, it's all within their rights as in this case the code are theirs alone.

However, if they are shipping the proprietary version as part of a Linux kernel to third-parties then they are in breach of GPL as their code is then a derivative work, this is not some new concept and it's very well understood.

Looking past the stupidity (imo) of trying to make a business out of shipping proprietary components for inclusion into the GPL licenced Linux kernel, it seems that they didn't even write all the code themselves to begin with, which would make this 'debate' entirely pointless.

Your scaremongering of companies leaving Linux or turning to binary blobs betrays your dislike of the GPL as it's entirely illogical, if it wasn't for GPL preventing their inclusion into the kernel we'd have tons more binary blobs and far fewer open source drivers.

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

So, what did BSD ecosystem get from Microsoft for using BSD TCP stack code in their systems?

Compatibility.

Good code should remain free. Just look at the amazing contributions by Apple back to BSD community... Oh, wait, there are none.

http://opensource.apple.com/

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.

Its not like mysql which was a standalone application. They developed code against the kernel and ship a kernel and that code together to make their code work.

whether they put that code into kernel at all doesn't matter.

whether it uses _GPL APIs doesn't matter at all (these are pretty meaningless).

All that matters is if they shipped a linux kernel and their closed code as a single product, which they did, which is generally seen as a GPL violation.

Dave.

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.

[ryao]

To expand on what I said, if shipping a linux kernel and their closed code as a single product is a violation, then I can point to nearly all Linux devices on the market as also being in violation. You can find blobs in them in one form or another. If those are considered violations, I would have to question why people are crying foul about a recent violation by a relatively obscure company when there are many larger companies that have been in violation much longer. If you narrow the definition of a violation to shipping their blob as a non-firmware/initramfs part of the Linux kernel and it can be stated that they did that, then I could see a violation without claiming that virtually everyone else also violates.

That is probably more relevant to Dave Airlied's comment than my philosophical tangent, but I am more interested in the philosophical aspects of this than the legal aspects. :/

[ArchLinux]

For the past few days there has been a much-viewed and very polarized discussion happening on the Linux kernel mailing list about a possible GPL violation within the Linux kernel.

This makes it sound like it's an _upstream_ issue when in fact it's the RTS OS kernel that's being accused.

And the GPL nazis are at it again! Good code is what matters, join BSD.

Like hell they do. Grow up.

[TAXI]

mysql created a complete codebase, and released it under two licenses. GPL and proprietary. the GPL is concerned with derivative works and linking of things together mostly.

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?

So company who wrote and owns copyright on mysql distributes it without linking to any other GPL thing, all good, releases plugins that link to proprieatry all good also.

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[¹].

If they don't ever distribute that work then thats fine.

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

The company distributes that work to others in a product which contains a linux kernel and that code, then the question of it being a derived work comes into play.

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

Does the code standalone from the kernel? can it do anything without the kernel being linked with it?

Maybe:

]FreeBSD's kernel does implement some Linux kernel interfaces

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

does it have a history preceeding it being developed with the kernel.

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

Now the secondary issue is the company took a large chunk of the code they wrote and licensed it under the GPL, and got it included in the kernel, however this has no bearing on whether the original work they did is a derived work of the kernel and thus covered by the GPL.

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.

The final issue is if they took back changes made to the GPL licensed version from upstream kernel devs and merged them into their secret one. That would lead to a second GPL violation, separate from the first one.

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?

_GPL is mostly meaningless and companies hiding behind it should have a very good idea about what constitutes a derived work of the Linux kernel,

the phoronix article reads like they don't know:

For our commercial target core, we only use Linux kernel symbols that are not marked as GPL.

some examples:
nvidia binary driver - since its built from a codebase that existed outside the kernel, their Windows driver its difficult to assert it as being a derived work.
andrew file system - this FS pre-existed Linux, so it is most clearly not derived.

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

_GPL was meant to help people with those sort of use cases, but not for somone who wrote a large body of code that relies on the kernel to be useful at all.

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.

[pingufunkybeat]

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?

Only if the license is incompatible with the GPL.

Proprietary software linking against a GPL library would violate the GPL. Software under the BSD, GPL, and other compatible licenses wouldn't.

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

I thought kernel.org and distributions like Debian, Ubuntu, ... distribute the kernel.

They do, but there is no license violation because they don't distribute incompatible derivative code together with it.

Firmware (as unfortunate as it is) is a different situation. It is completely unrelated to the Linux kernel, was written to be generic, and doesn't need the Linux kernel for anything. And it runs on a different device altogether. It doesn't link against the kernel in any way, all the interaction is through a stable interface, also used by other kernels.

[solo2101]

Which is evident with the lack of Linux developers compared to other systems??? Your trolling is exceptionally weak.

who says im trolling???...

[ArchLinux]

who says im trolling???...

I think he did.

[solo2101]

I think he did.

I think you are right...

[Temar]

A Linux developer from Red Hat has accused a fellow kernel developer of his company violating the GPL.

That would be his last work day in my company.