VMWare Taken to Court Over GPL Violation
sfconservancy.org
sfconservancy.org
In particular, this isn't just a question of whether a kernel module is a derived work of the kernel. Apparently VMWare has copied code from the Linux kernel, with GPLed headers on top, and compiled that code directly into some of their code.
(Can I legally port, say, the GPLv2 ext4 filesystem driver from Linux to a non-GPL OS like OS X? Can Apple pick up that port, and distribute ext4.kext and its source in OS X, without putting the entire xnu kernel under GPLv2?)
The harder and fuzzier part is that the ESX boot process works by asking Linux to "load" vmkernel, using the vmklinux helper module. If this is in the sense of loading a kernel module, it's (mostly) clearly wrong. If this is in the sense of loading a userspace app (as if vmklinux was a binfmt module, and vmkernel was a non-ELF executable), then this is (mostly) clearly okay. But it's doing neither of those. It's loading vmkernel above Linux, making the Linux process the first world, analogous to a Xen domU. So this isn't userspace, but it's also arguably a new address space. Neither of which are legal concepts per se, so it's hard to tell where this lies.
This fuzzy part is neither the first component (Linux / "vmnix" / the bootstrap) nor the second (vmkernel), but the way in which they interact and are designed around each other. This itself might be an infringement, even if the first is not infringing, and the second is fixed.
(Is the word "vmnix" wrong? Does it apply only to the entire Red Hat-ish distribution in the COS, and not to the Linux stepping stone alone?)
Basically the old 1.0 - 4.0 process for _ESX_ was like this:
* Bootloader
* Linux Kernel boot
* Load VMnix module.
* Load VMkernel
* hardware control passed to VMkernel
* Linux continues running as a sort of 'super' VM with some limited hardware access.
For _ESXi_ from 4.0 - now :
* Bootloader
* VMkernel
I don't know if this was to make the transition for stuff like vpxa from ESX 4 on easier internally, or to make it easier for 3rd parties to develop against, or both.
Is it lazily wrapping some functionality that should be open sourced that fills in where the service console would normally be? Probably not, but I can see why people would be a little suspicious.
vmnix was the name of the Linux kernel module that was loaded during the Service Console's boot process.
The terms "Service Console", "Console OS (COS)" were at times used interchangeably and referred to the Redhat distro you logged into at the terminal.
VSphere 4.0 had 2 versions: ESX (with COS) and ESXi (without COS). In 5.0 the COS was removed entirely.
ESXi's kernel does not bootstrap itself from Linux at all.
There is no linux kernel as such [1]
ESXi does reuse linux kernel drivers ... a lot of them. But the way this happens is through a well-defined API provided by (proprietary) vmkernel called vmkapi. What you are seeing in the code above is the mapping between various Linux API's and these calls to the vmkernel.
I have no idea about the complaint. VMware's position is probably that anyone can go and write anything they want against the vmkernel's vmkapi interface. Indeed some vendors ship drivers written espeically for this API.
VMware have chosen to write a linux<->vmkapi interface, which then allows them to re-use many linux drivers. All of the linux<->vmkapi interface is released, along with the drivers and any modifications and this is considered sufficient. My guess is that the software conservatories position is that it is not.
Note exactly the other thing happens on the "other" side -- between user-land and the vmkernel. ESXi uses glibc ... but of course that interfaces to vmkernel via standard system calls. Maybe that's part of it too, I don't know.
So this may be a fight over API boundaries and where the GPL starts and stops. That's quite interesting...
[1] There was with the ESX product, which shipped a version of Red Hat. That hasn't been around for ages
Conservancy discovered that VMware had failed
to provide nor offer any source code for the
version of BusyBox included in VMware's ESXi products
But ESXi is not a purely open-source product;
it also contains a proprietary component called
"vmkernel."
VMware's developers appear to have taken a
substantial amount of kernel code, adapted
it heavily, and built it directly into
vmkernel itself
Obviously though, I'm not sure how to prove that without the source of VMKernel
Again, this is honestly just how I'm reading it, if I'm wrong feel free to correct it.
The above extract mention "substantial amount of kernel code". If that code is implemented algorithms, data structure or full kernel features, then this case has nothing in common with the core issue between Oracle and Google.
It’s not clear, this really is an interesting case. From the description in the comments here, it seems that the GPL code from Linux, together with the code to interface with vmkernel is published, complying with GPL for that part.
My guess is that VMware considers vmkernel to be the operating system (which it is, albeit a minimalistic one, just the barebones hypervisor) and regard it as GPL code from Linux linking with the glue layer and the vmkernel system library. Which, if it provides some generic interface that the glue uses, arguably is.
And that - GPL code linking with proprietary system library - is an explicitly permitted exception in GPL: http://www.gnu.org/licenses/gpl-faq.html#SystemLibraryExcept...
I am just guessing here, but seen like this, VMware’s position makes sense. I would be surprised if they all-out violated GPL, Linksys-style, to be honest, because some competent FLOSS folks work(ed) there.
From my understanding, the problem is that vmkernel directly includes linux kernel GPL code, but they do not open source it.
If that's the case, this is 100% clear cut.
IE they aren't obeying their own interface, and have shoved GPL code in the wrong side of it.
If I recall correctly, the source tarball was created from a simple script which pulled in a bunch of open source files which were stuck into their own separate branch in the source repository.
To my knowledge, there wasn't any linux source in the vmkernel. We did use plenty of open source code, such as busybox, but my understanding was it was always in user space and the source was always published.
It's possible that Christoph's code was just pulled in and published with a bunch of other crap that wasn't actually in the product, but someone had checked it into the open source part of the source tree.
Also, "retrospectively making something portable doesn't change it's previous status as a derived work" was if I'm not mistaken SCO's argument for why it should be illegal for customers to run software they'd developed on SCO Unix under Linux. It's not something we should be supporting because it'd a really dangerous tool for locking users into a particular OS. (Fortunately, SCO lost.)
Arguing kernel modules are derived works from the kernel is very very different from arguing user space software is derived from an OS.
That's far from clear. Many core developers (including Torvalds, IIRC, but correct me if I'm wrong) are on the record that they consider Nvidia to violate the spirit and/or the letter of the GPL there. It's just that nobody cares enough to litigate.
Jonathan Corbet, editor of LWN, frequently posts his own subscriber links to LWN articles:
https://news.ycombinator.com/submitted?id=corbet
And has explicitly endorsed posting occasional links to HN:
http://sfconservancy.org/linux-compliance/vmware-lawsuit-app...
http://sfconservancy.org/linux-compliance/vmware-lawsuit-app...
Disclaimer - I'm on the Board of Directors of Conservancy.
The law is a tool that can be used to achieve certain goals. Similarly, software is a tool that can achieve certain goals. We wouldn't suggest that people shouldn't use software (which, in turn, requires employing programmers) because "in the end, you're only helping programmers", would we?
I'm no fan of the legal profession: the only sticker I have on my laptop reads "Keep your lawyers off my computer". However, I work with lawyers a lot because they are experts on the law, and I (or my organization) can hire them to utilize the law to promote good in the world.
I find proprietary software abhorrent and those who write in my mind are doing something harmful. I find Free Software wonderful and those who write it in my mind are doing something wonderful. Similarly, some lawyers do good in the world and some do bad, just like programmers.
4. You may not copy, modify, sublicense, or distribute the
Program except as expressly provided under this License.
Any attempt otherwise to copy, modify, sublicense or
distribute the Program is void, and will automatically
terminate your rights under this License...
Even then, a copyright-holder can still permanently terminate your rights if they so choose and notify you of such termination.
That said, (and continuing with my possibly incorrect assumption that the GPL hasn't been litigated) if it does get decided that this remedy can be enforced by the license holders through the court, I expect it will create the largest software effort since Y2K to get rid of GPL'd software in any enterprise larger than about 10 people. The business risk would become too great that they might be litigated by a rival into inoperation. (I know the author's aren't out to kill companies, they are out to enforce their rights, but there are lawyers that like nothing more than extorting companies for large sums of money and those lawyers would write "As you know VMWARE was damaged to the tune of several billion dollars because they didn't use the GPL correctly, and we know that you aren't using GPL correctly either, why take the risk and get a writ of compliance for a mere $<large sum>." Or like the guys who are coming out of the wood work to "test your house for formaldahyde" by basically clipping some PH strips to a stick, waiting for them to turn blue, and them selling the poor home owner a multi-thousand dollar "remediation" service.
I really respect what the GPL tries to do, but especially early in its life it was way too ambiguous in its interpretation (consider the difference of opinion between FSF and Linus on loadable kernel modules for example)
Only the owners of a copyright have standing to sue, so I think the complete version of your concept fails unless, like in this case, the copyrights are held by many people instead of being assigned to one person or organization. I also can't imagine that a lot of companies haven't considered this risk, it hardly matters to such companies if this hasn't reached the level of a contested (vs. default) decision if they believe it could if pushed. E.g. see this: https://news.ycombinator.com/item?id=9153278
EDIT: Maybe not true for copyleft software, reported not to be true in France (see below).
This is somewhat moot if the litigation happens in Germany of course.
In contrast to camperman's comment, the copyright issue is first determined as a matter of law (its instructive to see the Groklaw archives on this with regards to SCO) and then if the copyright is valid then the question of the license comes up. And party A will say "That wasn't what I meant" and party B will say "But this is what it says" and for each of the clauses and sentences in the GPL a discussion will be had on what it says versus what it means. And finally if what it means is something that can be legally enforced[1]. A good example of that was the AT&T versus UC Regents suit over BSD where the BSD license and the AT&T Unix licenses were extensively examined.
[1] You could write a shrink wrap contract that said "By opening this package you agree to give me all your future income." which is clear what it says and what it means, but you would be hard pressed find a court willing to enforce those terms with that contract.
A better one, that I'm a lot more familiar with, is Stephens Media, their property the Las Vegas Review-Journal, and https://en.wikipedia.org/wiki/Righthaven which produced a Federal District Court decision that in order to sue, one must actually own the copyright.
But if you're just worried about the prospect of being sued, none of this matters as you point out. New SCO dragged our corner of the world through a huge, long and expensive drama about code that they never had the copyright to, and knew in advance they didn't. Which means that risk exists for any code you don't write yourself....
I'm not sure the SCO case shows the progression you cite. As far as I can remember, everyone assumed SCO had the copyright, there was lots of litigation based on that, and it took years for the case(s) to wander around until in rather a big surprise we learned they didn't. Of course, to continue the theme of "(too) easy to get sued", there should have been severe sanctions levied on the parties responsible for that fraud, which somehow never seems to happen in the US.
What about people who receive the compiled software (customers) and would like the source code as well? Don't they have standing?
In the US, IIRC (and IANAL and this is not legal advice) license are analyzed under contract principles to the extent applicable, which might extend to standing, and, under contract principles, you could argue that those receiving the software are intended third-party beneficiaries with standing to sue.
So, its possible.
That's not true, at least in some countries. For example, see this case in France from 2009:
http://arstechnica.com/information-technology/2009/09/big-gp...
> "We've long said the GNU GPL is enforceable, and of course we're pleased to see another court reaffirm that fact," said FSF France president Loic Dachary in a statement. "It's a commonly held belief that only the copyright holder of a work can enforce the license's terms—but that's not true in France. People who received software under the GNU GPL can also request compliance, since the license grants them rights from the authors."
However, I do think that parties receiving GPL software also have standing to sue, not just authors.
And this may also be true in the US: see for instance one of the decisions in Versata v. Ameriprise where the court considered GPL to create contractual obligations towards third party beneficiaries -- i.e. towards people receiving the code. That whole case has been settled out of courts but that's still an interesting decision (and to my knowledge, this decision had not been further contradicted by upper courts so it is still interesting).
If the GPL is litigated to the point of a published decision, doesn't that give the legal team of the targeted company the ability to say "actually, we know we ARE using it correctly, so buzz off"?
According to the lwn link 'JoshTriplett provided upthread, corporate general counsels often contact the Conservancy to request GPL enforcement: "Their interest, instead, is in a demonstration that the GPL has teeth so that they can be taken seriously when they tell management that the company must comply with the license terms of the code it ships. "
If a company want to remove this risk, they can't license someone else work. That mean no third-party engine, no font types, no xml parsing library. The cost vs risk is so insanely on the cost side that it would be fools and fools only who rather make everything inhouse in fear of follow simple industry practices that has existed for 20 years or more.
If you link together GPL'ed work with something you distribute, release the source code for that work. That is not a more risky proposition that say, giving 5% for using unreal engine.
Commercial engines generally have a clause in there that you are not allowed to bring any GPL code in contact with the engine, no exceptions.
Note this problem only applies (in practice) to GPL licenses which are explicitly disallowed in all gaming environments I have encountered. As such the problem is moot. There are lots of Open Source code in computer games, just not GPL. It's a non issue.
In practice, license conditions are balanced to the interest of the company. Some might be perfectly fine with 5% revenue losses in order to pay for a engine, where others would strongly disallow it. If this lawsuit succeed, my guess is that any damages will be far less than 5% total revenue from the years of Linux usage.
Because not many other licenses like GPL "spread" to the entirety of the project. Sure, you can draft another license like this, but out of the popular ones there really is only the (A)GPL which does that.
* Most of the time commercial libraries like unreal make a distinction between interface and implementation. In the worst case you could swap out their implementation and reimplement the methods you use, which will be expensive but at least at the end of it you'll have a clean codebase that you own. With GPLed code even that might not be enough - you could replace the GPLed implementation and your codebase might still be a derivative work of the GPLed library. * Epic is a profit-making business with obligations to their shareholders; ultimately resolving any issue with them is going to be "only" a matter of money, it's not in their interests for your company to go out of business. An individual GPL copyrightholder is more likely to be idealistic/spiteful about it. And GPLed libraries often have several copyrightholders, multiplying the risk.
http://www.timelex.eu/en/blog/detail/gpl-license-reaffirmed-...
Second, most businesses already avoid the GPL, but among those that can't, such as Android device makers - well, some of them seem to be fine with avoiding the edge cases by just publishing the source to their kernel modules. Considering this, I suspect that for the other half, it would not be the end of the world to have to reveal some minor secrets about the hardware or whatever; they just neglect to publish source because they are unlikely to be penalized any significant amount for doing so.
Of course, there is the risk of GPL making it into codebases by accident, but really only if you spend zero effort keeping track of it. There are companies like Black Duck that provide tools to scan a codebase for known open source code, and honestly a quick grep should often be sufficient as well. In VMware's case, I'm not sure about the executable loading or kernel module issues, but if "vmkernel" itself has code copied and pasted from Linux, as is alleged - well, they should have known better! No need for the largest software effort since Y2K when you could just ensure someone in the company understands the GPL and how it relates to the company's code, before said code is highly developed.
Also, most super-big cos are not in the business of selling software but using it, despite what they may think. VMWare on the other hand should know better.
Saying that they'll Y2K away from it cuz of this lawsuit sounds a little like FUD to me.
Maybe I worked only in surprisingly enlightened enterprises, but the worst fear I was informed about regarded lack of support by a "real" company.
Using GPL SW in a product sold to clients is a different issue but in my (big) enterprise the GPL is a well-known topic: there are internal guidelines about what you can do and what you can't do with GPL SW and who you have to contact when you want to use GPL SW for clients products so that he can check that you're doing the right thing.
This is false for GPLv2, sadly, despite people wanting it to be so.
GPLv2 says "6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License."
So every time vmware downloads the kernel, they get a license. Even if the prior time, it was terminated.
(THis is pretty well accepted, but not happily, by most open source lawyers).
GPLv3 is different here.
"Each time you redistribute the Program"
In this sentence "You" would be VMWare, not the authors of Linux.
"the recipient automatically receives a license from the original licensor to copy"
the Linux license is between Linux authors and recipients of VMWare software.
So section 6 does not say Vmware gets a new license each time they get a copy of Linux.
Section 6 just makes sure that even if someone along the chain of distribution of the GPL software fails to comply, not all receiving parties down the path are automatically in failure to comply.
Sure, it's an interpretation.
[edit] the point is: nowhere as clear as the original comment expresses.
But this is a policy argument, not a legal one, and it will absolutely never win in court over very clear and unambiguous text.
This is, as i said, why GPLv3 was revised here.
You are reading who is giving who a license wrong.
Redhat, or whoever they download from, is the "you" there. Not the person who license was terminated.
So let's fill in the blanks:
6. Each time Redhat redistribute the Program (or any work based on the Program), the company who violated the license automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions.
All i did was replace the word "you" and "recipient" with the right people. This is clear and unambiguous. You may not like the result. I actually don't like the result. It does not change the legal meaning, or whether you'd win.
But you don't have to take my word for it, ask another open source lawyer, they'll tell you the same thing i just did.
The only lawyers I find who agree with your position (and, BTW, they agree with it for completely different reasons than you state, and I suspect they wouldn't agree with your reading of v2 Section 6) are a few lawyers in Germany.
I thus find myself in the odd situation of having to defend your trolling a bit, because Till Jaeger, Christoph's lawyer in the VMware case, has indeed stated publicly that he believes you can regain a license under GPLv2 by coming into compliance and redownloading in Germany. However, this is likely specific to Germany because no other legal expert I've ever met who has studied this issue has argued it works anywhere else in the world.
This point is therefore salient insofar as this thread is discussing a copyright case in Germany. But, as I wrote in the copyleft.org footnote I referred to earlier, the issue is just an esoteric legal detail except in the case of proprietary relicensing business models. Community-oriented GPL Enforcement Organizations always restore rights anyway once the violator achieves compliance, so the final impact of both interpretations ends up the same in most enforcement actions, unless of course your goal is to abhorrently use strict termination to extort gobs of money, in which case, this detail matters a lot.
It looks like a shitty, evidence free insinuation of dishonesty used as a rhetorical tactic, but that's a big assumption to make.
I can't even see how you would come to the conclusion you did, given it says "6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. "
IE it very specifically says they get the rights you claim they don't.
Section 6 is amazingly clear, and this is completely and totally unambiguous.
I don't remember if Eben disagrees (I actually don't think he does, last I remembers), but it's generally accepted that this is the likely outcome.
So if redhat redistributes (through their website) to vmware, redhat is you, and vmware is recipient.
You don't get to pin You to be a specific person just because it comes out the way you like it. The license says what it says. (and you can't anyway since this would ruin the rest of the GPL ...)
That's not how it works. "You" is, consistently throughout the GPL, whoever gets the program under the GPL license, and that license is between "You" and the copyright holders on the program (i.e. the licensors).
The person who is "you" can, in another situation, be a licensor or mere redistributor, but that's irrelevant to the legal relationship at stake here (i.e the relationship between the copyright holders and a person who failed to comply with the GPL).
In particular, take a look at Footnote 4 on that page, which documents state of this situation succinctly.
I'm not aware of many competitors in their market space - Hyper-V certainly, but that's less of an option for some. Short of rearchitecting our service as a series of containers, what action can conscientious corporate leaders take?
Openstack is trying to solve this problem; but so far, openstack seems to be more of marketing, less of success stories.
These are all part of oVirt/RHEV.
Our company started with RHEV and ran into lots and lots of issues with it. There were compatibility issues between our VM infrastructure and SAN (firmware problems on one side, I forget which). Guests would just lock up all the time. There were other problems, but I'm not familiar with them.
We've had little to no problem since migrating to VMWare.
however qemu-kvm hasn't been around so long, it's still not anywhere near the adoption numbers such as Xen, however I've used it in production in three different large companies with great success.. the beauty is that more people who use it means more eyes on fixing it.
so for small things especially I'd really recommend it, and honestly I like it anyway, it feels very freeing to use libvirt/kvm- you have much finer grained controls than what vmware gives even in it's expensive offerings, and the best bit is that it's free as in beer- you can use all it's features without being in any kind of violation with licenses. the tools to administer it are ssh if you're familiar with unix or a GUI python program which gives you good control and graphs (works over ssh tooo, so encryption goodness) and works cross platform (last time I checked) contrasting to when I last used vmware:- you had to use there vsphere client which isn't ported to OSX or Linux.
I use Windows at work so it's not a problem, but I would prefer to run linux so I can actually use decent virtualisation solutions for small test labs, my company baulks at the cost of vmware workstation, and if I run linux for kvm then I cannot administer our massive ESX clusters..
But then, you could use Xen directly.
XenServer is also 100% open sourced now by Citrix. It's a completely free product with all the features, but you can pay Citrix for enterprise support if you want/need it.
If you prefer a more hands on approach just plain Xen or KVM is a great option too. As for orchestration in that space have a look at running Openstack or Xen Orchestra etc.
If your goal is VM orchestration, and you are not ready to go full self-service via OpenStack and similar, then we also provide a product called CloudForms (http://www.redhat.com/en/technologies/cloud-computing/cloudf...).
Basic idea is that it allows you to manage your hypervisors/VMs, regardless of what you are using (VMware, RHEV, EC2, etc). By manage, I mean that you can provision and implement policies around anything that might be done to a VM. For example, it can require a manager approve an VMs deployed into the production data center.
It takes a lot of configuration, but fills a gap between IT provisions all VMs and full self service.
https://www.suse.com/documentation/suse-cloud-5/
Additionally it supports some components from vmWare: https://www.suse.com/documentation/suse-cloud-5/book_cloud_d...
Disclaimer: I work at SUSE.
I always cringe when people believe VMware HA == HA solution. No. It's part of a HA strategy, but 30 seconds to declare a node is dead, and then however long booting up a big server full of VM's takes - if your storage is not that great, that can be quite a while (boot storms are fun).
If up to 15 mins of complete downtime counts as HA for you, great! But that's already risking 99.99% SLA.
Granted my needs are hardly enterprise scale, but may be worth you taking a look (if you haven't already)
Grab the oVirt upstream and decide which of the commercially-supported downstreams you want.
I think datacenter platforms will start to look more like "Cloud Hosting" and less like it currently does where we basically just slice up a server into many different servers.
https://www.joyent.com/private-cloud https://github.com/joyent/sdc
I'm seeing much better direct device I/O on KVM than on ESXi (which is saying a lot actually, since raw I/O is a bit tricky on the latter).
I worked for a company that was on a receiving end of a similar GPL legal action (though not busybox-based and not from SF Conservancy). I'll tell you what will happen next. VMWare will (a) write a drop-in in-house replacement for busybox (b) they will show that busybox is not an principal part for ESXi and that it can be easily swapped for the in-house replacement. At this point they will release the busybox sources, potentially including the in-house version, but not under GPL. This will hinder the lawsuit, but it will keep dragging on until everyone gets tired of its pointlessness and then it will get quietly dismissed to the mutual satisfaction of both involved parties.
The thing is that it's not that VMWare is evil or unethical. It's just that this GPL thing doesn't even register on their legal radar, so it never percolates down to engineering. Similarly any concerns raised by engineering are never taken seriously by the legal council. It's really as simple as that.
> It's just that this GPL thing doesn't even register on their legal radar
It should register.
> Similarly any concerns raised by engineering are never taken seriously by the legal council.
Not in any serious company to my experience. Being so lax on legal matters for such company shows very low level of their management's professionalism.
Companies violate patents licenses agreements and all other legal nonsense all the time, that's what they got lawyers for.
Actually, no, it doesn't.
It merely means that the management views GPL violations as a low-probability calculated risk. As in "we know that we can be in compliance, but we won't be wasting any resources on it until it's justified". It has nothing to do with the professionalism.
No, that's a weird attitude (i.e. I'll create a mess today, next person will clean it tomorrow). One has to be responsible for the mess, and actually preventing it to begin with. What you described is exactly the lack of professionalism.
http://en.wikipedia.org/wiki/Black_Wednesday
http://en.wikipedia.org/wiki/Criticism_of_Comcast
It's only unprofessional if you're bad at it.
I get what you're saying, and I agree absolutely that it is a morally reprehensible thing to lie, cheat, or take the short-term approach to long-term problems. At the same time, you have to realize that anthropomorphizing companies is wrong. They are entities created to obtain profits, and any other reasoning about them is just going to cause you grief and distress. Accept that the system is made to generate non-corporeal profit-seeking amoral sociopaths, and move the fuck on.
No. It's a fake logic often used to excuse of kind of crooked behavior. This doesn't fly. Crooks are crooks, whether they are a company or not. Companies have those who drive them. If those people at the head can't control their own companies not to be crooks - too bad for them, they bear the responsibility.
It sounds like it has everything to do with professionalism.
Which shows stupidity of that management, which thinks that legal violations are acceptable as long as they can view them as "low risk". Or it simply means it's a company of crooks. Either one is not a professional environment.
Swapping out Linux in vmkernel would be much harder.
See their FAQ (or one of the other comment threads here) for more info: http://sfconservancy.org/linux-compliance/vmware-lawsuit-faq...
VMware engineer here. This should not be construed as commenting on an ongoing court case (and I've never worked on the vmkernel), but I would like to respond to:
At least in my organization: Legal is definitely aware of the GPL. Engineers are definitely aware of the GPL. Adding a dependency on a GPL'd library requires an almost unbelievable amount of paperwork.
Again, at least in my organization: We also take open source obligations very seriously. For each release, we publish a detailed list of all open source software we consumed and a bundle containing all of the source code for those components, even if the project's license is one of the more permissive ones which doesn't require it.
I can't imagine a less open-source friendly system...
It doesn't require a snail mail letter as far as I can tell.
Any engineer competent enough to incorporate Busybox into another product would know what GPL is, and what are the most basic implications that it leads to. I find it much easier to believe that VMWare as a whole was explicitly aware of the licensing situation. It remains to be seen what was their plan B, if there ever was one.
This is a software company, not a chocolate factory. "Doesn't even register" isn't an accident, it's a choice in the same way ignoring the speed limit is a choice.
Evil? No, probably not. Unethical? I would say so.
Then everyone in their legal department needs to be fired yesterday.
There's no legal department of any note in Silicon Valley which isn't painfully aware of the GPL, nor has there been for the past 15 years, if not 25. They may have decided, as he somewhat more plausibly suggests, that the risks aren't significant. FSF have pursued GPL compliance cases in the past, and their goals are to increase the scope of Free Software -- getting either larger works released as open source or changes committed back. IIRC some major GCC enhancements came by way of this route.
Odds of seeking a cash settlement or other punitive award are slight. There's similarly little risk of customers being sued, though other VMWare partners could conceivably be. This doesn't do much for corporate goodwill in at least some quarters, and a lot of early GNU / Free Software folks are now in senior positions within the industry.
Do you mean they'll release the busybox sources potentially not under GPL, or the in-house version potentially not under GPL?
The former is probably legally difficult, while the latter is expected.
What isn't clear to me is how action regarding the use of copyrighted materials taken after a legal claim is made could have an effect on on-going proceedings.
Perhaps someone with more legal knowledge could elaborate?
Whatever you think about the GPL (and I'm for open source and open licenses but I do have issues with GPL v3, but that's just me), this has been necessary, I believe, in order for GPL and OSS projects to move forward.
I wonder what they're thinking. At least with nVidia there's a plausible sounding defense that goes like "hey, we just wrote a shim to load this platform independent code we already had lying around, so our platform independent code can stay proprietary because it's not a derived work of Linux". I don't think this position is correct, but I can see that it at least requires a court case to adjudicate.
But in VMWare's case, it appears that they took the Linux kernel and modified it to make their own vmkernel. I can't see how you make an argument (that their vmkernel is not a derived work of Linux) that takes more than ten seconds to soundly defeat.
Thus, one could write kernel drivers, which (it was argued) are not derivative works under copyright, and be safe as long as the kernel is not redistributed by the same entity.
"that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language"
I'm not entirely sure what to do with this.
There is however a big caveat whenever you try to "hack" around law. If the author explicit state that "I do not wish X to happen to my work" and someone technically comply but in practice make so X happens anyway, then a judges ruling can go anywhere. See the Pirate Bay or the Aereo case where arguments for such "hacks" has been made.
LWN has some more detailed coverage, describing the proprietary vmkernel component that gets loaded into the kernel as a kernel module, and the specific files from the kernel that are included in this: http://lwn.net/SubscriberLink/635290/d7304b50a2ef15b0/
This is much deeper than simply a binary kernel module that uses the exported interfaces; it also appears to copy wholesale large parts of kernel internals, not just access the kernel via defined interfaces.
So far the decision of German courts has been that if GPL wouldn't be a legal license, then the licensee wouldn't have had any rights at all (since you would default back to regular copyright).
It's possible that some points of the GPL will be debated, but I doubt that this will bring much additional clarity.
From the page, it seems like there's been ongoing negotiation, so I am guessing there's been a lot of stalling.
Well they could replace the component with proprietary (so there is not license to comply with), stop releasing the old version and then probably settle to pay fines or damages.
In other words the legal outcome of GPL violations is not necessarily being forced to release the rest of the code as GPL.
Stopping will probably just be another outcome unless they can come with some kind of agreement, like a separate commercial relicensed version of the GPL (but with multiple contributors that becomes a nightmare)
True. I have met many people who didn't make that connection. They had this idea that if they found GPL code inside a commercial, closed source product, that it would be completely okay to start distributing this software themselves. Because in their minds, "GPL is in there, so the entire thing automatically becomes GPL licensed and everybody can distribute GPL licensed code and even charge money for it".
I had to explain to them that is doesn't work that way. And if they found such a component, all they would have found was a GPL violation which they can report and which then would be an issue between the software's developers to resolve. Which may either end in them actually releasing their entire product under GPL or simply paying a fine. Out of those options I am pretty sure most would rather pay a fine than to give up their own IP to the GPL.
My favorite example is OpenAFS. Development of the AFS kernel module started in 1983, so the code is a decade older than Linux itself. So it's hard to argue that openafs.ko is a derivative work of Linux, and since it continues to run on several kernels other than Linux (Darwin, Solaris, NT, etc.) and the Linux-specific code is just glue code to make it work, it's not really obvious that it's become a derivative work of Linux. (OpenAFS is free software under the IBM Public License, which is a GPL-incompatible free software license, and the rightsholders will not relicense. The Linux kernel infrastructure assumes that any non-GPL kernel module is proprietary, for extra amusement.)
Along the same lines is the kernel module for VMware Workstation, the desktop product that runs on Linux as well as Windows and Mac OS X. It doesn't predate Linux, so the argument is slightly less clear.
VMware's vmkernel, as I understand it, is an amalgamation of VMware's hypervisor code (that predated ESX, and originated on Workstation) plus Linux. I think it conceptually started off as a Linux server with the existing kernel module, but both have evolved quite a bit. I think the remaining Linux parts mostly exist as hardware drivers, and VMware is providing the core kernel routines like scheduling and memory management and "world" management (equivalent to process management, but it's a hypervisor).
I think that VMware's argument is that they did not start with Linux and add proprietary features to existing GPL'd code and call it proprietary; they started with their own code and linked in parts of Linux via well-defined interfaces, and they're happy to comply with the GPL for the parts that came from Linux, but they don't want to GPL the entirety of the ESXi kernel.
It's worth noting that the concept of address space isn't a legal concept, just a technical one. We generally acknowledge that it's not a GPL violation to run proprietary applications on Linux, even applications that use Linux-specific interfaces like cgroups and epoll and signalfd and all that good stuff. Is this simply because the Linux kernel copyright explicitly disclaims virality to userspace, or because there's some fundamental legal reason why userspace and kernelspace are far enough apart? Can two components in ring 0 also be "far enough apart"?
> In 2011, Conservancy discovered that VMware had failed to provide nor offer any source code for the version of BusyBox included in VMware's ESXi products (as required by BusyBox's license, GPLv2).
> This case is specifically regarding a combined work that VMware allegedly created by combining their own code (“vmkernel”) with portions of Linux's code, which was licensed only under GPLv2. As such, this, to our knowledge, marks the first time an enforcement case is exclusively focused on this type of legal question relating to GPL. However, there are so many different ways to make combined and/or derivative works that are covered by GPL that no single case could possibly include all such issues.
From the FAQ at http://sfconservancy.org/linux-compliance/vmware-lawsuit-faq... :
"[...] admittedly, VMware made substantial and good efforts toward compliance on BusyBox. However, VMware still refused to fix a few minor and one major compliance problem that we discovered during the process. Namely, there was a major violation regarding Linux itself that ultimately became Christoph's key complaint in this lawsuit."
As for "what came first"- the license (which is a legal contract) specifies what is and isn't allowed. The LGPL would work in the way you are saying that VMWare might like it to work- where linking isn't the same as deriving. The fact that these two licenses exist demonstrates that distinction clearly.
The issue will be whether or not a judge understands these distinctions.
("Derivative work" does occur in both copyright law and the text of the GPL contract, which is why the time argument is relevant. US copyright law specifically says, "A 'derivative work' is a work based upon one or more preexisting works." So unless you can argue that OpenAFS has become "based upon" Linux, it's not a derivative work; Linux is clearly not preexisting.)
Are you allowed to write and sell a proprietary LD_PRELOAD for a GPL'd app, that only intercepts standard POSIX functions and doesn't mess with internal symbols at all?
Are you allowed to distribute that library, the app, and a wrapper script? Are they "reasonably considered independent and separate works in themselves", or distribution "as part of a whole" (GPLv2 sect. 2)?
On the flip side, if you sell a virtual appliance that includes the GNU userspace (GPL) and some proprietary binaries, is that considered distribution "as part of a whole" (the appliance), and are you obligated to make your code available under the GPL? Even though there's no linking involved, it's not clear to me whether your code can be "reasonably considered independent and separate" if it's only distributed as part of the appliance.
I think that informed people in good faith can come to different conclusions about what they "reasonably consider" independent and separate. This isn't as obvious as, say, copying-and-pasting glibc's implementation of DNS resolution into your proprietary libc.
There is already legal precedent separating software licenses at process boundaries. This is why every piece of software in a Linux distribution doesn't need to be GPL'ed.
And I think it's closer to how I think vmmon works in Workstation: you load the module, and as part of initialization, it hoists itself as owner of the CPU and stuffs the existing system in a world, creating what Xen would call "dom0". If I'm reading you right, it sounds like ESX uses "vmnix" to boot from disk and initialize hardware, and then loads vmkernel in a way that does not link with vmnix at all (unlike Linux module loading), hands over control of the processor to vmkernel, and puts itself in a world.
Two things worth noting about how the world has changed since 2007: VMware has made the shell much less extensive in ESXi (which was one of the major changes: ESX was very Red Hat-based, and ESXi's UNIX parts are just enough busybox to make things work and the shell is disabled by default), and Linux has been pushing back more on proprietary drivers using in-kernel interfaces (see, like, Nvidia and DMA-BUF).
I still think that VMware needs Linux for hardware compatibility. If it's at all legal, they'd be wasting their time implementing support for every last SCSI controller, network card, etc. on their own -- and Linux is far ahead in cases where you need reverse engineering or politicking to get support. I don't know how good the BSDs are at this sort of thing; I'm curious if they'd solve this problem well enough on server hardware.
IBM and whatever ended up in HP probably spent hundreds of million (or more) to make sure Linux runs on anything anywhere. You don't have to spend that on writing an operating system that could run on select hardware at best, you can leverage their work and run on commodity hardware, for free.
Thanks to the reciprocity of the license they can do this with the guarantee that their competitors will do the same.
VMware did rip out the drivers from Linux and use in their own closed product, which is then guaranteed to run anything with no further work required. They argue, and this may very well be so, that since they wrote a binary shim between the Linux stuff and their own they are two separate products. They can therefore release the source of the shim only.
While that's clearly against the spirit of the licensors (which they have made abundantly clear over the years), it will be very interesting to see if it also is against the letter of the law.
That description of vmkernel reminds me of Xen's hypervisor (dom0 handling hardware access, providing drivers but otherwise still sitting "above" the hypervisor), one technical difference I'm aware of is that Xen's hypervisor is the first piece of code loaded by the bootloader.
But does that even count as a technical difference once the system is running? Does vmkernel effectively do the same thing Xen does even though it loads dynamically via the kernel module interface after the Linux kernel boots?
I don't know much at all about how each of these common hypervisors (vmkernel, KVM, Xen, Hyper-V) interact with their "driver domain", and certainly I'm in no position to say whether any technical distinction in the way they each load or work will matter legally, but I've been interested in the vmkernel situation for a long time so I'll be watching closely.
I'm also reminded that there seem to be several proprietary versions of Xen's (otherwise GPL'd) hypervisor that bolt on closed source features, perhaps they'll end up in a similar situation as VMWare if this goes badly for them?
Proper Type 1 hypervisors run on top of the bare metal, boot first, and then in the case of Xen load a privileged virtual machine as Dom0 which has access to the bare hardware, which can be e.g. NetBSD in addition to Linux. Dom0's device drivers then provide as services raw block and network devices to the DomUs (and there can also be pass-through of devices to DomUs, something I'm not familiar with).
So the isolation is very white line, and as we engineers view it, not GPL violating. But as someone else has noted, the address space concept is not a legal one.
My read of what they've been doing as their "enterprise" hypervisor evolves (it's hard for me to keep track anymore) is that they went from the old ESX bootstrapping vmkernel using Linux and a kernel module (as I was vaguely recalling in my other post), to ESXi loading vmkernel directly, and in the process of moving to this new Type-1 architecture they decided to just lump a bunch of GPL'd code from the Linux kernel in to vmkernel.
I'll be interested to see more about how this thing actually works at runtime, legal issues aside. It's quite fascinating :)
According to the LWN article someone linked[1], they're actually using modified versions of the Linux scheduling code in their hypervisor, along with the Linux implementations of fundamental data structures like radix trees. They're probably in deep trouble.
In the same way that if I took some pictures I drew back in 1960 and used them to illustrate a copy of Harry Potter, I've created a work that's a derivative of both my original picture collection and Rowling's work.
VMware joins Linux Foundation--while reportedly violating the GPL
http://www.cnet.com/news/vmware-joins-linux-foundation-while...
Edit: "[The USD] is our currency, but it's your problem.", John Bowden Connally, Jr.
Obviously here are people who like it that way.
What does that solve? Whom does it help? For VMWare it's just professional risk, they have their lawyers, they know their business. So even if it ends up extremely bad for them (which I doubt) it will be just "nasty day at work" and they'll recover somehow. And sure as hell it won't be tragic for EMC (if they notice it at all). The "victim" won't be rewarded as well, because "victims" are ordinary Linux-kernel contributors scattered over the world.
So what the whole thing really is: gathering money to feed some lawyers, who might not look as bad as VMWare when you read all that story, but in fact are far less useful for society than even VMWare, who is supposed to be the evil guy here.
It just makes me think how pointless all that stuff is. It's depressing.
Just two parties making their case in front of a judge, and the judge deciding who is right and what the repercussions are.
Two seconds of Google research suggest that settlements are possible: https://books.google.com/books?id=zZoibg8oR1QC&pg=PA132&lpg=...
You might mean plea bargaining, which is more of a US-centric feature, but that's only applicable to criminal cases. This is a civil suit between two parties.
Not trying to be a naysayer, but I wonder if this will accomplish anything? (since the case is in Germany and not the US where VMWare is incorporated)
[1]http://www.theguardian.com/world/2015/feb/12/paris-lawsuit-f...
[2]http://www.themarysue.com/france-sues-google-autocomplete/
this is dot a defamation case.
From my edit [2]http://www.themarysue.com/france-sues-google-autocomplete/
"In any event, Google is a U.S.-based company, and isn’t compelled to operate under foreign laws. Google’s autocomplete practices are as subject to French law as they are to Japanese law, which is to say they are not subject at all."
If Google has offices in France, and they probably do, then Google must respect French laws. A country has sovereignty over its territory, which means that if you want to operate under it, you must respect its laws.
Don't know what happened with that lawsuit you mentioned, but if Google won, then it must have been because it was a stupid lawsuit.
Mostly since in many of those drivers, it performs better than linux, but also because vmware did not hire idiots, (and non-idiots know not to ever use GPL code).
Source: worked there a while ago.
He concludes:
> 1) There is no argument that depending on a Linux console OS makes any part of ESX subject to GPL that is not already opene sourced. We have open sourced those GPL components of the system which we have modified and given the changes back to the community.
> 2) There is no argument that loading the vmkernel by bootstrapping it with Linux makes the vmkernel subject to GPL. In fact, in the funniest counter-example, Linux itself used to be boostrapped under MS-DOS by running the command loadlin (note the 7 character name, since DOS would not allow enough characters for load-linux).
> 3) There is no argument that distributing GPL binary drivers makes any piece of software distributed with them or using them subject to GPL. In fact the converse appears to be explicitly stated in the GPL itself.
* http://web.archive.org/web/20080105204946/http://www.venture...
updated for formatting.
Yes there is: the GPLv2 says:
"If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it."
You would have to not consider the ESX product "a whole which is a work based on" the COS.
Naturally, this interpretation would extend to just about everyone who builds virtual appliances, special-purpose bootable CDs, etc. So it would be an unfortunate interpretation. (In particular, you couldn't intermingle GPLv2 and GPLv3 software on a virtual appliance!) But just because it is unfortunate does not mean it is not valid.
[btw, it's worth noting that the COS basically no longer exists.]
1) The GPL doesn't cover execution, only distribution
True, and as such an end user loading a proprietary kernel driver into a GPLed kernel (or vice versa) isn't infringing. But things get more complicated when you're distributing a product that consists of GPLed and proprietary code and requires both of them to be useful. If vmkernel is basically useless without vmklinux, there's a reasonable argument that the distributed product is a derived work of both vmkernel and vmklinux.
(The same argument doesn't apply to a product using proprietary applications on top of the Linux kernel - there's an explicit statement in the Linux copyright file that using the standard userspace interfaces doesn't create a derived work)
2) There's a copyright boundary between Linux and kernel modules
Quoting from his comment:
"Linux has established a well defined, binary interface through which driver modules and the kernel may interact, with well defined copyright separation."
This is, well, nonsense. Calling the Linux kernel ABI well-defined is entirely untrue - it changes rapidly between releases, it changes within releases (there's no guarantee that an LTS kernel will keep the same ABI between minor point releases) and even Red Hat, who expend a huge amount of effort on maintaining a stable kernel ABI, only make their kABI guarantees for a small subset of the actual kernel ABI.
3) Nobody complaining about this has any standing
"those vocal advocates such as Christoph, who are so offended by this, do not even own any copyright on the code we are distributing"
I'll be charitable and chalk this up to being misinformed rather than an outright lie.
There is certainly an argument that distributing GPL drivers and a shim layer to load them into a proprietary kernel may (depending on a whole host of things) create a derived work, and thus subject to the GPL.
Zach pointed out that he's not a lawyer and that he wasn't making an official response, but VMware's only real defences are likely to be along those lines. I personally think they'll have a hard time convincing a judge of that, but we'll see how it goes.
From my limited understanding, it started out completely separate, but has, over the past few years, started throwing away barriers and including GPL code directly to get better performance.
(IE they used to have GPL shims to keep the GPL parts separate and dynamically loaded, and don't anymore, they just directly include it in vmkernel).
VMware basically invented the modern x86 virtualisation environment, and there is still a lot of value in saying that they do it best as they have the most experience. Make that a commodity and I don't think you have the industry leader anymore.
This lawsuit reinforce the corporate legal mindset that "use of open source invites litigation...".
If this causes trained corporate attorneys to think that the use of open source software invites litigation then they should probably not be attorneys. If software comes with a license then follow the rules of the license. Is that really that hard to do? If you don't understand the terms of the license then that's what the lawyers are for.
If there's a ruling it will create precisely the kind of clarity corporate users want.
If there's a settlement it will show that free software developers are reasonable.
Either way, it will encourage corporations who are concerned about using free software to educate themselves rather than rely on FUD.
The original code is still "free" for the world to use, so there really isn't anything being taken.
I don't see where paulhauggis is claiming he's entitled to use other people's work without adhering to their conditions. Can you point out that claim explicitly for me? (edit: removed a stray nonsensical "it" for clarity)
> If you don't like their conditions for using it, then don't fucking use it.
This is what I generally do when it comes to GPLed libraries. Even closed source APIs generally grant me more "freedom" as a developer in how I redistribute my own programs invoking those APIs.
But hey, it's their right to release GPLed software. I make use of some GPLed software (generally only as a user, not a developer) and thank their developers for their contributions.
...but I don't think it's outrageous to find their definition of "free" a little odd, I get why it can be hard to follow their line of reasoning, and don't see the harm in trying to dig into the reasoning behind using the GPL over, say, a more permissive license such as MIT. Personally, I'm more inclined to release under permissive licenses - but this is your chance to convince paulhauggis of the merits of the former, no?
Why is it that whenever I bring up this point, the words "theft" and "stealing" are used by many.
However, when we are talking about copyright infringement, I am instantly corrected when I try to use those words to describe essentially the exact same practice?? (people here have even said it is their 'right' to freely copy copyrighted material).
"If you don't like their conditions for using it, then don't fucking use it. Why do you feel entitled to use other people's work without adhering to their conditions?"
So, it's not about giving and happiness anymore and happiness is it? Giving out software for free and then getting angry and going after someone in court when they don't use it to your liking is not freedom in my mind. I release all of my software under the BSD license. It's true freedom because I don't care what you do with it. It's a true unselfish act.
The GNU is just Stallman's attempt to destroy the commercial software industry, tie up our courts with ridiculous GNU violations, and essentially socialize it (a few years back, he had goals of the GNU and one of them is to have a 'compliance officer' mandated by the government in each company). I'm glad most of these attempts have failed.
Stallman isn't out to destroy commercial software. He's out to ensure freedom of computing for all. If commercial software can't function without taking away freedom, then that's the problem of those business models.
Your claim is "Stallman isn't out to destroy commercial software. If commercial software can't function without being free, then that's its problem" - where one is the very exact opposite of the other. "He doesn't want to kill it. But if it can't survive without being something it's inherently the opposite of, well, that's not us seeking its death, but rather 'a problem of their business model'." Hmm.
I should point out, that so far you are the only one in this conversation to use the word "theft", and the word "steal[ing]" was only used by one other commenter (who was not replying to you at all). (At least, this is true as of the 178 comment mark).
All software licenses at their core rely on some sort of copyright, including the GPL as well as proprietary licenses. This is at the heart, I believe, of what the parent poster meant by "Why do you feel entitled to use other people's work without adhering to their conditions?".
And as someone who both uses, and creates GPL code - let me assure you, it is most definitely not a "lure" to get companies to use it and then "release proprietary code".
So, it's not about giving and happiness anymore and happiness is it? Giving out software for free and then getting angry and going after someone in court when they don't use it to your liking is not freedom in my mind. I release all of my software under the BSD license. It's true freedom because I don't care what you do with it. It's a true unselfish act.
I don't think the parent post was saying it was all about giving and happiness. Nor do I, at least not directly. People spent time, money, etc.. creating code to release under a specific license. The license is clear, and well-known. It is not unreasonable to request that people respect the license when using the code. The reason why they chose the license isn't all that relevant, to be honest, when it comes to the validity of it.
It is clear that you don't like or respect the GPL very much; that is fine, and the appropriate option is the one you espoused: don't use it. I'm not sure I understand all your hostility, however.
edit: side note - I know many customers are very happy to adopt BSD / ASL software, but more hesitant to adopt GPL because not everything they do can or will be open-source. If, one day, everyone is using like BSD or ASL or GPL, switching to an all GPL world becomes more feasible.
I only wish more people could be this free.
[1] http://www.ifross.org/sites/default/files/130618%20Urteil%20... [2] http://www.it-recht-kanzlei.de/Urteil/2767/LG_Frankfurt_6.Zi... [3] http://www.internetrecht-rostock.de/urheberrecht23-gpl-lg-mu...
This can only have a positive outcome. The alternative is the GPL ceases to exist.
They'll probably pay up and drop dead once someone mumbles injunction.
Or maybe, they don't agree that they are?
My god, it's so simple...
The second they came back in compliance, they could redownload the exact source they copied, from wherever they got it, and they'd have a fresh, brand new license, with no problems.
GPLv3 fixed this "loophole".
In fact, you can see what others have attempted (and failed) to do to try to prevent this "loophole" from functioning.
Look at: www.ximpleware.com
(they were involved in GPL litigation against Versata)
It says, at the bottom "All licenses to any parties in litigation with XimpleWare have been expressly terminated. No new license, and no renewal of any revoked license, is granted to those parties as a result of re-downloading software from this or any other website"
This is there because they know of this exact problem, and didn't want versata to be able to avoid the lawsuit.
Of course, this text does not override the GPL in any way, and since it was given to them under the GPL, they can't now go back and say "those copies you have are retroactively under a different license". So it's pointless text, but hopefully this gives you an idea that what i said is not just "random lawyer kibitzing".