Report from the VMware GPL court hearing
laforge.gnumonks.org
laforge.gnumonks.org
[...] the VMware defense in claiming that overall, they could only find very few functions that could be attributed to Christoph, and that this may altogether be only 1% of the Linux code they use in VMware ESXi.
At times their lawyers made statements like linux is this small yellow box in the left bottom corner (of our diagram). So of course already the diagrams are drawn in a way to twist the facts according to their view on reality.
Here's how I see it. Vmkernel has a driver API. It's documented, versioned, comes with a ddk and has drivers written directly to it.
As we all know, Linux basically has driver apis. They are not as explicit as the vmkernel driver apis; they are not versioned and deliberately unstable - but if you've written a line of kernel code you know they are there.
Now it seems it is OK to ship a binary blob driver that links against Linux driver apis. Nvidia, ati, lots of arm type boards and now zfs. I say seems because, well, so far everyone has pretty much gone along with it. In some of the comments on zfs, I see people go as far to say that the Linux driver APIs are tacitly considered lgpl (ie. similar to why you can ship a binary against glibc - although obviously glibc has made the exception explicit)
Can I do the reverse? Implement a GPL licensed wrapper that converts the Linux driver API to one provided by a binary blob (ie. what vmklinux does talking to vmkernel) and thus use the drivers?
I don't know, I think it's a good question to find an answer to.
OpenZFS and Nvidia are modules of the kernel, they use the exposed API. OpenZFS is fully open source, with an incompatible license. Nivida's graphic driver has a GPLed portion that it's binary blob loads into.
OpenZFS is may be only considered derivative, because when it compiles, it has to include the kernel header files, because that is how you compile C code. No part's of its code base infringe on linux's and no part of linux's code base infring on OpenZFS's. Just the compile binary might be infringing. However this has implications that are far reaching, as if this is considered derivative. GLIBc is GPL, does that mean everything compiled against GLIBc are derivative of GLIBc? If so, this means a great many things are legal required to be GPLed and code shared.
Back on topic, in the case of VMWare, the claim is that they are actually using GPLed linux code in their code. Much more than using the exposed API. This one should be an open shut case.
There seems to be some thought that vmware are idiots and copied a bunch of Linux code and didn't release it. It's more about when something becomes a derivative work. Much more subtle
The GPL wrapper method has long been considered to be a subterfuge that GPL lawyers think judges would be able to see through.
https://www.gnu.org/licenses/gpl-faq.html#GPLWrapper
As to the rest of your questions, this is how Conservancy answers them. The situation is more nuanced for vmkernel as compared to the nvidia blob.
https://sfconservancy.org/copyleft-compliance/vmware-lawsuit...
Another might be about reimplementation of APIs. The binary blobs could be evidence there is an API (even if you say you don't support it). If I reimplement it, is it derived?
So yeah, it's nuanced ... Otherwise I guess it would never have got so far
However, the GPL lawyers don't want to press the point too hard as they could easily lose a lot of hardware that would quickly render Linux useless.
If nVidia, for example, got scorched by the GPL and started releasing binary-only drivers only for FreeBSD, Linux would start losing a lot of corporate seats.
Linux would be hurt more by nVidia's absence than nVidia would be hurt by Linux's absence.
Linux could disappear tomorrow, and there are plenty of free Unix-like alternatives that easily fill the void.
If nVidia disappeared tomorrow, there are lots of Linux contracts that would simply stop (and most likely switch to Windows).
Now, you can argue ideologically, but part of the reason why Linux is popular stems from the fact that Linus was more pragmatic about licensing rather than RMS' dogmatism.
If you want to see what a world with a strictly enforced GPL without modules looks like, look at the device support for OpenBSD. A lot of Linux folks would be very upset being limited to that set of peripherals.
Maybe for the desktop, but not overall: Nvidia is heavily pushing supercomputing/machine learning and it can't afford to ignore Linux in this space (since Linux dominates).
If Nvidia were to abandon Linux, they would be gifting AMD a free come-back opportunity.
If for some reason supercomputer builders could no longer use the best GPUs in supercomputers, would they stick with Linux or would they follow the hardware and switch to a ⋆BSD on the compute nodes?
I have no idea what the answer would be, but my guess is it would hinge on 1) AMDs reaction, and the performance hit (if any) of switching to AMD GPUs on Linux and 2) the performance hit (if any) of switching the OS to *BSD
Going with second rate option simply doesnt work when you're spending hundreds of millions per machine on the high end.
I mean do you really think it told really be easier to port a thousand heavily optimized applications/libs CUDA to OpenCL than the handfull of librsties that dont alrady work with BSD from Linux?!
Would this actually happen? Would it effect Linuxes popularity? That's harder to predict.
What makes this different IMO from VMWare is that they are not creating a work that exists purely b/c of Linux, instead they a making a piece of software that allows their hardware to work with a Linux based machine.
I think those are two very different types GPL violation. One really does flout the GPL and exploit Linux kernel devs, the other I think is generally viewed as an enhancement to Linux, thus less interest in fighting it.
Hyperbole aside about how Linux would be useless without nvidia blobs, the situation with nvidia is not about a mere GPL wrapper. The nvidia blob is using parts of the Linux API for which the Linux API explicitly declares "there's no GPL here". This declaration is enforced via C macros.
Linux is extremely pervasive by now: embedded systems, phones, laptops/desktops, servers, super computers. Let's say NVIDIA boycotted Linux on account of the GPL. No more NVIDIA for Linux-based embedded systems, phones, laptops/desktops, servers, supercomputers. What then?
It certainly wouldn't make a dent in the embedded space, where NVIDIA hardly has any presence at all, even if you do include NVIDIA Shield. On the phone side, how many of the 1+ billion Android devices use NVIDIA chips? 1 million? 2?. It certainly wouldn't make a dent in the server space -- the market for GPGPUs on regular servers is rather tiny. In the supercomputing space, there's a trend towards more GPGPU capabilities, so here it might actually make a difference for some. Still, seems somewhat unlikely that lack of NVIDIA support would "quickly render Linux useless" as a supercomputing OS...
That leaves the laptop/desktop space. Linux has around 2% market share on the laptops/desktops. Most people in that space who need rock-solid 3D performance for CAD/CAM work are already using Windows. Sure, there are still die-hard NVIDIA Linux users left, even after everyone decided to transition to MacBooks and OSX for development, but their number hardly qualify as "lots of corporate seats".
All of that being said, I'd love for additional uptake of the *BSDs, in addition to the ~30 million PS4s running FreeBSD :)
Sure it might not be the end of the world for many existing applications but think of the new/growing growing markets they basically control right now - deep neural networks, car automation, photorealistic offline rendering, accelerated simulation, accelerated HPC, gaming etc.
With the interest and demand from all those and potentially other segments like say Android could be enough to push BSD ahead of Linux in a few years and be absolutely crippling for the future prospects of Linux.
It'd basically be like GCC vs Clang all over again.
The embedded space follows Linux because their alternative desktop was Linux (if it wasn't Windows).
You assume that a GPL slapfight only takes out nVidia. It would take out lots of people who have binary-only drivers who currently make Linux their home. The WiFi manufacturers being some of the most important ones.
And that WOULD impact embedded Linux very much.
Nobody has actually tried to legally challenge the GPL via a GPL wrapper, so there's nothing to enforce yet. It seems like there's widespread consensus that a GPL wrapper wouldn't work. Indeed, if it did work, it would make copyleft utterly pointless. Just write a simple wrapper around any GPL library you want and no more copyleft.
The situation with nvidia and VMWare is not about GPL wrappers.
NDISwrapper?
Several copyright holders in the kernel are on the record that what Nvidia is doing is not ok. Linus himself is known for some harsh words.
In theory you only need one who is willing to put up a fight. Your business model should not depend on winning a court case concerning the actual license as it is put in print. It should be based on you not going to court at all, by not doing things against the copyright holders wishes.
Other kernel devs indeed claim that everything that links with a kernel is a derivative work and EXPORT_SYMBOL / EXPORT_SYMBOL_GPL distinction means nothing.
I can prove without a fault that the most code running on my server is the kernel. I can also prove that its the least significant code in the system. Counting cycles, the kernels idle function runs often at 99%. Counting bytes stored on the disk, the kernel is just a few MB in a vast sea of TB's of data stored and thus are far less than 1% of the machine. In terms of cognitive thinking, the machine could be described as a Linux box, a Debian machine, a GNU/Linux system, or a webserver, each attributing different independence to the kernel running inside. In terms of user-interaction, the kernel barely exist and I rarely ever interacts with it. In terms of executable binaries that I run, most have a larger number of syscalls in them.
The statement that "the diagrams are drawn in a way to twist the facts according to their view on reality" is a perfectly unbiased. If I were at a court and saw a diagram being presented by a party, I would by default distrust it and wonder what the actually data say.
This doesn't even get into "linkage". They're almost certainly using huge chunks of Linux code wholesale.
A key argument I was missing in the article here was the question about market impact. In every court case I have read that talked about derivative works, they always considered the impact that the claimed infringement has on the original work. Court seems to have a historical viewed that copyright is there to protect the authors, and thus leans towards decision that minimize harm. In the case of VMware, it would be interesting to see such arguments from both parties.