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.
I don't think it is as clear cut at all, but that makes it much more interesting. I left a comment there, but it bears some repeating I think
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
I worked at VMware for over 11 years and was one of the first dozen or so people on the vmkernel team (which produced ESX and later ESXi), although I left several years ago.
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.
From reading the linked article, it read to me like the complaint asserts that VMKernel itself is a violation of the GPL. If I'm wrong, please feel free to correct me, but these statements seems to point in this direction
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
If so, that would be like me finding some code on Github, changing it a little, and then including it in my own closed source application, clearly a violation of the GPL.
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.
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.
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.
This sounds more like Oracle vs Google regarding Java, where VMWare, like Google, is stating that APIs are not copyrightable, and the SFC, like Oracle, is claiming that even those APIs are copyrightable.
There is a huge difference: in this case the Vmware product does include linux kernel code. So there's definitely some reproduction and distribution of copyrighted parts even excluding the use of APIs.
I don't see the commonalities except that both are about copyright. Has there been any information that the kernel API is being claimed to be copyrighted, or header files, or are VMWare claiming that no copyrighted code has actually been distributed?
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.
Thank you, that makes a lot of sense. I can see now how VMware can believe in good faith that they're in compliance (and in fact did a fairly major move towards compliance with ESXi) and Conservancy can believe in good faith that they're not.
Re: [1] There's an argument that ESXi was released to handle these concerns, which predate ESXi's release. I ran venturecake which first published the story, showing how the Linux kernel started vmkernel, not the other way around. Proprietary kernel modules are considered derived works unless they can run independently (eg, nvidia.ko isn't generally considered to be a derived work because it's largely code ported from other platforms). However retrospectively making something portable doesn't change it's previous status as a derived work, and ESXi wouldn't be popular without ESX, which wouldn't exist without Linux booting vmware (despite vmware's protestation otherwise - load ESX and watch the boot process).
I dunno, a bootloader seems like the most clear-cut example of something not being a derived work you could get - it doesn't care about the code being bootloeaded and vice-versa, and the API between the two is about as trivial as it can get. What matters according to the GPL isn't whether the code runs on other platforms but how deeply intertwined it is with the kernel; for most Linux drivers, whether it runs on other platforms is a good rule of thumb for determining this, but it kind of breaks down for ESX.
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.)
> nvidia.ko isn't generally considered to be a derived work
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.
Aside, shouldn't you be parsimonious with subscriber links for LWN and not post them publicly? I haven't had a LWN subscription in a while, but I really like their business model. I would not have posted this link myself.
No, the subscriber links are for exactly this kind of situation. They are to allow you to link to articles when it's relevant to a discussion, as long as you don't abuse them by doing something like posting a regular feed of all LWN articles or submitting every single one to Reddit/HN.
Jonathan Corbet, editor of LWN, frequently posts his own subscriber links to LWN articles:
Reasonable question (and I don't think you should be downvoted for it), but no, LWN editors (including Jonathan Corbet) have explicitly said that they're very happy to see LWN subscriber links posted to social networking sites and discussion sites. The main thing they don't want to see is someone systematically posting links for every single subscriber-only article.
Interesting. My reading is that there are two components. The first is the Linux bootstrap, which they are entirely in compliance for. The second is vmkernel, which includes some GPL code whose source they're releasing, but vmkernel as a whole is not GPL; this is almost certainly out of compliance (but also easily fixable), unless they're doing something to isolate "vmkdrivers" from the rest of vmkernel.
(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.
They still use it for bootstrapping, right? I know they've gotten rid of the Red Hat-ish userspace, but according to the LWN article, there's still a Linux kernel involved and a kernel module used to pass control to vmkernel.
(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?)
What's curious is that VMkernel's "personality" for ESXi userworlds (which are analogous to sessions IIRC) is it implements the x64 Linux ABI, with some signal/syscalls masked.
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.
Wait, Microsoft is distributing and loading GPL'ed kernel modules for windows? I did not even know windows kernel had modules, and even less so that they distribute and use third-party developed gplv2 modules.
Are Microsoft shipping this with windows 7, windows 8, or windows server 2012, and is there a list somewhere for the shipped modules?
If I understand you correctly, you think Microsoft would be held liable for copyright infringement if someone installs a GPLv2 driver into their own personal installation of windows?
That is not how copyright infringement work. To be held liable, you have to distribute* a copyrighted work and then fail to comply with the license. Microsoft is as you say not distributing GPL'ed kernel modules, so there is no possible way* for them to help liable for GPLv2 windows kernel modules.
A third-party windows distributor could be help liable if they bundled the modules with preinstalled windows machines. In that case, that third party would have to stop distributing the module, or beg Microsoft to release the source code for windows under GPLv2.
* The pirate bay crew got charged for assisting in copyright infringement without distribution, but at least there was the accusation that someone somewhere did distribute a copyrighted work without permission.
I donated too. If you're sitting on the side lines: remember that that the Software Freedom Conservancy is a non-profit while VMware is multi-billion dollar corporate entity with very deep pockets and high-priced lawyers.
I'm surprised it took this long. I can't really blame them, after 15 years of ignoring the GPL, they probably figured nobody would ever come up with the financial resources to actually go after them. This is going to take years to come to a resolution and millions and millions of dollars in lawyers fees.
I doubt that it'll come to that. There are some really nasty consequences of being found to violate the GPL:
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...
From what I understand, there is no obvious way to re-gain a license to GPL'd code once it's been terminated (short of asking every single individual contributor). There is the distinct possibility that VMWare could be enjoined from using Linux in any way if they are ruled against (and it sticks on appeal).
"there is no obvious way to re-gain a license to GPL'd code once it's been terminated"
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).
DannyBee, I have stayed mostly silent on this thread (given my direct involvement with the Conservancy and the lawsuit in question), but I'd like to draw your attention to copyleft.org's details regarding this issue:
https://copyleft.org/guide/comprehensive-gpl-guidech8.html
In particular, take a look at Footnote 4 on that page, which documents state of this situation succinctly.
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.
Uh, you is whoever they get the program from. It says that.
That's what 'each time you redistribute means". It means if i redistribute to someone, this is what happens.
Recipient is whoever i redistribute to.
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).
They do not get a license, so they couldn't even legally download the new copy. It's the same as downloading pirated Windows (except that when downloading pirated Windows the hosting site shares the blame with the downloader, of course).
All sections apply. It's just that the original comment misunderstood what section 6 says. This is the only way to read section 6 coherently with section 4 and the rest of the license.
Sure, it's an interpretation.
[edit] the point is: nowhere as clear as the original comment expresses.
You have yet to point out any misunderstanding or why this is wrong past saying "that makes the license crappy in some ways". Which may in fact, be true.
But this is a policy argument, not a legal one, and it will absolutely never win in court over very clear and unambiguous text.
Sorry, but no.
They get all the rights. The rights auto-terminate if they are still violating the license (so they lose that license).
If they have cleaned up their act, they gain all rights.
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.
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.
It's odd you keep saying "all open source lawyers" agree with you, because I can't figure out who you could possibly mean. Like, which specific human being do you believe agrees with you? I've studied copyleft almost daily for two decades, and I'm aware of the position of nearly anyone who has ever called themselves an "open source lawyer" in the world, so one would think I'd know who you are talking about since I "know them all" and I can't figure out who I could ask that would give me the same argument as you give.
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.
This is the way I understand the license as well. That's one of the reasons the GPL3 has language to the effect of regaining the license: http://www.gnu.org/copyleft/gpl.html#section8
Even then, a copyright-holder can still permanently terminate your rights if they so choose and notify you of such termination.
That would be an interesting result. To my knowledge the GPL (any version) hasn't actually been litigated to the point of a published decision (would love to hear that it had).
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)
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.
Taking games as an example, in todays AAA games most have a long list of licensed work, with everything from personal permission slips to standard licenses like proprietary licensed third-party, lgpl, apache, bsd, mit and project specific ones. If they mess up on any single of those license requirement, they risk inoperation for the whole product.
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.
> Taking games as an example, in todays AAA games most have a long list of licensed work, with everything from personal permission slips to standard licenses like proprietary licensed third-party, lgpl, apache, bsd, mit and project specific ones. If they mess up on any single of those license requirement, they risk inoperation for the whole product.
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.
Commercial engines generally are not compatible with license requirement from other licenses. That is however outside the point since the argument parent post made is that the threat of enforcing third-party licenses will make every company switch to self-production only.
> [...] the argument parent post made is that the threat of enforcing third-party licenses will make every company switch to self-production only.
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.
How would this problem only apply to GPL? If you do not give the 5% revenue to unreal when using their engine, I am sure they will sue. A company can not pick and choose which license agreement to follow and which to ignore, or they risk inoperation from lawsuits.
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.
The worst cases are better with most other licenses though:
* 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.
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.
>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..."
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. "
"The business risk would become too great that they might be litigated by a rival into inoperation."
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).
I don't disagree that only people with an ownership right in the copyright have standing, but I note that this has been worked around by a variety of means. The poster child being
people like Prenda Law who used dubious techniques to get just enough copyright ownership on something (in their case porn) to sue. Also, as many have noted and some have experienced, at least in the US it is pretty easy to get sued whether or not the case has merit, and ignoring it results not in it being dismissed because of lack of standing, but a judgement against you by default.
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.
Except, of course, Prenda Law didn't get around copyright law, but their case is exceptional and I don't think it, or what you've correctly pointed out about how in the US it is easy to get sued, demonstrates much beyond the advantages of loser pays law systems (as I understand it, all of the world but the US).
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.
> "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."
This interpretation of the decision is wrong, and I think this is also not a right interpretation of copyright and of the GPL.
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).
In the case of copyleft software, I would think so, and onestone tells us this has been established in France. So I've amended my posting (minimally, near the end of the edit window).
> 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.
You forget something: most enterprise SW is for internal use only, so they don't and won't care one bit about GPL's related ligations.
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.
Meh. Enterprise is already terrified of GPL -- but they have to use it because there's simply too much good software written under the license. There's lots of emphasis these days to "pretty please avoid using GPL" but they simply put up with it in the end because it's counter-productive not to.
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.
Yeah, which company on Earth large enough to have an IT department doesn't use Linux somewhere, for example? I know I would be hard pressed to find one.
One of the major changes to GPLv3 was to fix this problem, so companies that goes back into compliance can automatically get permission again. However, the code in question here is gplv2 so no such luck.
I would expect that most users of software that violates the GPL are not lawyers, so I don't see how your statement "in the end you're only helping lawyers" could possibly be correct: enforcement to gain compliance is never going to primary help lawyers in an event.
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.
This will take place in German courts and from all what I known about the judicature here you cannot stretch a process endlessly if the judges don't allow it. Also this should a civil court (??) case, where usually the loosing side pays for the lawyers of the other side. (When you're right it is in general, from a financial point, always good to sue, because you only have to cover the court fees, about 150$ or nothing if you can prove that you have a low income.)
As a VMWare customer, this makes me consider their ethics. If they're unethical, shouldn't we look into switching away from their product?
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?
Well, the go-to is generally considered Redhat with their RHEV product line. There are a plethora of other options out there, but if you're looking for an open source path with enterprise support they are generally candidate #1. Oracle has an option but... ya. Citrix Xenserver would be the other major player.
Disclaimer; I'm not a sysadmin. Data point below is second hand knowledge from helping to track down issues with the ops team.
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.
Controversial opinion here probably, but vmware has been doing virt for a long time, so it makes sense that it's rather polished if you fit there eco-system.
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..
VMWare has more than just ESXi: managing ESXi, HA and DRS, vmotion, etc. Open source lacks what VMWare offers to enterprise customers. Not every company can develop tools to manage hypervisors (say, kvm) like Google does.
Openstack is trying to solve this problem; but so far, openstack seems to be more of marketing, less of success stories.
If you're a customer, you could raise the issue with VMware through your support channel. You could potentially be at risk of a GPL violation yourself if your license agreement with VMware does not indemnify you.
You might want to consider Joyent's Smart Data Center. It is all opensource and you can buy support. A lot of the people leaving the engineering teams at Sun/Oracle ended up at Joyent.
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.
Hyper-V is great, also System Center Virtual Machine manager kicks the pants out of VCloud Director and friends.
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.
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.
It's quite a difference too, above 10%. This is on raw device pass through however, which is not very useful to most people. As soon as you are on a file system things change considerably (pretty much the other way around, on my workload).
The problem with OpenStack as a replacement for VMware (outside of the complexity of installation), is that most people using VMware have an expectation of high availability being table stakes (a VM automatically being rebooted on a different node in the event of a node failure). OpenStack assumes the software on the front end can tolerate a node going down in it's current form and that the front-end application will just route around a node failure.
Well, since you work there, perhaps you can let them know that while www.suse.com resolves to an IPv6 address, your webserver doesn't actually serve up any pages via IPv6. So for those with native v6 connectivity like myself, the page just won't load.
Also available in some commercial distro's of OpenStack, like Metacloud.
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.
XenServer seems a more apt replacement for ESXi. They are both tier 1 hypervisors and come with comparable features and management options, and both install from an ISO with easy setup.
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.
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, so it never percolates down to engineering.
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.
Out of curiosity - if GPL is taken so seriously, why do customers have to jump through so many hoops to get copies of source. Last I checked you are required to send a letter via snailmail to legal counsel @vmware and if they deem you worthy, they send back physical media with copies of the source.
I can't imagine a less open-source friendly system...
If you want a copy of the source you can get it via the Open Source tab on most VMware products download page. You'll find the open source distributed for ESXi under the VMware vSphere Open Source group on this page -> https://my.vmware.com/web/vmware/info/slug/datacenter_cloud_...
It doesn't require a snail mail letter as far as I can tell.
It's not required to be "friendly" nor is it required to be convenient for you. It's designed to be compliant, internally audit-able, and for free they get the ability to frustrate you into not requesting copies.
It is taken as seriously as is has to be. They are required to provide the source, they are not required to make obtaining the source a pleasant experience.
It's not really about busybox. Conservancy started looking at the use of Busybox, and then realized that vmkernel was using the Linux kernel in ways that (in their eyes) violated the Linux kernel's license. The present lawsuit is about that, and Christoph Hellwig is suing as a Linux rightsholder.
Swapping out Linux in vmkernel would be much harder.
Or you know, they can stop being jerks and release sources for the code they derived from the GPLed one.
> 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.
Especially since the GPL is one of the most widely known copyleft licenses out there. I can expect a layman to not know about it, but the software engineers at VMWare?
It sounds from the above comment that even if engineers raise this issue, their legal department dismisses it. I find it bizarre for any serious company.
Yes exactly. Most large organizations (with in house counsel) take feedback from software/systems engineering very seriously. For compliance (especially licenses) contract requirements etc. Legal exists to serve/protect the organization.
You assume that a software engineer knows any more about copyright law than a random person from the street? Cuz I'm pretty sure they don't also in virtually every company it will be "don't bother with this, let the lawyers deal with it".
Companies violate patents licenses agreements and all other legal nonsense all the time, that's what they got lawyers for.
> Being so lax on legal matters for such company shows very low level of their management's professionalism.
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.
> 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.
It sounds like it has everything to do with professionalism.
Ethics don't enter into it--you might be thinking of negative externalities. That's the responsibility of the person running things next fiscal year. In the mean time, quit worrying and go deliver shareholder value.
> That's the responsibility of the person running things next fiscal year. In the mean time, quit worrying and go deliver shareholder value.
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.
Look, "professional" is a lie told by successful people to keep dullards in line. There is the almighty dollar, the pursuit of that dollar, and what you have to do to attain that dollar--if you aren't in this to get paid as much as the market will bear and damn the consequences, you sir are the unprofessional one.
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.
What a bizarre world we live in where willful violations of a legally binding license (a license which attempts to keep knowledge in the open) is considered nothing more than a "calculated risk."
I'm sure you've never jaywalked or littered or sped in a car and thought to yourself "there's no way i'll get in trouble for this so i'll do it anyway". Except in VMware's case they are much large than a single person so their list of "low risk" crimes is larger.
> It merely means that the management views GPL violations as a low-probability calculated risk.
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.
Any large company is very aware of GPL or else they're incompetent. Having worked at several companies I can assure you it's on their radar. If they're not compliant, it's a choice.
> It's just that this GPL thing doesn't even register on their legal radar...
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.
> At this point they will release the busybox sources, potentially including the in-house version, but not under GPL
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?
I seem to be missing the part where this behavior of VMWare is not unethical.
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.
Was said lawsuit also taking place in Germany?
IANAL, but my understanding of the German copyright law (being a citizen of said country) is that such a proof is not a possible solution.
I think it's far more likely that huhtenberg is speaks of what he knows not.
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.
So this could be really interesting from a precedent standpoint because it could help clarify the legality of the GPL in various contexts in the court.
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.
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.
I'm not sure it will be that groundbreaking; this seems to be yet another busybox violation litigated in Germany, of which we have had several already.
It started out that way, but as I understand the release materials here, this is now about Hellwig's copyright on core kernel code (e.g. the VFS), which VMWare has integrated into their product.
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.
I've seen it argued on HN that the GPL's definition of a derivative work differs from the legal definition, and if you never distribute the GPL'd code, you aren't bound by it.
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.
In theory that would not be copyright infringement as you describe it, since the entity that would be accused never distributed the GPL'ed licensed work.
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.
The GPL does say the conditions are only on redistribution. But I think that's how it works with other derived works as well, by default. The GPL is all about how you can relicense it to other people using only the same license, you're free to do whatever you want if you never give anyone your modified code.
17 USC §106 refers to the right "to prepare derivative works" as an exclusive right of a copyright holder, so creating the derivative work in the first place could be a copyright infringement under U.S. copyright law even if it is never distributed to anyone. So you can potentially infringe copyright in your basement by making a fan translation of some movie or novel into your language.
The first time the GPL mentions "derivative work" is in paragraph 0, in the phrase "derivative work under copyright law", which would suggest that they are not redefining it. However, it immidietly goes on to say:
"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"
It means the definition under copyright in addition to translations and modified versions. Different countries have different copyright definitions, and the translation of a work is not always the same CC.
You missed the next paragraph, in which it says that as they looked further into it, they discovered Linux kernel violations as well.
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.
Is there any information about why VMware thinks they are not bound by the GPL? Curious whether they have a technical justification, rather than simply being a blatant licensing violation.
I'm not fully up-to-date on this case, but there is a bit of wiggle room on what counts as a derivative work, even in kernelspace.
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"?
That's a great link. That clarifies the relationship between the vmkernel and Linux.
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.
They do. Those who builds and sells the stuff that VMware runs on has tech centers set up just to support Linux.
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.
> 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).
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 :)
Unfortunately, it sounds like recent versions of ESXi avoid having a privileged Linux virtual machine for drivers by incorporating GPLed Linux kernel code into their proprietary hypervisor, which allows it to run Linux drivers and userland software directly. Which is why they're in deep legal hot water right now.
From the wording in the link it sounds like they include modified GPL code and don't publish that, not that they are expected to open-source ESXi (or whatever it is called right now) entirely:
> 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).
They then say that, while they were poking around at BusyBox violations, they also realized that vmkernel is probably continuing to infringe Linux, and decided to pursue that. (I think VMware's been vaguely moving away from putting large parts of Linux in vmkernel, but may not have moved fast enough.)
"[...] 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."
> 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.
The article is bit muddled in describing the nature of the charges; it seems like there are multiple GPL violations. Withholding the source to BusyBox is one of them, in addition to the violations involving the Linux kernel.
The issue is that there's linking, not merely calling from.
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.
"Linking" isn't really a legal term either; it doesn't occur either in copyright law (of course), nor does it occur in the text of the GPLv2. It's true that in non-legally-binding prose, the FSF describes the GPLv2 as prohibiting linking with proprietary apps, but the license itself doesn't draw that line. The FSF may have intended to draw that distinction with the LGPL, but that doesn't necessarily mean that it's there in a legally-binding fashion.
("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.
> 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.
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.
"Linking" and "calling" are also technical concepts, not legal. The GPL and LGPL claim a distinction, but that claim may not have teeth in all cases (as I understand it as a non-lawyer who has worked with FOSS for more than half my existence).
To continue the OpenAFS example though, while OpenAFS.ko itself considered as a standalone item might well be not a derivative work, that doesn't mean that you if distributed a work comprising the Linux kernel combined with OpenAFS that that combined work might not be a derivative (of both the Linux kernel and OpenAFS).
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 is providing the core kernel routines like scheduling and memory management
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.
Don't know specifically, but these usually come down to hair-splitting over terms like "linking" and "derived work" and so on. I guess VMware think they can convince a judge that the way their code interacts with the Linux kernel does not cause it to fall under the GPL's source-publication requirement. On the other hand, I know Christoph enough to know how insanely smart and persistent he is. If he's confident enough in his conclusions to go forward with this, I wouldn't want to be on the other team.
And frankly, some of the hair-splitting differentiators need to be settled in court. It seems more obvious in compiled software (such as what VMWare is doing and with BusyBox), but if you think about the persistent issues that arise with what is the difference between "derived works" and "linked works" with web apps (even before JavaScript started taking over the client and server side), there are a lot of questions that I have long believed only a court could really settle to at least give a legal precedent.
This is just speculation but I suspect this is a matter of being caught with their pants down. They violated the GPL, but to comply with the license would mean that they'd have to release a lot of code that they don't want to release.
From the page, it seems like there's been ongoing negotiation, so I am guessing there's been a lot of stalling.
> They violated the GPL, but to comply with the license would mean that they'd have to release a lot of code that they don't want to release.
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.
>In other words the legal outcome of GPL violations is not necessarily being forced to release the rest of the code as GPL.
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.
Right but they also didn't have rights to distribute the work. There will be issues of demonstrating damages, but you can't just say "Oh sure I violated your copyright... but now that you take me to court, I'll stop." and expect to get off without paying anything.
Well that's why I said they'll probably be forced to pay a fine or damages. They could for example look at number of licenses VMWare sold with the GPL code in it, then take a fraction of the profits from each or something like that.
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)
The Software Freedom Conservancy did recently announce that they've started working with kernel developers who are willing to have SFC enforce the GPL on their behalf, so that they can directly work on Linux rather than just busybox.
It's not the first instance. Harald Welte, a member of FSF-Europe and an IPtables contributor, did spend a lot of time enforcing the GPL against violators in Germany, as the driving force behind the late gpl-violations.org.
I didn't bother to read it all, but all that stuff makes me feel apathy. I very much believe, that VMWare did something wrong. Maybe even illegal. I believe they deserve to be punished for that. But what I see here doesn't look like punishment at all.
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.
I'm no lawyer, but isn't the most exciting fact about this lawsuit that it takes place in Germany? That means no settlements or other silly American business.
Just two parties making their case in front of a judge, and the judge deciding who is right and what the repercussions are.
Surely, two parties can settle a civil case in Germany. Otherwise every dispute between two neighbors over a fence would end up taking up the court's time when they are perfectly capable of agreeing to a solution.
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.
What could a German court do to VMWare? I am wondering if this is a similar situation to where France wanted to sue Google[2] and more recently Fox News[1].
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)
National laws apply in the corresponding country in principle universally. If a company from country A sells something in country B then the sale is under the laws of country B.
Would it be possible for this case to be kick up to a higher court and eventually encompassing the entire EU? I assume these copyright/copyleft cases are standardized across all of EU.
> It appears that Paris would not be able to recoup funds from Fox News in the event of any judgment in its favor, based on a 2010 law that prohibits US courts from enforcing any foreign judgement for defamation except in narrow circumstances.
"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).
The wayback machine* has Zachary Amsden's opinion in 2007 why the vmkernel (and other components) are not in violation of GPL. It's an interesting read.
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.
Points (1) and (2) aren't relevant - nobody in this case is making those arguments. Point (3) is more interesting. He makes three arguments there.
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.
> 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.
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.]
There is already precedent for the separation of software licenses at process boundaries, if the GPL was viral enough to cause issues with virtual appliances then Linux distributions would be in deep water already since they are a product of the combined software included on the installation media.
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).
The claim, I believe, is that vmkernel uses Linux in a way that is not permissible under the GPL. At least that was the issue as people understood it the last time this came up: http://www.cnet.com/news/vmware-and-the-gpl-round-two/
Once the Conservancy has sorted out this GPL situation, perhaps they can investigate the legality of the commercial GPL-using ecosystem around WordPress.
This is not old code. This is the kernel of ESXi 5.5 (Their current product) and its highly likely that ESXi 6.0 has the same problem. This is not old code, it is the heart of their product offerings.
It's not the heart of their product offerings. The heart is vCenter, the kernel is only a small piece. Citrix has no problem with making Xen free software.
I disagree. When you think of all the functions the vmware hypervisor has a range of features where it is quite far ahead of the competition including Fault Tolerance. vSphere is the management interface, its telling the vmkernel to do things, but the vmkernels are able to do a lot of work without the vsphere service being available (HA, etc).
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.
I support Hellwig and the Conservancy in their claim, but I see an unfortunate consequence: This further hinders corporate adoption of open source software.
This lawsuit reinforce the corporate legal mindset that "use of open source invites litigation...".
If licenses don't get enforced, "free" game engines like Unreal can't operate. You get the world where the only available code which do not require long meetings, massive upfront cash, lawyers and NDA's are those tiny exceptions which are given under public domain. That is not a future anyone should wish onto the software industry.
We are way past the point where that sort of advocacy is necessary. Companies need to understand that compliance is relevant too. VmWare has no excuse for this.
> 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.
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.