VMware GPL Enforcement Suit in Germany Continues
sfconservancy.org
sfconservancy.org
The lawyers in that company have a somewhat different interpretation of the GPL/LGPL than I've seen elsewhere in my career.
VMWare is a pretty scummy company, thankfully open source virtualization has come a long way - it's not 100% yet but oVirt does a pretty good job at replacing vCenter IMO.
If the problem is that you have to use a new app ID and cannot seamlessly install over the existing app, how is that different from using LGPL software installed in /usr/bin on a machine where you haven't been granted root access?
(removed wall off text quoting 6a, was a bit too long)
I think the confusion that one would have to "open source the whole project" comes from the offer that many GPL authors make to violators of their license. Very frequently, if you violate a GPL license, the author will offer to allow you to continue to use the code as long as you comply with the GPL. The author does not have to make such an offer and, in fact, this point is spelled out very clearly in the GPL itself. If you violate the license, you lose any right to use the software, unless forgiven by the author. Since many authors are not interested in suing anyone and are only interested in compliance, they make the offer anyway. Usually the offer is accepted, or the GPL code is removed from the software (there have been very, very few GPL violations that have actually gone to court).
If you buy some software library from somewhere, it will also have a license for use. You are only allowed to use the software according to the license. If you use it in other ways (for example, you accidentally use it for product A, but you have only licensed it for product B), you can expect to be sued. You will have to pay some money and may have an injunction against distributing your product. It is exactly the same.
I've talked with several lawyers at large tech companies that I worked with who avoided the GPL. In one particular case, they had signed an agreement to avoid the GPL (very likely with Microsoft) and were thus were obliged to forbid its use. However, in other cases, I have found the sticking point usually is in the way the agreement is made.
In most software licenses, you can not run the software without agreeing to the license. With the GPL, it explicitly says that you may use the software for any purpose without accepting it. You may even modify the software and even link it to your own code. You only have to accept the license when you distribute it. For the lawyers I talked to, this was very confusing. They had never seen language like that before and were very hesitant to touch a license like it, just because they couldn't relate it to the very precise legal language that they were familiar with. I think, as the GPL has gained popularity, this problem is going away. Most IP lawyers are familiar with the license now and understand how it works.
Having said that, there are a whole class of programmers who believe what you have said. This is unfortunately ignorance, reinforced by decades of misinformation spread by Microsoft when they decided they needed to wage war against the GPL. As times change (and even MS has used the GPL now), this misunderstanding seems to decrease, so I don't think it is a major worry.
Basically it seems kind of silly to tightly define it as "going to jail", when the practical aspects of willfully violating an NDA can ruin your life (which may or may not be worse than going to jail depending on circumstances)
It was specifically referred to as your "liberty" which is incorrect. I never argued that violating an NDA could or could not result in something worse than jail time.
(For that matter, even prisoners have some liberties...)
I don't know of any settled law about this question; IANAL and I haven't really looked. But I think the distinction that would make the most sense would not be based on anything technical, but on how an API is used in practice, and in particular on whether it's used by multiple unrelated parties. Ie, the same set of function calls can be either an irrelevant division within a single work, or a partition which separates independent works, depending on whether there're several different vendors/programs who call and implement them, or only one, and on whether the author of a new program who wanted to use that interface could reasonably do so.
The word "arbitrary separation" also seems to cover intention rather than technical facts. Did VMware create the ESXi intention to bypass copyright, or was it create as a natural part in the development of VMware products.
Since it's an api, the "in practice" is some other piece of code, so I would still call it a technical issue.
The German GPL has some interesting workarounds for a number of these rights; mostly they do it by declaring that the GPL is a contract and not a license. You can give away lots of "rights" in a contract I'd you're explicit.... But not quite all of them. Among the problematic clauses is the one that controls the license of derivative works. Another interesting clause is liability, but that's another conversation.
Another important example is severe defacement, which is not allowed. To most known recent case is Berlin's new main railway station which was built without the elaborate ceiling the architect planned due to cost and time constraints. The architect sued and won the case. They later signed a deal. If that hadn't happened, the owner Deutsche Bahn would have had to replace the ceiling with the originally planned version on their own cost.
Also the defacement thing is a rather special case. If you'd buy a painting and defaced or burned it, no one would care. I also don't see how it could possibly apply to software or music. It's certainly an interesting case and kind of weird but apart from that not all that important.
In practice you can sign away pretty much all of your rights and none of those that you can't sign over really matter when it comes to software.
It's not like the GPL is some questionable license either. It's a well established licence and has been tested in German court. Based on the information from this court case it also doesn't appear as if that's in anyway in doubt. The focus is entirely on where the lines should be drawn in this particular case.
The directive does not make such a distinction. If running in the same memory space would be a criteria then everything running on a MMU-less system would be a derivative work of everything it uses.
That seems damning.
When Company B is sued by the copyright holder of Harry Potter, they hold up their license and say, "See. We have permission". My (very limited) understanding of copyright law is that the court would quickly find the license invalid since Company A never had the ability to grant the license. Company B would lose the lawsuit, pay some money and have an injunction against distributing their work. They would then be invited to sue Company A to recover their costs.
It exports many symbols for drivers (proprietary or otherwise) to use internally. Some symbols are exported GPL_ONLY, which means that only GPL drivers may call those symbols.
I fail to see how those symbols being exported makes the relevant functionality public vs. internal to the kernel [1]
> Some symbols are exported GPL_ONLY, which means that only GPL drivers may call those symbols.
I don't think that is accurate. Drivers are necessarily derivative works of the kernel and have to be licensed under the GPL anyway. In practice closed source driver modules seem to be tolerated, even if they are not strictly compliant with the kernel's license.[2] The purpose behind the GPL_ONLY symbols is that a driver has to declare itself compliant with the license to use the symbols. If a proprietary driver would declare itself GPL compliant to gain access to GPL_only symbols, its author would be in even muddier waters than before.
[1] https://www.kernel.org/doc/Documentation/stable_api_nonsense... [2] http://archive.linuxgizmos.com/are-non-gpl-loadable-linux-dr...
It can be a grey area. Quoting Linus himself
> But one gray area in particular is something like a driver that was originally written for another operating system (ie clearly not a derived work of Linux in origin).
It's not stable, but it's an API. I can write and distribute a proprietary module that uses those symbols. I can't do that with symbols that aren't exported.
> I don't think that is accurate. Drivers are necessarily derivative works of the kernel and have to be licensed under the GPL anyway. In practice closed source driver modules seem to be tolerated, even if they are not strictly compliant with the kernel's license.[2] The purpose behind the GPL_ONLY symbols is that a driver has to declare itself compliant with the license to use the symbols. If a proprietary driver would declare itself GPL compliant to gain access to GPL_only symbols, its author would be in even muddier waters than before.
Now you're just being pedantic. Obviously when I said "GPL drivers" I mean those which explicitly include a MODULE_LICENSE("GPL") directive. What else would I mean? I'm not engaging in legal speculation.
The test used by the industry for derivative works usually requires a full implementation of the same code with another OS than Linux (e.g the nvidia drivers which shares 95% of the codebase between Linux and Windows). Some ported-over-from-an-RTOS drivers fall into this as well, but there's rarely enough value in them that they shouldn't be opensourced.
In the end there are so many nice features hidden behind EXPORT_SYMBOL_GPL that it's rarely worth it to go the proprietary route.
Does it only apply if you resell / package the source code as a deliverable product? Where is this line drawn between software downloaded as a binary vs. software delivered to you in a hosted fashion with an API or similar (i.e. SaaS)?
This is something that the GPL version 3 tried to fix.
> Amazon don't distribute any of their Xen-derived code,
> so they don't have to give the source out either.
>
> This is something that the GPL version 3 tried to fix.
I thought they have a kernel module with a GPL wrapper, like the NVidia graphics module which would be more contentious.
edit: oh, I remember I tried to ask him once, and he called me a Stallmanite or something like that and sent me some insults.
Not in the FSF's opinion. User-does-the-link does not change whether the blob is derivative work or not.
So blob drivers that clearly wasn't originally designed for Linux and work via GPL-ed shim (which isn't the case with VMWare) may be not derivative work. Anyway I think it's wrong to say that kernel developers (at least Dave Airlie as we talk about DRM/GPU drivers) don't do anything because they do have anti-leech rules that actually working:
- Some features only exposed as GPL-only as their usage clearly prove that driver is derivative work of kernel. See DMA-BUF.
- Open source kernel drivers that only used by proprietary code aren't going mainline. This is benefit whole ecosystem more than GPL-only kernel with blobs in user-space.
So it's become more expensive to maintain out-of-tree drivers and not all features are available for them. This actually working because Intel does have open source kernel and user-space driver even if their Android user-space is proprietary. AMD also switching to hybrid model.
Personally I find these rules more reasonable than attempts to enforce copyleft that are extremely hard from legal standpoint as there is no single copyright holder. For example FSF require to sign CLA to contribute to their projects in order to relicense code to newer GPL version or enforce it.
The marking or not marking of things as GPL-only has no affect on whether or not using those things makes the using thing a derivative work. Whether or not X is a derivate work of Y is determined by how much of Y's copyrighted expression is incorporated into X.
What I wanted to say is that GPL_ONLY exist and does what it's intend to do: make it clear to driver maintainers (Nvidia as GPU vendor) that certain functionality shouldn't be used within proprietary code.
Of course this isn't actual legal limitation, but Nvidia also want to have open source drivers for Tegra and certainly don't want to get a finger on their next pull request.
What is controlling on this question is copyright law, not the FSF's opinion. And, clearly, the FSF isn't a neutral authority here, they have a positive interest in portraying the need for a license as being as broadly as they can to encourage use of the license and adherence to its other conditions.
No, but things are significantly more straightforward if the combination Linux-kernel-plus-nVidia-module is distributed; this combination is clearly a derivative of both the Linux kernel and the nVidia module that make it up. There is far more room for argument if the module is distributed on its own.
https://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL:
"If a library is released under the GPL (not the LGPL), does that mean that any software which uses it has to be under the GPL or a GPL-compatible license?
Yes, because the software as it is actually run includes the library."But they are arguing that the API they added makes the proprietary vmkernel a separate work and the distribution with vmklinux a "mere aggregation", no?
[0] https://twitter.com/rootkovska/status/518037037480697857
Anyone more familiar with German law that can explain this to me? Normally, civil filings are open to the public in the U.S., which seems like a good thing, so I'm wondering why German law allows this.
Oh, wait, I haven't used their stuff in years. Heh.
hope they make this right
It's not even asking that much, honestly. The kernel components are a very small portion of the VMware stack, and are pretty clearly an extension of GPL code. The argument VMware is making would effectively destroy the GPL, if successful. Any company could fork a GPL project, build some extensions with some minor handwaving in the general direction of abstracting it out into "modules" and call it a non-derivative work.
This isn't, from my understanding, merely a binary blob that gets loaded into any standard Linux kernel, as some proprietary Linux driver modules do; there's seems to be a steady state around this use case, where Linus and the community is reasonably comfortable with it (even though some other GPL projects take a harder line on this sort of extension). But, what VMware is shipping is a broken version of Linux (i.e. one that does not have the protections of the GPL for end users).
The conversation with VMware has been going on for years, since it was first noticed they were non-compliant with the BusyBox license. VMware has always had no respect for the GPL. Which would be fine, if they stayed the fuck out of Linux. But, if they want to play in the Linux market, they need to play by the rules that the rest of the industry plays by.
GPL is opposite. It's clearly state that your code depend on GPLed code become derivative work.
That is not the case.
The answer to whether or not X is a derivate work of Y is the same regardless of the license of Y. It is answered by looking at how much of Y's copyrighted expression has been incorporated into X.
All the license of Y determines is whether or not, in the case that X is a derivative work, that making or distributing such a derivative work is allowed.
Some licenses have contributed to confusion over this by using terms like "derived work" or "derived from", which people confuse with "derivative work".
Maybe that was a bad example though, but do we really want to disallow opensource project from extending proprietary software without the blessing of the copyright owner? Because that is the other side of the coin.
Though for officially supported add ons system of proprietary products usually state what license you can or can't use. All kind of tools that access and patch process memory are not in danger because most of time they modify process state via 3rd party OS APIs and they do not interact with programs they patching.
In same time changes that patcher do within process can't go under GPL and fact that developers keep licensing that code under open source licenses doesn't change the fact it's break EULA.
Isn't this the current status quo? How can a patched DLL be anything but a derivative work?