Slashdot Mirror
VMware May Violate Linux Copyrights
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.'"
'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. To reitterate The question then is whether the ESX OS is based on Linux
init 11 - for when you need that edge.
- Omit actual details in favor of baseless speculation.
This is how you optimize FUD: keep the claims mysterious. SCO kept up this strategy for, what, 4 or 5 years?why? forty-two.
Whether or not VMWare violates Linux copyrights, the mere fact that this is being discussed may add to the perception of the GPL as a "viral" license, and steer developers/businesses away from using Linux and other GPL software in their products.
"Anyone who [rips a CD] is probably engaging in copyright infringement." - David O. Carson
- Linux boots.
- Userspace tool kexec's the hypervisor (an odd way of doing things, so I wouldn't be surprised if this isn't actually what happens).
- The Linux kernel continues to run in a VM, providing an admin UI and drivers to the other guests, just as it does with Xen.
Looking at the patches that the VMWare guys have been sending in for hypervisor support, it seems like step three, at least, is accurate. Xen does the following in a typical install:- Linux is installed, with a Xen-compatible kernel.
- User reboots.
- Xen Hypervisor boots.
- Xen Hypervisor loads a Linux (or NetBSD or Solaris, or Windows with Xen Enterprise) domain 0 (privileged) guest, which runs the (userspace) management tools and provides device drivers.
There has, I believe, been some work done making Xen boot using kexec from Linux, so you can skip step 2 if you want. If you do this, then you get exactly the same set of steps as VMWare ESX.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.
I am TheRaven on Soylent News
1. It details information that is from an older and nearly 2.5 year old revision of the Product. The Current Version is 3.0.x and the relationship of the Linux system and the VMKernel has changed substantially.
2. VMWare licenses the Implimentation of Linux used in ESX from Red Hat, however nowhere is that mentioned in the Article.
Power Corrupts,Absolute Power Corrupts Absolutely, leaving one person(group)in charge is absolutely corrupt.
Go read this article (http://hardware.slashdot.org/article.pl?sid=07/08 /09/171248) from last week and note that Dell apparently will be booting a version of ESX from BIOS. If ESX can be booted with an alternate bootloader, it must not be that closely tied to RedHat.
Nothing for 6-digit uids?
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.
Cyrano de Maniac
My point is that there is a difference between using an OS as a bootloader and integrating an OS kernel with another one. There is precedence for the former (Novell Netware) and also for the latter (Windows 3.x/9x/Me). Linux doesn't integrate with the BIOS. It doesn't need it, it can be loaded with ANYTHING that bootstraps into the kernel. ESX Server seems to require a poorly hacked Linux 2.4 kernel. Nothing else can boot it. That's the difference.
My blog
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.
Capitalism: When it uses the carrot, it's called democracy. When it uses the stick, it's called fascism.
If you are talking about the kernel, then you should read the COPYING 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+). I harken back to the days of Netware NLMs. Netware didn't seem to want some sort of ownership for people loading things onto their kernel, nor did Microsoft demand rights for people distributing TSRs. So why is this different? And look where it got them. Well, I have no idea if Netware is still alive and/or relevant today, but the sheer number of crappy proprietary drivers written by two bit hardware companies has locked them to the shitty old i386 architecture, and it looks like this will continue to be the case for decades to come.
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.
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.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
By the standards of "derivative work" many purists would like to impose, any program written for Windows is a derivative work thereof, and therefore requires the permission of Microsoft to distribute.
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.
I don't know for sure, but if you look at the ESX hardware compatibility list it's quite limited. Which suggests that ESX isn't using Linux drivers; otherwise it would have much broader hardware support.
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.
An assertion is made that VMware infringes on Linux-related copyrights held by others, but no concrete proof has been shown. Why should they have to disprove an as-yet unproven allegation, regardless of who made it? When SCO made a statement about Linux without concrete proof, the overriding opinion was "Prove it." Why wouldn't the same standard be applied to someone making a statement about VMware? Shouldn't they be given the assumption of innocence until proven guilty?
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?
"It's too bad stupidity isn't painful." - A. S. LaVey
Under that logic almost all FSF software would be the property of Sun, AT&T, HP, IBM, etc. since for a long time it required SunOS, Solaris, HP/UX, AIX to run on.
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.
Finally! A year of moderation! Ready for 2019?
libraries are okay because they're just linked
Incorrect. You *cannot* link a GPL library into a non-gpl app. Check with your lawyers. Seriously..
Not true. First, Linus decides what isn't a derived work everytime he decides not to sue somebody. Linux is his creation, and only he has legal standing to sue. Congress could pass any law it wanted defining "derived works" and as long as Linus does nothing, no one else is allowed to sue anyone for infringement. Second, Linus can decide to sue, in which case the courts, not Congress, decides if his arguments have merit. Congress frequently passes laws that the courts promptly strike down; Slashdot readers frequently cheer when this happens.
Nothing for 6-digit uids?
He could have run the vmkmod module through a disassembler and compared it to parts of the Linux binary. It takes a lot of effort, but you can show that actual code has been copied that way, which is really what matters.
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.
Put identity in the browser.
Nuh-uh -- read the license before you spout off.
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.
Microsoft: "You've got questions. We've got dancing paperclips."
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.
Oh my, do we really want this? Microsoft is spending hugely on their own Virtual Server range and we want to put road blocks in front of VMWare?
Do not mock my vision of impractical footwear
>> VMkernel does not run on Linux kernel.
>> 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.