Software Freedom Conservancy Funds GPL Suit Against VMWare 188
Jeremy Allison - Sam writes with this excerpt from a news release from the Software Freedom Conservancy: Software Freedom Conservancy announces today Christoph Hellwig's lawsuit against VMware in the district court of Hamburg in Hamburg, Germany. This is the regretful but necessary next step in both Hellwig and Conservancy's ongoing effort to convince VMware to comply properly with the terms of the GPLv2, the license of Linux and many other Open Source and Free Software included in VMware's ESXi products. Serge Wroclawski points out the SFC's technical FAQ about the suit. One nugget: 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
How to help ! (Score:5, Informative)
To donate funds to Conservancy GPL compliance efforts see here:
http://sfconservancy.org/linux... [sfconservancy.org]
I'm dying of curiousity (Score:5, Interesting)
about VMWare's position on this. What on earth do they think trumps their obligations to the license they agreed to by using GPLv2 software in their product?
I wonder if they could possibly be as deluded and stubborn as SCO.
Re: (Score:2)
We've seen enough corporate sociopathy to accurately answer that question.
Why didn't they just go with BSD?
Re:I'm dying of curiousity (Score:5, Informative)
Re: (Score:3)
Which means their own code depends heavily on the Linux code they've borrowed. Which, to my layman's understanding, likely means the resulting combined work is a derived work of the Linux code concerned, at least under US norms. Which means they would need to follow the GPL for *all* the code concerned. Alternatively, if they don't like that, they have the choice of not using the Linux code they don't own.
My understanding is based on advice from US corporate counsel that I have dealt with. Corporate counsel
Re: (Score:2)
I think it is mainly due to the issue, that enough hardware manufactures support linux officially that it makes it easier for them.
I expect if they lose the case, they may switch to BSD, or even work with a deal with Microsoft to use the NT Kernel, instead.
Sometimes if you force someones hand they just might leave the game.
Re: (Score:3)
I guess the point has to be, what has VMWare bought to the game. They've essentially grabbed the Linux kernel, stacked their own kernel extensions on top of it and called it their own. I've never heard of them as major contributors to the Linux kernel itself.
Re:I'm dying of curiousity (Score:5, Informative)
You are mistaken in thinking they use the Linux kernel in ESXi. There is no Linux kernel anywhere in ESXi.
They have written their own operating system from scratch, and they did a complete rewrite of the kernel in the update from ESXi 3.5 to 4.0.
What they have done is copied a subset the interface API from the Linux kernel. Much how like the Wine Project has copied API details from Win32 without permission from Microsoft.
This allows existing driver source code that already works in Linux to be compiled using the VMware driver development kit into a binary that can be loaded as a driver in ESXi.
This means that hardware vendors can write the driver once, and then it could be built for either Linux or ESXi, so that seems beneficial for Linux users to have more drivers still being written for Linux.
This is considered a legacy framework, and VMware is already phasing this out... see details on the new native driver framework [virtuallyghetto.com]
This will be sad, as the native driver framework is proprietary, and it will likely no longer be possible to write your own drivers for ESXi, once vmklinux is gone, without purchasing the driver development tools at high $$$.
Also, major enterprises are running ESXi on much of their hardware, so the incentive may go away for many manufacturers to release information or develop Linux drivers; they can just produce their binary ESXi drivers and be done with it.
Re:I'm dying of curiousity (Score:5, Insightful)
My understanding is that your description is inaccurate.
Yes, they have implemented a number of Linux APIs in their own code. Additionally, they have sucked in bits of GPL Linux code that implemented bits of those APIs (i.e. NOT reimplemented, as WINE does). This is to allow ESXi to be able to re-use drivers from Linux, as you say. However, they didn't stop there, from what I understand. They also have ESXi use Linux GPL drivers.
My understanding, from what I've read, is that ESXi didn't just re-implement Linux APIs. ESXi also heavily depends on GPL licensed Linux code, both in the partial-reimplementation of Linux APIs, and in sucking in Linux GPL drivers. The issue is this direct re-use of GPL code, and ESXi's heavy dependence on that GPL code. That dependence likely makes ESXi a derived work of the Linux GPL code, and as such it - in its *entirety* - must be distributed in accordance with the GPL.
Alternatively, VMWare are quite free to not use code they didn't write and don't own, if they don't like the licence conditions.
This is very different from what WINE does, and to characterise the situation as like WINE seems to be quite inaccurate.
Re: (Score:3)
The Software Conservancy FAQ has a diagramme giving an abstract of what they allege has been copied:
http://sfconservancy.org/linux... [sfconservancy.org]
With respect to the drivers, it seems they've copied SCSI, USB and network drivers. Christoph Hellwig holding copyright to at least some of the SCSI drivers concerned, in addition to core code VMWare are alleged to have copied to implement required APIs for the drivers.
It seems you could give us a full list from an ESXi installation, if you wished, rather than just a selected
Re: (Score:2, Interesting)
Re: (Score:2)
There is no reason to think the court would require the entire stack / product to be opened. I don't anything any sensible read of the license would dictate that either.
At most vmkernel would have to be GPL licensed to use the code. The big question with the GPL (IANAL but have paid attention to this for a long time) is who can claim harm when its violated. Will the court agree the anyone who says they were harmed were harmed, is only the author harmed, are only users of the code harmed, is only the curr
Re: (Score:2)
IIUC, German law is different on this, and anyone is allowed to file suit to enforce anyone's copyright claim. I usually think this is a bad idea, but in this case I'm unsure.
Re: (Score:2)
Software licensing is always complicated, particularly when a product is a assembly of separate modules and pieces. If they have violated the license for the Linux kernel itself, I highly doubt this would touch their actual VMWare software at all, though a court could determine that. Conventional wisdom would indicate that the license does not cross the API boundary, so the copyright infringement ends at their kernel drivers. My understanding from the article is that it's the kernel drivers themselves (t
Re: (Score:2)
Or it may be due to a general confusion of the GPL/Willing to push its meaning to the limits.
This is why if I do any coding professionally, that is meant to be distributed, I avoid the GPL like a plague, and go with MIT or BSD licenses. Just so I have the freedom to choose how I want to expand the code.
Re: (Score:3)
if someone sees the terms of the GPL and then chooses not to use GPL-ed code, then that is the GPL working as intended. You're only supposed to use GPL code if you are willing to pay the licensing "fee", which is that your derivative work can only be distributed under the same terms.
If you choose not to use GPL code, that's perfectly OK. That's not a bug in the GPL, it's an intended feature.
vmware's fault is that they chose to use GPL-ed code while refusing to pay the license "fee". This directly harms n
Re:I'm dying of curiousity (Score:5, Informative)
They are taking a calculated risk knowing that very few GPL lawsuits actually went to court. They know it takes money to fight a legal battle and hope the opposing side doesn't have it, or will run out of it before reaching a final verdict. And finally, from the fact that they've been at this since 2012 - they probably think that it's a fairly cost-efficient way to buy more time and make business.
Re:I'm dying of curiousity (Score:5, Interesting)
it's a fairly cost-efficient way to buy more time and make business.
It sure is, and the people making such decisions face no consequences for violating the license. Yeah, maybe the corporation will get slapped with a tiny fine that reflects some small percentage of the money saved by incorporating the GPL'ed library, but how is that really any disincentive? It's more of an inconvenience, or simply a cost that gets processed through the EMC legal department, and then only maybe.
The money being spent on the prosecution won't actually change much behavior - there might be better causes to donate your money too (especially if you don't believe in imaginary property) than funding this expedition to behead a hydra.
Re:I'm dying of curiousity (Score:5, Interesting)
I highly doubt there was any such forethought. Much more likely (at least, at companies I've worked at) that some junior dev checked in GPL code as his own work, and it somehow slipped past code review (as can happen at crunch time).
I worked for "shrinkwrap software" companies for `15 years, and all of them had ironclad rules against using GPL software in any way (without a multi-month lawyer-approval process anyhow). One place I worked ran open source detection tools (similar to the plagiarism detection tools, but seeded with all the big free projects) as part of the daily build, they were so paranoid. I'd be surprised if this was deliberate on VMware's part. But then, maybe they're just a shitty company now?
That will be the interesting part of this case, IMO: was this deliberate, against official policy that the dev teams ignored, or some junior guy cheating?
Re:I'm dying of curiousity (Score:5, Insightful)
If that was the case VMware would (or should) have apologized, and removed the offending code to get into compliance. The fact that things are this far along signals at least some degree of maliciousness towards the terms of the GPL.
Hopefully, the penalty doesn't come out to be a meaningless fine. Instead, it should be a meaningless fine and forced compliance to the GPL - not through removal of the offending code (they have passed on that), but through open-sourcing of the entire product via GPLv2, effective immediately.
Re: (Score:2)
Chances are VMWare will eventually just release the bare minimum code in question after they hit a small threshold in legal fees and make the lawsuit moot.
Waiting for somebody else bring up litigation didn't cost VMWare much. They can simply wait until somebody calls them on it, then do the bare minimum to make it go away.
And nobody will continue to press on them because seeking "damages" is really hard to demonstrate in this kind of case and continuing to pay lawyers to try to punish VMWare will be cost
Re:I'm dying of curiousity (Score:4, Interesting)
That is, unless VMWare sincerely thinks they are in the right and have a defensible case. Then things get very interesting because then there is a chance the GPL could be undermined/weakened if they win and you will see a lot of groups start paying attention to make sure Software Freedom Conservancy doesn't screw up the case for GPL. (And you may see other parties interested in exploiting a weakened GPL.)
Re: (Score:3)
That may have started it, but keep in mind, talks have been ongoing for several years now. They have had every opportunity to correct the problem. The suit didn't happen until VMware made it clear that they have no intention of remedying the situation.
Re: (Score:2)
You may have noticed I don't care how it got there, only why they are acting now the way they are.
Many companies have this immune system response that if something happens that shouldn't have, they will at the same time punish someone internally, and defend themselves externally claiming everything is proper.
Re: (Score:3)
no, it's not the mistake of a junior dev - it's quite clear that vmkernel is entirely based around the linux kernel, most of the code is linux with some changes and additions.
either:
1. they're recklessly ignorant about software licenses
2. they're unable/unwilling to see the difference between BSD licensed code and GPL licensed code
3. they thought they'd get away with it, either because they thought nobody would notice or because the legal costs of license enforcement would be prohibitive.
Re: (Score:2)
But, ESX is not ESXi. ESXi is very different from ESX(and ESX was discontinued years ago). If they are really suing VMWare over ESXi but based on arguments about ESX, then it only looks like an ideology-based extortion-via-lawsuit attempt.
Re:I'm dying of curiousity (Score:5, Insightful)
It this your code?
No.
Why are you distributing this code?
We have a license.
What are the conditions of the license?
Interpreting these conditions (Score:5, Informative)
The controversial part, as I understand it, is the difference in interpretation of a license's conditions. For example, the difference between an "aggregation" and a "combined work" in the GPLv2 confused at least one Slashdot user [slashdot.org].
Re: (Score:2)
To take that a step further, the GPL is largely untested in court. Per TFS: "this, to our knowledge, marks the first time an enforcement case is exclusively focused on this type of legal question relating to GPL." IANAL, but any element of it that is reasonably subject to interpretation can be interpreted any way you like - until a case comes along to codify some other interpretation.
Therefore, from a strictly business point of view, you can interpret it in whatever way favors your business. However, if y
Re: (Score:2, Interesting)
To take that a step further, the GPL is largely untested in court.
Mostly because every violator's lawyers have looked at it and said "Give up. There's no way we can win this in a court case. This thing is ironclad."
Re: (Score:3)
Users don't have to worry about the GPL as anyone is allowed to use GPL code however they like, but it's only when you distribute it that you come up against its restrictions.
Re: (Score:2)
Not true. The FSF insists that dynamically linking proprietary code and GPL code (for example, by installing a proprietary extension in a GPL product) creates an infringing derivative work. Linus has said that creating a proprietary Linux device driver violates the GPL, even if it uses no GPL code, IIRC on the basis that the Linux driver API is itself a copyright work subject to the GPL.
(The GPLv2, at least, has language that seems to explicitly rule this interpretation out, but that doesn't appear to bot
Re: (Score:3)
the GPL is largely untested in court.
No it isn't. It's been tested at the federal level.
Daniel Wallace tried to get the GPL declared invalid through stretching of legal concepts, and was thusly shown how stupid /that/ is.
Re: (Score:2)
The controversial part, as I understand it, is the difference in interpretation of a license's conditions. For example, the difference between an "aggregation" and a "combined work" in the GPLv2 confused at least one Slashdot user.
Actually the ugliest part of the GPL which is clear as ink in law is what - if anything - makes inter-module communication derivative. The theory of derivative works mainly involve sections or elements reappearing in the derivative, like a composite made from a photo. It doesn't cover interfaces where independently developed code calls each other at all. If I wrap a GPL library into a web service, is calling it derivative? If the answer is yes, the GPL is extremely viral. If the answer is no, the GPL is in
Re: (Score:2)
You obviously do no understand the GPL. What you say here has specifically been addressed by the Affero GPL
That's not what I'm talking about, because it lacks the "distribution" part. What I'm talking about is what level of detachment is necessary to say that these bits of software depend on each other, but they're not derivative of each other. And thus the GPL wouldn't apply, even if you distribute them together.
Re: (Score:2)
Well... a software license is a type of contract. There's a principle in contract law; that if there are multiple ways which a condition can be interpreted, then it will be interpreted for purposes at time of adjuication in the manner that most favors the parties who did not produce the contract term / present the offer.
The same contract or license text can be interpreted in different ways for different cases.
Re: (Score:2)
For example, imagine NVidia has a driver for their graphics card, and they decide to port the driver to Linux. Of necessity, they will need to use some Linux kernel code to do so. Would that be a derivative work, or not?
Re: (Score:3)
Only the headers (that define interfaces used) not a derivative work.
Uses actual implementations, derivative work.
This was covered three of four times in the commercial software world.
Re: (Score:2)
Re: (Score:2)
So binary only drivers violate the GPL?
Re: (Score:2)
So binary only drivers violate the GPL?
No, but they really piss off people who disagree with Linus' interpretation of the GPL when it comes to binary only drivers.
I imagine this case actually hinges on an EXPORT_SYMBOL_GPL symbol that VMWare uses, or an API underneath one of those as an API aggregator, to which the aggregator would like to force all sub-APIs to reverse-inherit the label. Which is more or less similar to const-poisoning all the way down.
My expectation is that (1) If there is not explicit user, or (2) it's possible to recompile t
Re: (Score:2)
Why would the guy who wrote the driver in question not have standing?
Re: (Score:2)
Re: (Score:2)
Old thread. Linus apparently thought header files/interfaces could be copyrighted. He's been shown to be wrong in the USA. Thank dog.
Re: (Score:2)
Old thread. Linus apparently thought header files/interfaces could be copyrighted. He's been shown to be wrong in the USA.
A) If you're talking about Oracle VS Google, The appeals court overruled that [wikipedia.org]
B) It's not just 'using the header files', it's literally using the kernel code, so even if interfaces couldn't be copyrighted, that wouldn't apply here.
Re: (Score:2)
A. That sucks. Hopefully the supreme court returns sanity.
B. All interfaces 'literally use the code' If calling an interface makes my code a derived work that is very, very bad in a larger sense. SCO might have won with that argument.
Re: (Score:2)
All interfaces 'literally use the code' If calling an interface makes my code a derived work that is very, very bad in a larger sense.
Do you understand that the case of the linux kernel is different than the oracle vs google case? Google literally rewrote all the code from scratch, merely maintaining the APIs. In the case of the Linux kernel, drivers use the actual code written by Linus et al, it's not just using the APIs.
Re: (Score:2)
The deciding factor is whether or not it is using the defined API. If so, it is mere use and not derivation.
If the kernel has to be modified to add an API, there would be a clear violation. If the driver is digging underneath the public API, it is on very shaky ground.
In the case of the Linux kernel, the line has been made very clear for modules. The module declares it's license and the kernel decides based on that what will or will not be linked.
The kernel is GPL, you can change it ... (Score:2)
The deciding factor is whether or not it is using the defined API. If so, it is mere use and not derivation. If the kernel has to be modified to add an API, there would be a clear violation.
That is simply a fork of the kernel. If the forked kernel source is published there would seem to be no violation.
Re: (Score:2)
But then they MUST offer the modified source to anyone they distribute a binary to. They also get to field all of the support issues since the kernel maintainers won't touch a bug report if the kernel is tainted by a non-free module (for good reason).
Re: (Score:2)
But then they MUST offer the modified source to anyone they distribute a binary to. They also get to field all of the support issues since the kernel maintainers won't touch a bug report if the kernel is tainted by a non-free module (for good reason).
Seems a non-issue. If the bug is not in their code it could be replicated in the pristine kernel and reported to maintainers. Since the forked kernel would be used at the core of one of their virtual machines they would be the natural contact point. From the customer's perspective VMware failed, not some embedded kernel that they don't know or care about.
Re: (Score:2)
If it's a non issue, they should release the modified source and be done with it. They've had 3 years to do so and flatly refuse, so the law suit.
Re: (Score:2)
The deciding factor is whether or not it is using the defined API. If so, it is mere use and not derivation.
You are wrong; if you care to understand why, Linus explains [yarchive.net] in more depth.
Re: (Score:2)
Actually, he said the same thing I said, in different words.
For example, he points out that using the defined API, such as system calls is not a derived work, but digging into the internals is.
Re: (Score:2)
Specifically he says if the symbol is exported with _GPL at it's end he thinks it's protected.
Apparently he invented an 'intent of author standard'. Which would suck in the bigger sense.
I sure hope Oracle loses the header case.
Re: (Score:2)
The userspacr process does not execute any kernel code, just request that the kernel do something.
Any function call can be characterized in the same way.
Re:I'm dying of curiousity (Score:5, Insightful)
It's only "controversial" in software where people think that "what's mine is mine and what's yours is mine" is an acceptable way to think about other people's work.
The GPL is a clever hack of copyright law written by someone that knew what he was doing. I think people see RMS and think they can get away with sh*t because they think he's not smart enough to hire a real lawyer.
Re: (Score:2)
And yet we have had three versions of the GPL, several of the LGPL, and even more of the AGPL. Not to mention the rest of the derivatives...
It just goes to show that the GPL isn't even considered watertight by its creators, just like any other license.
Re: (Score:2)
And GPL is very much "what's yours is mine and what's mine also makes yours mine"
Re: (Score:2)
Where things get tricky is the "mere aggregation" clause in the GPL. AIUI a storage or distribution medium containing two unrelated programs is a derivative work of both those programs but thanks to the "mere aggregation" clause it's perfectly OK if one of those is GPL and one is propietary.
So the question becomes what level of interaction/interconnection/integration does there need to be between two works distributed together such that they no longer satisfy the "mere aggregation" clause and hence violate
Re: (Score:2)
The FSF insists that dynamic linking - in fact anything that puts two pieces of code into the same address space - creates a derivative work.
Re:I'm dying of curiousity (Score:5, Interesting)
If, and thats a big if, VMWare have done anything in violation of the license at all - the "technical FAQ" is very light indeed on actual technical details, instead mostly talking about how Conservancy went to great lengths to do anything they could to open a dialog before suing. The "technical" part of the FAQ is a single diagram which explains very little in how they think VMWares approach is violating either the GPL or copyright.
This is going to be something to watch, as its going to be an interesting one.
Re: (Score:2)
Yes, I'm quite curious about the lack of specifics.
It starts off with a very reasonable BusyBox violation that need to be corrected, and then veers off into claiming there's a much bigger problem without specifically stating it. It SOUNDS like they're saying VMWare's hypervisor is loaded by something that loads from the kernel and therefore it all must be GPL.
I'd like to be corrected if this is wrong.
Linus' own comment about a driver ported to Linux not falling under the GPL because the driver effort doesn'
Re: (Score:2)
The diagram was fairly clear that various large parts of the Linux kernel are modified and incorporated into the vmkernel. It doesn't say exactly what parts but at least one of them is the SCSI subsystem.
Re: (Score:2)
No, the diagram is very simplified, only showing 3 layers, and that the alleged Linux kernel and ESXi hypervisor kernel occupy kernel space. It is very disingenious, since ESXi is bare metal and stand-alone, unlike ESX, which was discontinued years ago. In fact, when reading the link to mailing lists someone in the thread posted, many of the complaints are about ESX, and invalid for ESXi.
In fact, the entire situation smells fishy.... I wonder if they are trying to appropriate VMware code somehow to improve
Re: (Score:2)
The diagram remains clear. It shows what I said it does. Your question is more about if the diagram shows reality or not.
I note though that the Linux kernel is at the bare metal level itself.
Re: (Score:2)
But with ESXi, the linux kernel runs on top of the hypervisor.
Re: (Score:2)
And according to the diagram, parts of the linux kernel are incorporated INTO the hypervisor. That, I imagine, is what has lead to a legal dispute.
Re: (Score:2)
Which is the bogus claim, as anyone who's worked with ESXi and developing drivers for it can testify(which I have done). ESX, otoh, ran sort of parallell with the Linux kernel, but ESX was discontinued years ago.
Re: (Score:2)
I have no opinion on the facts of the situation. I only know what the diagram clearly claims.
Re: (Score:2)
But you still made factual claims, based merely on the diagram
Re: (Score:2)
Yes, I made factual claims ABOUT THE DIAGRAM.
Re: (Score:2)
The entire thing is highly confusing, since ESXi tossed out the Linux kernel components from the hypervisor and runs on bare metal since 4.1(released in july 2010), and ESX, which is not the same thing as ESXi . And BusyBox is not a part of the kernel. Also, the source code for the Open Source components for ESXi 5 have been available for download since the start. So, judging by that technical FAQ, is their argument "You share kernel space with GPL'd stuff, now hand us the goodies or we'll sue you!"?. (Whic
Re:I'm dying of curiousity (Score:5, Interesting)
They're a for-profit corporation, who see this as their bread and butter technology.
All you need is an idiot CEO to say "I want this" and an asshole lawyer to agree with him.
Are you honestly expecting principle, logic, and honesty from this?
It's a corporation looking out for its own interests. If that means fucking everybody else over or coming up with your own interpretation of the law? So be it.
I expect nothing less from this kind of situation.
Re: (Score:2)
Re: (Score:2)
What on earth do they think trumps their obligations to the license they agreed to by using GPLv2 software in their product?
Their profits i imagine.
A human brain will accept all sorts of compromised logic to get something it really wants.
More than curious, (Score:2)
Re:More than curious, (Score:5, Informative)
1. Made their management tools run on only Windows, shitting on the Linux community
2. Deprecated VMWare Server 1.x (free and very functional) for VMWare Server 2 (free and barely functional)
There are far better free alternatives out there nowadays if you're not managing a full-blown cloud infrastructure (see: LXC and KVM). And if you are, there's OpenStack.
Re: (Score:2)
Their management tools are transitioning, slowly to web based. There are tasks that ONLY work in the web client now but there are also tasks that ONLY exist in the Windows only desktop client.
If you're only running guests, then you can get away with the slow web client. If you're managing the hosts you need to use both, for different things now.
Re: (Score:2)
Sorry it took so long, but it was a resourcing decision at the time. Spend Engineer's time building new features, or porting the client to Linux.... seems like an easy decision for me in 2005. I am certain lots of homework went into this decision.
As for OP's comment #2... really? You're still upset over a decision made ~10 years ago?
I find it interesting how people are quick
Re: (Score:2)
Those aren't the reasons why I currently shy away from VMWare (it sounded like he was asking more from a moral point of view, hence the answers I gave), but those reasons, plus others, prompted me to start looking for alternatives.
The biggest problems I had with VMWare back then was 1.) when they made the switch to the web-based managed interface for VMWare Server 2 (it was sluggish and very unresponsive compared to the VMWare Server 1 management console) and 2.) the lack of a mature CLI toolset for managin
Re: (Score:2)
FLASH based, through a web page. And it's a horrible mash of crap compared to the native client.
Re: (Score:2)
and not able to be used by browsers in Linux because of flash version needed
it can be used by browser on OS X though
Re: (Score:2)
So you prefer ones that shit on the Windows community?
Yes.
Re: (Score:3)
Re:More than curious, (Score:4, Informative)
Judging by the diagram, the "offending sections" are huge swathes of virtualisation-specific code that ESXi runs on, written or modified by VMWare.
Being forced to open-source their largest software project is a quite conceivable (even if unlikely) outcome. Not everyone who has a part in the Linux kernel is going to accept "Here's some cash, ssshh, don't tell anyone we cocked up" compared to forcing them to open their code.
VMWare accepted a (believed to be) legally binding agreement to open any code that modified or become part of the kernel under GPL licences to anyone who asked. You can't always buy your way out of such obligations with money, and the courts may well end up showing that.
And that... that's gotta hurt the bottom line to have vast portions of ESXi available as open-source software.
Re: (Score:2)
Re: (Score:2)
One possibility is that suit is based on the theory that simply sharing an address space between the GPL code and the proprietary code, e.g., because they are both running in kernel mode, is enough to create a derivative work in violation of the GPL.
As far as I know, this theory has not yet been tested in court - am I mistaken?
Re: (Score:2)
we are wiping it tomorrow and rerolling all of our vm's with hyper-v or xen
Re: (Score:2)
Not even going to wait until the courts reach a verdict?
Is the disruption to your organization worth it?
Here's a suggestion for a verdict (Score:5, Interesting)
Anyone found in willful and deliberate violation of the GPL showed that they have no interest in copyright or its protection. Hence they implicitly and irrevocably agree that they will not pursue anyone violating their copyright.
That should take care of this pretty quickly. You don't even have to look for GPL violations in products anymore, corporations will do that for you in the products of their competitor, hoping to kick them out of the market that way.
Re: (Score:2)
That's actually a VERY good point.
We could see MICROSOFT help fund this GPLv2 lawsuit against VMWare since they have a competing product.
Wouldn't that be bizarre.
Re: (Score:2)
You [wouldn't] even have to look for GPL violations in products anymore, corporations will do that for you in the products of their competitor, hoping to kick them out of the market that way.
Great idea!
I'm concerned my competition is sucking up all of my users with their superior product and marketing. So, naturally, I was wondering: How can I discourage users from using my competitors product?
That's it! I should force my competitor to make his product free! The users will come flocking straight to me. Brilliant!
Re:Silly people (Score:4, Informative)
After skimming the GPLv2, found under section 3:
For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable.
Seems like it includes building and installation to me.
Installation on what machine? (Score:3)
But does it include "compilation and installation" on the end user's machines, or only on developer hardware available only to a select few? The latter interpretation leads to the Tivoization loophole in the GPLv2. GPLv3 tightened this by defining "Installation Information", its counterpart to GPLv2's "scripts used to control [...] installation", to require that execution be possible "in that User Product" if the work is designed for a consumer platform.
Re: (Score:3)
But does it include "compilation and installation" on the end user's machines, or only on developer hardware available only to a select few? The latter interpretation leads to the Tivoization loophole in the GPLv2. GPLv3 tightened this by defining "Installation Information", its counterpart to GPLv2's "scripts used to control [...] installation", to require that execution be possible "in that User Product" if the work is designed for a consumer platform.
Well, having used VMware Workstation 8 and 9, I can was able to download and modify the Linux drivers provided by VMware, necessary to fix some kernel related bugs (http://clocksmind.blogspot.com/2013/04/vmware-workstation-8-and-linux-kernel-38.html) as kernels changed over time but VMware simply didn't keep up with compatibility.
So frankly, I'm a little surprised but then, may this is for a different edition or something.
Re: (Score:3)
Well, having used VMware Workstation 8 and 9, I can was able to download and modify the Linux drivers provided by VMware, necessary to fix some kernel related bugs
I don't think the lawsuit is over vmware tools. VMware provides source code to most of the VMware tools components; often they are installed by building the source code.
The VMware hypervisor includes a special management Virtual Machine run by the vmkernel which uses Busybox.
They do not include the source code for Busybox. However, there i
Re: (Score:2)
Wrong.
BusyBox is part of the source code ISO's on their website. Don't even need a login to grab them.
Re: (Score:2)
Reading the FAQ and TFA, this is more about BusyBox than the Linux Kernel.
No, it started with BusyBox, but it's now mostly about the Linux kernel. The BusyBox issues are largely or completely resolved. As explained in the FAQ: "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."
Re: (Score:2, Insightful)