Hacker News Reader

Comment by osivertsson | Hacker News Reader

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.

View on HN

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.

You missed a pretty big part here.

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

The implications of this are pretty broad reaching. I think it'd be amazing if, at the end of this, the VMWare kernels all becoming opensource.

That'll never happen, one can't force someone else to abide by one's license, only force them to stop using one's work and pay damages.

glibc is LGPL, not GPL like the kernel.

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

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

The wrapper is one way to look at it.

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

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

Why is it so important to protect proprietary software companies that infringe on other's copyright?

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?

[1] http://qr.ae/RUortF

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

[1] http://www.nvidia.com/object/unix.html

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?!

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.

They're already not producing for Linux, though; they're producing for themselves and flouting the GPL to expand their market.

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.

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

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 :)

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.

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.

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

And that WOULD impact embedded Linux very much.

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.

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

NDISwrapper?

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

[1] https://lkml.org/lkml/2003/12/3/228

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.

1% would be a massive, massive part of Linux. I'd be surprised to find any one kernel developer that has 1%.

Reply on news.ycombinator.com