VMware May Violate Linux Copyrights 443
Nailer writes "Bloomberg believe VMware's IPO today may the largest technology offering since Google. But doubts have been cast over the company's supposedly proprietary ESX product, as top 10 Linux contributor Christopher Hellwig claims the software may violate Linux kernel copyrights. 'Is Hellwig right, and is VMware a derived product of Linux? Unless vmkernel can be loaded without the Linux kernel, it would appear so. VMware was developed from another, long ago OS created as a research project, but it's unclear whether vmkernel was ported from that OS or rewritten as the Linux-requiring binary blob. What's more of an issue is that VMware had these serious questions posed directly to them a year ago, repeated in a public forum many times since, but have yet to respond at all.'"
Re:If it cannot be loaded without the linux kernel (Score:5, Insightful)
'Q. Does ESX Server Run on Linux? On Windows?
A. ESX Server runs natively on server hardware, without a host operating system.
Ok, so ESX doesn't need a host OS. It's pretty clear that ESX installs directly on the hardware without needing Windows, Linux or any other OS installed first - ESX itself is the OS. The question then is whether the ESX OS is based on Linux.
Re:They made a movie about this with Charlie Sheen (Score:5, Insightful)
Adds to Perception of GPL as Viral (Score:3, Insightful)
Uh, what? (Score:5, Insightful)
Now, to be fair, Xen actually does include some code (stuff like atomic operations, for example) from Linux (and is GPL'd, making this a non-issue), but this was done to save time, rather than because the code has to come from Linux.
Re:Adds to Perception of GPL as Viral (Score:5, Insightful)
Re:Adds to Perception of GPL as Viral (Score:4, Insightful)
See, whether or not it's "viral" and whether you get to use Linux and other GPL software "in your products" depend entirely on what kind of software it is and what you're doing with it.
If you merely took Linux code (which is copyrighted) and incorporated it into your product, you've just swiped code -- which, oddly enough, is illegal under the law and the not provided for in the license. If it was LGPL and you can link to it, then you can make it as part of your product since it is just plumbing.
Nobody is saying you can't write your own closed-source application which runs on top of Linux. But, you don't get to steal parts of Linux or anything else under the GPL and pass it off as yours -- that's just plain old copyright violation. There's no blanket exemption to re-use it any way you choose; you must adhere to the license granted to you.
So, if someone wrote software based on Linux and find themselves running afoul of the GPL, it's likely not because GPL code is 'viral', it's that you tried to steal code you had no right to. Which is entirely different from this whole 'viral' talk.
u
What companies need is an occasional reminder that they specifically can't just incorporate Linux and other GPL code "into their products" any way they choose. It just doesn't work that way. As an end user, you can make use of GPL'd software until you're blue in the face with pretty much no obligations. As a company, you can't just take parts of it without any consequences. It's not a public domain code repository to pillage to your heart's content -- it's Open Source (TM), and there are rules about what you can and can't do with it.
I'm not sure that steering "developers/bsinesses away from using Linux and other GPL software in their products" is anywhere near as bad as you're thinking it might be.
Cheers
I call shenanigans..Article is Pure FUD (Score:4, Insightful)
2. VMWare licenses the Implimentation of Linux used in ESX from Red Hat, however nowhere is that mentioned in the Article.
FUD based on a fallacy (Score:5, Insightful)
Re:Old news? (Score:2, Insightful)
That is simply incorrect.
By your statement any userland program that made use of Linux-only interfaces (e.g. hugetlbfs, most anything in /proc or /sys, video4linux devices, etc) would also be a derived work, which is obviously not the case. Even within the realm of kernel-internal interfaces, it is difficult to argue that a derived work is created by using interfaces whose function and calling requirements you understand without needing to know the specifics of the implementation (though this seems to be the thrust of the thinking behind EXPORT_SYMBOL_GPL).
Personally I would argue that nothing short of code-copying creates a derived work, but other intelligent people hold contrary views. I'm waiting for the day that someone wakes up to the fact that the whole EXPORT_SYMBOL* nonsense is at its heart a form of Digital Restrictions Management. Not that closed-source modules haven't caused me rare moments of headache, but in this case the cure seems more repugnant than the ailment.
Re:Old news? (Score:2, Insightful)
This isn't Tivoization (Score:4, Insightful)
I think Christopher Hellwig put it best: Exactly. Linux would've pushed legal action by now if they thought it would get them anywhere. The defense rests, end of story. So what is the point of this article? To whine about how unfair this is? Ok, maybe. But such is life.
--
Capitalism: When it uses the carrot, it's called Democracy. When it uses the stick, it's called fascism.
Re:Adds to Perception of GPL as Viral (Score:2, Insightful)
>the GPL.
It's more than that. It is the right of the copyright holder.
What is being alleged is that a corporation is abridging the rights of one or more individuals. The suggestion (raised several times already in this thread) that this should be overlooked because of their community affiliations, is preposterous.
Re:Help me understand... (Score:5, Insightful)
If you are talking about the kernel, then you should read the COPYING [kernel.org] file: if your work is a derived work of the Linux kernel, then it must be released under the GPL. If it is not a derived work of the kernel then you can do whatever you want.
If you are talking about one of the many platforms based on Linux (e.g., RHEL, Debian GNU/Linux, etc) then you must consider the licensing terms of every work which you derive from (e.g., the GNU C Library, GTK+).
BTW, I must correct your implied assertion that the free software community wants "ownership" of a vendor's code. This is not the case! We merely want vendors to respect the licensing terms of any works from which they create a derivative work.
Copyright is viral (Score:4, Insightful)
The GPL is not viral. Copyright is viral. You can't take any copyrighted work and incorporate it into a new work of your own without permission from the copyright holder (excepting Fair Use). The work you incorporated "infects" your work.
Copyrighted work distributed under the GPL is different only in that it does give permission for creation of derivative works, given certain limitations. If you don't want to comply with the license, don't incorporate GPL'd code into your software. Go buy some commercial code and use that instead -- but be sure to comply with the terms of that license, because "viral" copyright will burn you if you don't. Or, if you prefer, you can write your own code so you don't need a license at all.
This is not rocket surgery. It's not even the slightest bit confusing, except when made deliberately so by FUDsters.
Re:Old news? (Score:3, Insightful)
IMO, a derivative work has to include some significant* part the work from which it is derived, not merely reference it. But I don't have a team of lawyers to back up that opinion, alas.
*by which I mean things like the names of API functions aren't sufficient.
Re:Hardware Support (Score:2, Insightful)
Re:Help me understand... (Score:5, Insightful)
No.
Derived from Linux source code = Have to show the code
Running on Linux = whatever you want to do
Derived from linux concepts (commands, interfaces, etc) or using linux API's = whatever you want to do
Please don't spread rediculous misconceptions about what the GPL forces to be free, it hurts the GPL movement because people will avoid it for fear its will "infect" their code, I had to get our lawyers sign off that checking our proprietary code into the GPL'd CVS would not force our code to be GPL; arguements that using Open Office make your term paper GPL or that somehow the ability to run Halo under WINE means you have a right to the source code is the type of anti-GNU FUD MS wants to spread.
Re:Help me understand... (Score:3, Insightful)
I'm not saying they infringed and I'm not saying they didn't, as I honestly don't know. Regardless, shouldn't the impetus on the accuser to prove their case?
Re:Help me understand... (Score:4, Insightful)
FSF did not distribute SunOS, Solaris, HP/UX etc. and therefore they were not bound by those licenses. The same applies to say NVIDIA, since they don't distribute GPL-covered software either. VMWare has no such luck -- they distribute both GPL-covered and proprietary software, and they even do it on the same CD. Now, the GPL could have outright forbidden this "mere aggregation", which would obviously have been completely enforceable. Instead, the GPL allows shipping both on the same media -- but only if both pieces work independently of each other. And the VMWare hypervisor seems to not work without the Linux kernel. Whoops.
Re:Help me understand... (Score:4, Insightful)
Incorrect. You *cannot* link a GPL library into a non-gpl app. Check with your lawyers. Seriously..
Re:Derived Works (Score:3, Insightful)
Re:They made a movie about this with Charlie Sheen (Score:2, Insightful)
So you didn't actually read the article? The problem is not copied code: it's the use of a binary-only module which links to and requires the Linux kernel to boot the ESX server. According to Linus' guidance, this steps over the line into an area where binary modules can't be used. The iSCSI component developer is refusing to let ESX use any of his code until they answer questions about how the ESX kernel module interacts with the Linux kernel.
Re:Help me understand... (Score:3, Insightful)
Static linking implies derivation, because the executable contains code from the library as well as the covered program. Shared library linkages only imply derivation if the program in question is written to use an interface which is specific to the covered program -- so the standard C library does not apply. It makes sense: If I'm writing to the libgnome API, I'm creating a product which would not possibly work without libgnome. If I'm writing to the standard C API, I'm creating something which works with all manner of standard C libraries; if my code happens to be dynamically linked against a GPLed C library implementation, that doesn't change the fact that that code was not in any way written with knowledge of the specific implementation.
The GPL, taken literally, can be reasonably complied with.
Re:Help me understand... (Score:3, Insightful)
Re:Help me understand... (Score:3, Insightful)
Agrees that writing software against a different program's API implies derivation? No court, but it's a pretty damned easy argument to make, at least for programs written in C and C++ (and other languages where libraries' headers are included during a precompilation phase): You're writing your code the way you do only because of the external API being structured the way it is, and would not write your code that way otherwise. Moreover, structures and values from the API's header files are copied into your source during precompilation. There may not be settled precedent -- but in a precedent-setting case, this would be a favorable side to be on.
Agrees that writing software against a standard API doesn't imply derivation from any specific implementation of that API? Well, duh. If you statically link your code with that implementation to generate a binary, that binary certainly is a derivative work -- but if you're doing dynamic linking, your generated binary does not contain any portion of the work (other than the structures &c. from the header -- but because those are generated to conform with the 3rd-party API, there's no creative [and thus no copyrightable] element in them), and your source neither contains any portion of the work or is influenced in any way individually traceable back to the work.
The FSF's position may not have been fully validated by case law, but it is a very reasonable interpretation, prone to being effectively argued in court. Remember that to a significant extent, the reason there is relatively little case law regarding the FSF's interpretation of their licenses is that offending parties whom the FSF has communicated with almost universally settle.
Take off shoe, aim, squeeze trigger... (Score:3, Insightful)
Re:VMkernel is a kernel... (Score:3, Insightful)
>> Please, let me reiterate this again: VMKernel DOES NOT RUN ON Linux.
RTFA. According to everyone, including VMware, vmkernel is started from Linux.
The article has been updated to include a video of an ESX machine booting.
Run 'strings' on the 'vmnix' kernel on your machine (or just watch it boot). It's Linux. Nobody hides this fact.
As TFA mentions, vmkernel is started by S90vmware, which insmods vmkmod to load it.