VMware update to GPL-enforcement suit
On March 5, 2015, Software Freedom Conservancy (SFC) announced a lawsuit in Germany, filed by Christoph Hellwig against VMware, alleging a failure to comply with the General Public License (GPL). We believe the lawsuit is without merit, and we are disappointed that the SFC and plaintiff have resorted to litigation given the considerable efforts we have made to understand and address their concerns. We see huge value in supporting multiple development methodologies, including free and open source software, and we appreciate the crucial role of free and open source software in the data center. In particular, VMware devotes significant effort supporting customer usage of Linux and F/OSS based software stacks and workloads." LWN recently covered the lawsuit. (Thanks to Emmanuel Seyman)
Posted Mar 10, 2015 23:30 UTC (Tue)
by juliank (guest, #45896)
[Link] (4 responses)
Posted Mar 11, 2015 0:45 UTC (Wed)
by ejr (subscriber, #51652)
[Link] (3 responses)
Posted Mar 11, 2015 0:47 UTC (Wed)
by juliank (guest, #45896)
[Link] (1 responses)
Posted Mar 18, 2015 4:51 UTC (Wed)
by ploxiln (subscriber, #58395)
[Link]
If you're a company and you get sued, you get legal counsel. If you get legal counsel, they say "we believe this case is without merit". There is no conditional here, it doesn't matter what the company or lawyers really think, this is what they have to say. It's their job, it's how the system works. So it's meaningless.
Posted Mar 12, 2015 12:18 UTC (Thu)
by jhoblitt (subscriber, #77733)
[Link]
It would be a hard sell that use space component of GPFS is a derived work of the kernel. GPFS is currently supported no Linux, AIX, and Windows. It is also merely a re-branding of MMFS which (all GPFS porcelain commands are prefixed `mm...`), which I believe predates the existence of the Linux kernel.
Posted Mar 11, 2015 1:47 UTC (Wed)
by ThinkRob (guest, #64513)
[Link] (5 responses)
But as I said, that's just the cynic in me. ;)
Posted Mar 11, 2015 2:19 UTC (Wed)
by flussence (guest, #85566)
[Link]
Carrying on like this for *eight* years doesn't constitute a "considerable effort to understand" or anything resembling good faith in my book. Seems more like a considerable effort to stonewall, and I'd hope the penalties are proportional to 8 years of massive, wilful copyright infringement — if that turns out to be the case.
Posted Mar 11, 2015 8:07 UTC (Wed)
by oldtomas (guest, #72579)
[Link]
The realist in me thinks that the cynic in you is spot-on :-(
Posted Mar 11, 2015 12:17 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link]
Posted Mar 11, 2015 16:00 UTC (Wed)
by ssmith32 (subscriber, #72404)
[Link]
Posted Mar 12, 2015 11:56 UTC (Thu)
by dunlapg (guest, #57764)
[Link]
VMWare isn't a sketchy fly-by-night operation, or a front for some other company like SCO. They're a massive publicly traded company with billions in revenue; they have a lot to lose from being wrong. They have lawyers, and you can bet they're good ones. If they haven't budged, it means that their lawyers think they're on sound legal ground.
From what I understand, the basic problem is that there is not a clear definition -- either in the law or in case law -- about what it takes to be a "derived work". The GPL FAQ makes a simple rule, and says if it's in the same address space, then it's a derived work; if it's in a different address space, it's not. But lots of people (Linus Torvalds and Lawrence Lessig for example) think that's too simplistic.
I think both sides are honestly convinced that they are correct and have been behaving above board. The fact is that the law isn't yet clear; which is why it really needs to go to a court.
Posted Mar 11, 2015 2:40 UTC (Wed)
by joshuagay (guest, #88423)
[Link] (1 responses)
Posted Mar 13, 2015 9:49 UTC (Fri)
by rdnetto (guest, #101489)
[Link]
Posted Mar 11, 2015 7:29 UTC (Wed)
by eru (subscriber, #2753)
[Link] (40 responses)
Posted Mar 11, 2015 7:51 UTC (Wed)
by ledow (guest, #11753)
[Link] (30 responses)
VMWare. nVidia.
Posted Mar 11, 2015 7:59 UTC (Wed)
by eru (subscriber, #2753)
[Link] (23 responses)
Posted Mar 11, 2015 9:15 UTC (Wed)
by vapier (guest, #15768)
[Link] (22 responses)
there have been cases in the past where distros did livecds that included the precompiled nvidia.ko and they got into difficulty. pretty sure this is how Ubuntu/etc... also work -- you get the source, and it's compiled on the fly on your system for you.
also similar to how adobe flash was packaged in the NPAPI days -- the distro distributes an installer script that automatically fetches & installs the plugin from Adobe.
Posted Mar 11, 2015 9:57 UTC (Wed)
by ledow (guest, #11753)
[Link] (21 responses)
As such, this could be quite bad for VMWare AND nVidia, OR the consumer (where nVidia realise they don't have to do things this way). Although the technique is different the boundary between the code licences is essentially the same.
Posted Mar 11, 2015 19:39 UTC (Wed)
by jwarnica (subscriber, #27492)
[Link] (20 responses)
*Having* a stub means that the .ko can interface with *many* kernels with only a very small external interface that needs to change. ISTR that, allegedly, the .ko was, in fact, largely the Windows driver. Which can't be literally true, but there isn't any doubt that there is a bunch of stuff done in software that you think is hardware. Or at least header files for data structures.
Posted Mar 11, 2015 20:28 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (18 responses)
I think the thing there, is if the software house is clearly going through the pain of avoiding the GPL, that's okay, not least because it's obvious to the user that that is what is happening.
The VmWare thing certainly looks dodgy to me - linking vmWare proprietary code to a vmWare GPL shim (clearly legal) to other peoples' GPL code - very definitely a lawyerly attempt to get round the clear intent of the GPL.
Cheers,
Posted Mar 12, 2015 11:02 UTC (Thu)
by SLi (subscriber, #53131)
[Link] (17 responses)
It speaks about derivative works (which is everything it can restrict anyway). Whether the scenario you describe creates a derivative work is an unanswered legal question. I think the only thing that is safe to say is that it most certainly will not be as simple as "whether X links to Y" or who does the linking. Instead the territory will likely be charted on a case-by-case basis and it most likely will not end up being a bright line.
Posted Mar 12, 2015 15:10 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (15 responses)
There's also no question that it IS a derived work.
nVidia does not distribute other peoples' GPL'd code therefore there is no copyright violation.
The END USER creates the derived work, and the GPL explicitly states that what the end user does is of no concern to the licence.
Of course, the result cannot be distributed, that *would* be a GPL violation, but the whole point of the nVidia dance is to avoid said distribution.
The vmWare thing seems to be different ...
Cheers,
Posted Mar 15, 2015 20:10 UTC (Sun)
by xtifr (guest, #143)
[Link] (14 responses)
Argued like a programmer. Unfortunately for the overly-literally-minded, the law takes intent into account, and, as we saw with Objective C, way back when, distributing a module that can only work with someone else's code clearly shows intent to produce a derivative work on the distributee's system. "I make the end user glue the pieces together" is not a valid excuse. At best, you might be able to argue that it's contributory infringement, which isn't exactly a whole lot better.
NVidia, as I understand it, is using the documented public API of the kernel, intended by the kernel devs for exactly that sort of use. That, not some legal trickery about not distributing the kernel themselves, is why they can do what they do.
If what you suggest were true (or completely true--there's obviously some truth to it), then gcc wouldn't have an Objective C module. NeXT didn't really want to release the source code to it, and they weren't actually distributing any part of gcc. Nevertheless, their (NeXT's) lawyers were persuaded that the FSF had a solid infringement case.
Posted Mar 16, 2015 2:40 UTC (Mon)
by zlynx (guest, #2285)
[Link] (9 responses)
Which part of Nvidia's code would that be, exactly? The fully GPL licensed (yes, dual license GPL/Nvidia) glue code? Or the code which is the same core code that they use on Windows?
A too liberal reading of derivative code would make it impossible to read EXT2/3/4 filesystems on Windows or BSD, make it impossible to run ZFS or NTFS FUSE modules, and disallow using NDIS wrappers. WINE and Samba would probably become copyright infringers as well.
After all, code interop in the same address space, or in the same computer system, or on the same network is all a matter of arbitrary boundaries.
Posted Mar 16, 2015 11:13 UTC (Mon)
by etienne (guest, #25256)
[Link]
The whole part. The fact that a company ask its costumers/users to do "complex" things because said company cannot do it itself, while still claiming total ownership of said source code may look strange to a judge.
Posted Mar 16, 2015 12:45 UTC (Mon)
by paulj (subscriber, #341)
[Link] (7 responses)
However, that was a /long/ time ago. Their GPUs since then have changed a lot. Their drivers have changed a lot. They have done a lot of development since that original obviously-not-linux-influenced core with Linux officially supported.
For NVidia to have retained a obviously-not-linux-specific core they would have had to maintain a firewall between their Linux and core driver teams, to ensure their Linux driver writers could never influence the core driver team. Otherwise, this core may well have had adaptations made to it to benefit Linux support. At which point, it is no longer obvious that the closed core is independent of Linux.
In short, given the many years NVidia have officially been producing Linux drivers, it is not possible now to say NVidias' driver consists of a Linux-independent core and an open shim into Linux. At least, it would now require a review of their internal driver development history and processes to make that determination.
All that is certain now is that NVidia have a Linux driver that consists of a large, closed blob, and a smaller open shim to wedge the blob into a Linux kernel.
Posted Mar 16, 2015 13:56 UTC (Mon)
by NAR (subscriber, #1313)
[Link] (6 responses)
The question is not whether the driver is independent of Linux, the question is whether the driver is derivative work of Linux. My gut feeling is that a derivative work is a modified version of the original - if it merely uses the original, then it's not derivative. The combined work may be derivative, but nVidia makes pains not to distribute that.
Posted Mar 16, 2015 14:52 UTC (Mon)
by paulj (subscriber, #341)
[Link] (5 responses)
If one work has a functional dependency on another, in whatever way, then that indicates there may be derivation issues that you'd need a lawyer to look at, and potentially a judge and jury to resolve authoritatively.
That's my understanding from US corporate legal advice given to engineering, at a previous job. Legal gave functional dependence as a good rule of thumb that engineering could easily apply to determine if/when there was an issue that needed to go to the legal department.
The interesting bit was that the legal people there didn't really care about the technical details. For them, the issue seemed to be whether code A could work, with the same features, with or without code B in the *abstract*. It didn't matter to them if A used function calls, IPC or network protocols to use B - if it resulted in A specifically depending on B for functionality, then legal considered that an issue.
Legal simply short-circuited all the complicated, technical discussions the programmer/engineering types like to get into on free software licensing, and went with a much more abstract and fundamental test. A test that seems much easier to resolve too. "Does that code still provide the same functionality without that other bit of code, specifically?". It changed my whole perspective on free software licensing arguments.
Posted Mar 16, 2015 15:09 UTC (Mon)
by NAR (subscriber, #1313)
[Link] (4 responses)
Is it independent of the Java VM and API? Clearly not, uses the System class and uses the special
Of course, the HelloWorld.class and the JRI bundled together are derivative works, because they do contain the actual Java VM and system libraries.
The Linux kernel (intentionally or not) provides an interface to 3rd party kernel modules. I don't think merely using that interface makes the user code derivative work. Following this line a bootloader using BIOS would be also a derivative work of BIOS.
Posted Mar 16, 2015 15:48 UTC (Mon)
by paulj (subscriber, #341)
[Link] (3 responses)
1. You're asking me to believe your gut feeling over legal advice
2. A Java VM generally comes with a licence, which allows you to run programmes in it.
I don't see why a programme running in a VM and greatly dependent on it couldn't derive from it.
On the BIOS question, does the bootloader depend on a /specific/ BIOS (I used "specifically" in my last paragraph deliberately)? Or is the BIOS interface that it uses sufficiently well-defined that there are multiple implementations of it, and the bootloader could run on any one of them? If "yes" to the latter, it becomes hard to say that this bootloader derives from any specific BIOS.
You can apply similar reasoning to the Java VM / Helloworld case.
Posted Mar 16, 2015 15:52 UTC (Mon)
by paulj (subscriber, #341)
[Link]
From another angle: As programmers / techies, we so desperately want logical, well-defined answers to these questions. It may be hard to accept that in reality this isn't obtainable, unless you're very careful not to specifically depend on any one elses' code.
Posted Mar 17, 2015 12:46 UTC (Tue)
by NAR (subscriber, #1313)
[Link] (1 responses)
I'm not talking about a generic program - I'm talking about the very specific HelloWorld program. Do you really think that's a derived work?
For the BIOS-analogy - suppose someone implements from scratch a kernel that provides the same driver interface as Linux. Would this make the nVidia kernel module "underived", because there are multiple implementations of the driver interface?
Posted Mar 17, 2015 13:29 UTC (Tue)
by paulj (subscriber, #341)
[Link]
Is a small programme that relies heavily on supporting infrastructure (libraries, a VM to interpret it, etc.) derived from the work implementing that supporting infrastructure? Quite possibly! Why couldn't it be? Even compilers can have licence clarifications to clearly state compiler outputed programmes are not affected by the compiler's licence (e.g. GCC has this, though a GCC compiled programme can still be subject to the libgcc runtime library's licence).
Now, in the case of your Java HelloWorld, you could perhaps argue:
1. Your JVM came with a licence that explicitly lets you run programmes in it without further licensing implications for your programme.
2. Your programme depends only on functional, standardised interfaces (e.g. as de facto proven by there being multiple, wholly independent implementations), and so can not derive from any specific work.
Case 1 is what your lawyer would much rather prefer to have you rely on. Being able to say "The copyright author has published declarations that clearly state they are fine with this" puts you in a very good place.
Case 2 would worry your lawyer. It means the copyright holder might disagree and try sue you. That's annoying even if you prevail in the end. Worse, this can be a murky area of law (even murkier while Oracle v Google is ongoing).
The situation with your BIOS is probably similar. Use is probably covered by a licence, so the derivation question would then be moot (that said, I can't remember ever seeing an end-user usage licence for any BIOS I've had in a machine). Otherwise you're off in the murkier area of functional interfaces and derivation.
For the Linux case, assuming Oracle v Google is resolved in a way that we go back to the "strong interfaces are not copyrightable" standard from before, then maybe yes a Linux driver re-implementation could "underive" any binary drivers, or maybe not. I honestly don't know. (Note that in the VMWare case they are alleged to have re-used GPL-only Linux code in both the re-implementation, as well as having re-used GPL-only Linux drivers, IMU from the FAQ - which would make it a different case from your hypothetical).
I'm not trying to interpret the law here - IANAL. I'm trying to point out that, IME, lawyers will strongly advise you to avoid, if at all possible, getting yourself into a position where your only defence is to argue that a murky area of law falls in your favour. The lawyers will advise you that ideally you should either ensure you have a clear licence allowing your use of the other work, or else clearly not use that other work. My experience of this with lawyers predates Oracle v Google too.
Relying on the vagaries of copyright law to have your work ruled not deriving is risky and something lawyers I've had experience of would try dissuade you from.
Posted Mar 16, 2015 12:36 UTC (Mon)
by paulj (subscriber, #341)
[Link] (3 responses)
+1 on this. One of the most surprising things to me, when I came into contact with computer industry lawyers, was how little they cared about the finer technicalities that programmers might think are important.
Posted Mar 16, 2015 19:09 UTC (Mon)
by raven667 (subscriber, #5198)
[Link] (2 responses)
Posted Mar 17, 2015 5:19 UTC (Tue)
by zlynx (guest, #2285)
[Link] (1 responses)
Posted Mar 17, 2015 12:06 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link]
Posted Mar 12, 2015 18:10 UTC (Thu)
by raven667 (subscriber, #5198)
[Link]
IIUC it would be more accurate to say that whether something is a derivative work is a judgement call so it's something that is answered in a case-by-case basis and there isn't a lot of precedent in software cases to point to like instances and make a strongly informed opinion as to which way it's likely to be judged.
Posted Mar 12, 2015 11:28 UTC (Thu)
by nye (subscriber, #51576)
[Link]
I'm sure it is literally true. Given that there's the GPLd translation layer, I'd expect almost every line of code in the binary .ko to be cross platform, and hence written to target Windows first by default.
(The people writing the code for the supercomputer probably don't care much about the OS running on that pathetic co-processor we laughably call a 'CPU', except to provide a very thin interface between them.)
Posted Mar 11, 2015 12:20 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link]
Posted Mar 11, 2015 16:21 UTC (Wed)
by SEJeff (guest, #51588)
[Link] (4 responses)
Posted Mar 12, 2015 11:04 UTC (Thu)
by SLi (subscriber, #53131)
[Link]
Posted Mar 13, 2015 9:57 UTC (Fri)
by jezuch (subscriber, #52988)
[Link] (2 responses)
...by giving it a middle finger? :)
Posted Mar 14, 2015 1:24 UTC (Sat)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
Posted Mar 14, 2015 12:58 UTC (Sat)
by Otus (subscriber, #67685)
[Link]
Posted Mar 11, 2015 17:30 UTC (Wed)
by raven667 (subscriber, #5198)
[Link] (3 responses)
In some way isn't that the case for any proprietary closed source software running on a GPL base OS? ISTM that the problem the GPL is trying to solve is to require equitable sharing of modifications to code, if I wrote something and you modify and ship a better version, you have to share those changes back with me, but if I write something and you just use it unmodified as a component in another work in what way am I being harmed? I may like it if your whole software stack was Free Software but I might also like a pony, that doesn't mean I must get what I want.
Posted Mar 12, 2015 5:26 UTC (Thu)
by eru (subscriber, #2753)
[Link] (1 responses)
In the case of Linux, Linus has explicitly stated that the GPL does not affect user-mode code that just uses the kernel API.
Posted Mar 12, 2015 21:54 UTC (Thu)
by vapier (guest, #15768)
[Link]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/lin...
Posted Mar 14, 2015 3:54 UTC (Sat)
by neonsignal (guest, #87868)
[Link]
No, the problem the GPL is trying to solve is the restriction of user freedoms. "the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users". Modifications to the code have to be made available to the users of that modified code. There is no specific requirement to provide the modifications back to the original author, and that would be an unnecessary restriction.
The users of the GPL code include users of any derivative works. The only area which is not crystal clear here is where the boundary of 'derivative' work lies in relation to software; but that is a copyright question, not a GPL one. (The framers of the GPL clearly believe that linking constitutes derivativation of a work, which is why the LGPL is provided as an alternative for rare cases where allowing linkage to proprietary code may actually benefit users in the larger scheme of things.)
If linking to a GPL file is found to not be a derivative work, then this has significant ramifications for all software libraries, not just ones under a GPL licence.
Posted Mar 11, 2015 21:45 UTC (Wed)
by dfsmith (guest, #20302)
[Link] (3 responses)
IANAL but consider, for example, your BIOS. This is closed source proprietary software, which can load a GPL kernel; and in turn the kernel can call the BIOS. BIOS <-> GPL Linux kernel <-> GPL driver/application Compare this with what VMWare's letter said:
vmkernel <-> GPL vmklinux <-> GPL driver/application As a software guy, I'm kind of hard-pressed to see the difference. I don't know how a jury would see it.
Posted Mar 11, 2015 22:35 UTC (Wed)
by HenrikH (subscriber, #31152)
[Link] (2 responses)
Posted Mar 11, 2015 23:16 UTC (Wed)
by dfsmith (guest, #20302)
[Link]
Posted Mar 12, 2015 20:35 UTC (Thu)
by ttonino (guest, #4073)
[Link]
Courts are quite good at making this distinction.
Posted Mar 23, 2015 13:38 UTC (Mon)
by redden0t8 (guest, #72783)
[Link]
Posted Mar 13, 2015 11:42 UTC (Fri)
by UnwashedMeme (guest, #98571)
[Link]
Making workloads that their customers desire run properly is their business. This isn't a defense of breaking copyright; it's just trying to sell to a broader market segment.
VMware update to GPL-enforcement suit
VMware update to GPL-enforcement suit
VMware update to GPL-enforcement suit
VMware update to GPL-enforcement suit
VMware update to GPL-enforcement suit
VMware update to GPL-enforcement suit
VMware update to GPL-enforcement suit
VMware update to GPL-enforcement suit
VMware update to GPL-enforcement suit
VMware update to GPL-enforcement suit
VMware update to GPL-enforcement suit
Just a confusion over acronym, perhaps?
Just a confusion over acronym, perhaps?
If I understood VMWare's statement correctly (a big if...), they have their proprietary kernel loading a GPL-licensed "vmklinux" module (with published source), which in turn can load Linux drivers. So "vmklinux" translates between the proprietary API and Linux, and VMWare seems to believe this insulates the proprietary kernel from the effects of GPL. If this is the case, and the court accepts it, it becomes pretty easy to include any GPL'ed code into your closed proprietary software. Just write your own GPL'ed intermediate layers.
GPL-insulator
GPL-insulator
GPL-insulator
GPL-insulator
GPL-insulator
GPL-insulator
GPL-insulator
Wol
GPL-insulator
GPL-insulator
Wol
GPL-insulator
nVidia does not distribute other peoples' GPL'd code therefore there is no copyright violation.
GPL-insulator
GPL-insulator
The judge may ask what is the intend.
If you are the owner/costumer of such system, are you allowed to back-up (i.e. create a copy) of your system - maybe even in the cloud? Is that clearly explained to their costumers before buying?
Note that I would not say NVidia is doing anything wrong if really the closed part has never been debugged, optimised or modified on/for Linux...
GPL-insulator
no longer obvious that the closed core is independent of Linux.
GPL-insulator
GPL-insulator
Let's take a look at this piece of code:GPL-insulator
public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello world!");
}
}
main method to execute. Is it derivative work of the Java VM and API? I seriously doubt since I haven't even looked at the Java VM and API sources. My gut feeling conflicts with the legal advice you got.
GPL-insulator
GPL-insulator
GPL-insulator
GPL-insulator
GPL-insulator
GPL-insulator
GPL-insulator
GPL-insulator
GPL-insulator
GPL-insulator
GPL-insulator
GPL-insulator
GPL-insulator
GPL-insulator
GPL-insulator
GPL-insulator
GPL-insulator
In some way isn't that the case for any proprietary closed source software running on a GPL base OS?
GPL-insulator
GPL-insulator
> the problem the GPL is trying to solve is to require equitable sharing of modifications to code
GPL-insulator
GPL-insulator
GPL-insulator
GPL-insulator
GPL-insulator
So basically the defense they're setting themselves up for is:
GPL-insulator
+------------------+ +-----------------+
|proprietary kernel| |GPL Linux drivers|
+------------------+ +-----------------+
| |
derivative derivative
| |
V V
+--------+
|GPL shim|
+--------+
In other words, their kernel and the GPL'ed drivers are completely independent of each other. The only thing that's a derivative of the Linux kernel is the shim. The fact they also have native drivers for their kernel supports this. Their kernel works 100% fine without any GPL code (as long as the hardware you're running it on has native drivers available).
You can argue what you want about the moral aspects of this case, but I can see why VMWare believes that they're in the *legal* right here.
VMware update to GPL-enforcement suit