Some quotes that I feel shows VMware's attitude towards the software freedom community:
[...] 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.
Using diagrams and graphs to distort data has been utilized for such a long time that seems hard to find cases where it was correctly used to help understanding data. I even know a famous Swedish sketch (and accompanying song) that has misrepresenting diagrams as its central theme.
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.
What did you expect them to say? Linux is a huge part of what we do?
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.
> 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?
The GPL wrapper method has long been considered to be a subterfuge that GPL lawyers think judges would be able to see through.
> The GPL wrapper method has long been considered to be a subterfuge that GPL lawyers think judges would be able to see through.
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.
Not sure I'm able to follow your logic here, esp regarding "quickly render Linux useless" and "losing a lot of corporate seats".
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 :)
Most independent people who need 3D performance for CAD might be using Windows, but the VFX industry need 3D performance on the desktop and they heavily use Linux and NVIDIA (at least at the high level). AMD is almost nowhere to be found - it's all CUDA (for any GPU compute stuff) and NVIDIA's drivers.
Losing the market leader for GPUs at a time when accelerators have almost become mainstream absolutely massive.
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.
> It certainly wouldn't make a dent in the embedded space
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.
> 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.
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.
I think his point is that if the nvidia company felt threatened by Linux, then they would immediately stop producing for Linux. In which case the Linux ecosystem would shrink, and the platform would become less useful.
Would this actually happen? Would it effect Linuxes popularity? That's harder to predict.
Are they really flouting the GPL though? I think you could make a better case that SteamOS is, with an integrated Nvidia driver.
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.
They're flouting the GPL in the sense that they produced a binary-only driver enabled by a compatibility layer released under GPL that, in my uninformed opinion, probably violates the GPL. It still doesn't do me any good, though; I'm on my second laptop with Optimus graphics, and they're just not going to make their hardware work on this machine when it's not running Windows. Fortunately, I only need 3D acceleration when I'm gaming, and the machine came with a Windows license, so dual-booting is an option for me.
Leaving aside the fact that this isn't really settled legal theory...
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.
> Linux would be hurt more by nVidia's absence than nVidia would be hurt by Linux's absence.
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.
What if Nvidia provided good ⋆BSD drivers? According to the answers from Greg Lindahl and Eugene Miya on Quora to the question "Why is the OS landscape of Supercomputers dominated by Linux instead of BSD?" [1] the Linux dominance is largely an historical oddity rather than due to some inherent superiority of Linux.
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?
>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
NVIDIA does produces drivers for FreeBSD[1]. I don't know if they're considered "good" or not, but they definitely aim to have the same features and quality as on Linux.
I think you vastly underestimate how far those guys would go to eek out every last bit of practical performance.
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?!
If "GPL lawyers" think that, where are the enforcement actions? When lawyers say they believe things about the law but aren't, it -- as the SF conservancy itself pointed out in their statement on the Canonical ZFS issue -- often represents what their clients have an interest in people believing about the law more than anything else.
> If "GPL lawyers" think that, where are the enforcement actions?
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.
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
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.
Glibc is a bad example, as they have explict linkage exceptions
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
>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?
> Now it seems it is OK to ship a binary blob driver that links against Linux driver apis. Nvidia, ati,
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.
Actually, if I understand what Linus says here[1] correctly, porting modules from other OSes to work with linux seems to be ok, writing closed source modules specifically for linux kernel is not ok. But overall still a gray area.
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.
One should make a graph showing man years put into each part and see how big the kernel would be compared to the wmware parts. It would most likely paint a completely different picture and also show the importance of that 1 percent of the plaintiff.
They're definitely obfuscating the amount. If it were just a couple of functions that could be ripped out and rewritten, VMWare would have done it long before this hit court.
This doesn't even get into "linkage". They're almost certainly using huge chunks of Linux code wholesale.
Considering that there are definitely more than a hundred major contributors to the Linux kernel, it's not unreasonable that a single one's contributions only make up 1% of the total.
I am not really up to date on this case. Why is Christian sueing for just the copyright infringement of his contributions? It sounds like this 'fading' concept might really put a stop to this whole trial. Wouldn't it be possible for Christian to represent more Linux developers so their collective work sits comfortably above 1% of Linux?
There is no class action in german law. Everybody has to sue on their own (with very few exceptions), but of course there is no point in having (and funding) multiple identical cases unless this case gets dismissed for a technicality like the fading issue.
Just to add: If similar lawsuits are anticipated or the question is seen as important courts usually give they opinion on what criteria to use to judge other cases. So even if this one is lost due to technicalities we will likely learn more about this legal question.
This is just an excellent summary of events so far, and the court proceedings. I'm looking forward to more analysis as the case proceeds. It's interesting to come at it from a long-time Linux user perspective -- it seems incontrovertible that GPL is being violated to me -- so I'm most curious how this winds its way through the courts.
It will be interesting to see how the court will determine if its one work or two separate works, and if they will look at other copyrighted media. There is already a rather established model for music video, where even if you have rights to distribute a particular song, you need additional rights to adapt the music to moving images. On the other side of the argument, there is cases that has addressed compatibility. There were for example gaming consoles that had unlicensed third-party modules that courts deemed to be non-infringing.
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.
[...] 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.