I worked at VMware for a couple years and this was a contributing factor to why I left. I know a number of people that felt it was a GPL-violation and refused to work on that product because of it, myself included.
The lawyers in that company have a somewhat different interpretation of the GPL/LGPL than I've seen elsewhere in my career.
Quite honestly, I'm more worried about inaccurately portraying their viewpoint. Most of my teams run-ins with the lawyers was LGPL related, and their interpretation of LGPL 2.1 section 6a.
I don't really see how 6a is open for interpretation. If you use a library licensed under LGPL2.1 or higher the user must be able to replace the library with a modified copy, this is why Mono cannot be used on iOS or Android without a commercial license.
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.
Is that true now that the latest ios/xcode combo allows anyone with an apple id to self sign most apps (those that don't require specific entitlements like push messages)?
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?
You've always been able to do this. You could distribute your Xamarin.iOS application as source-only and require users compile it themselves without being in violation of the license, but you still cannot release it on the App Store without a commercial license (since it is impossible without jailbreaking to replace the .so).
Everywhere I've worked, anything with the letters "G", "P", and "L" was to be avoided like toxic waste. Just too much concern about running afoul of it and having to open source the whole product.
The GPL is a license like any other license. If you violate it, you may be sued. The result of that lawsuit would be that you would be liable to hand over an amount of money and also potentially have an injunction on further distributing your product. This is the exact same thing that would happen if you violated any other license, so there is not any additional risk to using the GPL.
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.
I wish you had made these comments earlier so more people would have seen them. In fact, I think you should write a blog post out of this comment and publish it.
Hmm... I appreciate the kind words, but I wonder if it would be better if someone like Bradley Kuhn wrote it. I know he has written several posts discussing his approach to GPL violators, but I'm not sure if he has written anything as explicit as "What happens when you get sued for a GPL violation". I think it is an excellent idea.
Well no that doesn't technically mean he gave up his "liberty", it just means he promised not to do it at risk of being sued for breach of contract. That's all. You can't be thrown in jail for breaking an NDA.
But you can end up in bankruptcy court. And of course if you're found guilty of violating your NDA that shows up in background checks which pretty much makes you unemployable in the US (in the tech industry at least).
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)
> 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.
What is liberty if not the absence of restrictions on your choices. Clearly, the repercussions described might heavily impact your liberty in that sense.
(For that matter, even prisoners have some liberties...)
It's near pointless arguing actual logical positions based on real definitions here. People will bring in their own assumptions and project those onto any words you use. When a logical rebuttal can't be made, some will just downmod you to bury your arguments (as you can see actually happened).
If you have to add "practically speaking" to a statement then I would argue your statement is poor in the first place. There is a difference in signing away a "liberty" and signing a contract. A really, really huge difference. Let's just speak clearly.
I can't agree. Context is almost always a sufficient indicator. If you really can't distinguish the difference between what's literally said/written and the intent I do feel bad for you but the reality is that most people can do it just fine.
That's why 'malandrew asked, "Are you at liberty to elaborate?" - in other words, "does the langauge of NDA or whatever other contract you have signed, or the risk your boss getting medieval on your ass, preclude you from elaborating?".
It's a question, but unfortunately, no direct answer that can be given will really tell us about the actual language. All that can be given is someone else's interpretation of the language, which may or may not be accurate.
This seems to hinge on the legal nature of the interface between vmklinux (a Linux kernel module created by VMware) and ESXi (VMware's virtualization software). If that interface separates two legally distinct works, then VMware is in the clear; if it doesn't, then VMware has created a derivative work of the Linux kernel and is in violation of the GPL.
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.
My IANAL impression of the courts is also that they don't want to make a judgement based on technical distinctions, but rather looks at how the work was used and what the intentions was. Did VMware distribute vmklinux without the linux kernel, and was it written with the intention to distribute it was a collected work.
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.
Wonder if they can "fix" this by sponsoring an open source project that would find some token "use" of the interface. Then court can point to it and say -- look, another use!
This is further complicated by the precarious position of copyleft in Germany in particular, and the EU in general. In German basic property law, there are certain "rights" of a creator which CANNOT be given away.
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.
There are certain rights you can't sign away, even if you wanted to. An example the right to be named as the creator. Simplified, it's not allowed to put the name of some one else on your creation – no matter what the contract says and what you agreed to. Such an agreement can be revoked at any time by the creator.
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.
Pretending someone else created something is a shitty thing to do anyway.
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.
> Finally, the response explains that vmkernel and vmklinux don't “communicate over an interface”, rather they run in the same process as a single computer program. Thus, VMK API, as used by vmklinux, is not an “interface” as set forth in the EU Directive 2009/24/EC.
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.
The argument is that they are literally the same process, with no API or interface between them. It’s instead used like a library, loaded by the linker.
Everything in kernel space is "the same process". Using something as a library exactly means that there is an API to use. If the proprietary part of the kernel module directly pokes around in private symbols in the kernel then I can see that there might be a problem, but if only publicly available interfaces are used then it should be under the definition in article 10 as far as I can tell.
Reading the examples provided, it seems to be the case that they modified many of the kernel components to call directly into their proprietary component (not via an established abstraction, like driver hooks).
That I agree might be a problem. If the case ends up being decided in favor of Christoph Hellwig based on that then I wonder if what happens isn't just that companies gets a third party to distribute a modified kernel (as source code) with the interfaces they need added and then use that. It may still technically be a violation, but judging intent isn't easy.
I think the question is really what resolution you would get. Consider the fictional situation where Company A makes a derived work of the novel Harry Potter without permission. They then sell a license to Company B to make derived works of their work. Company B writes a novel in the Harry Potter world, thinking they have a license to do so.
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.
> It exports many symbols for drivers (proprietary or otherwise) to use internally.
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.
> Drivers are necessarily derivative works of the kernel and have to be licensed under the GPL anyway.
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).
> I fail to see how those symbols being exported makes the relevant functionality public vs. internal to the kernel [1]
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.
While I'm sure that's an opinion held by some, it seems unreasonable when you have both EXPORT_SYMBOL and EXPORT_SYMBOL_GPL. If there is no distinction, then why does one exist? I think there's a good argument to be made regarding the intent of the application of the license across the API.
I should probably know this, but can anyone explain to me why other service providers like AWS don't have to release the source code of things like their brand of Xen running EC2 hypervisors?
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)?
You can provide services all day long and you don't have to provide the source code. It's when you ship a binary that you have to provide the source to the person buying it (or technically just downloading it if you give it away).
There are gpl-like libraries for which this is not true like the Affero GPL which is not as wifely used, but for the GPL itself this statement holds true.
> 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.
Well, it's never been tested, and I think that companies are not sure if it's safe to use it ever. I don't exactly know how much of the stack you have to provide the source for.
You can provide services all day long and you don't have to provide the source code. It's when you ship a binary that you have to provide the source to the person buying it.
For what it's worth, the FSF's opinion (and they wrote the GPL) is that the nvidia blob is no different and that the Linux developers should defend their copyleft. I really don't get Linus's position in that he refuses to defend his copyleft here while at the same time gives nvidia the finger.
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.
Both Nvidia and AMD bypass legal issues because they don't distribute mixed GPL and proprietary code. Basically their proprietary kernel modules is being linked with Linux kernel by end-user and this totally fine for GPL as long as result is not distributed.
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.
> Some features only exposed as GPL-only as their usage clearly prove that driver is derivative work of kernel.
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.
Thanks for clarification. Sadly I'm not an expert in copyright law and post of "jnky" about GPL_ONLY probably explain better what I attempted to say.
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.
The license-writer's published opinion on whether an activity is a copyright-protected activity that needs a license is of no special status (if the license-writer is also the copyright holder, it might have special status as itself being an implicit license in those circumstances where the opinion is that a license is not necessary.)
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.
User-does-the-link does not change whether the blob is derivative work or not.
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.
"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?
GPL bans adding restrictions on redistribution and other such rights. Automatic contract termination is the best you can do legally to try to get around GPL.
"Unfortunately, VMware has explicitly asked for the filings not to be published and, accordingly, Conservancy has not been able to review either document."
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.
They've been fighting for years to not make it right. I don't think there is any scenario in which one could say they have "made it right". VMware is a company that won't participate ethically with the Linux community, even when given ample opportunity to do so, and they should be shunned for that behavior.
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.
So if VMware loses this what would prevent e.g. Microsoft from claiming that the kernel driver in Process Hacker is a derivative work of the Windows kernel? Or worse, anything that patches a Windows DLL is a derivative work of that dll?
Try to incorporate any code from the Windows kernel into your proprietary product without permission, and count the seconds until lawyers from Redmond start calling.
I'm talking about that if a proprietary driver that links to the linux kernel is a derivative work then surely an open source driver linking to the Windows kernel is too.
I'm not a lawyer, but I totally sure that all Windows APIs that used by drivers and programs have clear statement within license that licensing is not "viral".
GPL is opposite. It's clearly state that your code depend on GPLed code become derivative work.
It seems that you are under the impression that the license can determine whether or not something that uses or interfaces with some program is a derivative work of that program.
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".
I didn't say it would infringe on anything just that it would be a derivative.
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.
It's depend on what you mean as "extending": official module/plugin or process memory patching. Some example would be helpful if you seriously want to discuss it.
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.
The lawyers in that company have a somewhat different interpretation of the GPL/LGPL than I've seen elsewhere in my career.