
VMware GPL Enforcement Suit in Germany Continues - chei0aiV
https://sfconservancy.org/news/2015/oct/28/vmware-update/
======
audidude
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.

~~~
malandrew
Are you at liberty to elaborate on how they interpret the GPL/LGPL differently
than what you've seen elsewhere in your career?

~~~
dkarapetyan
At liberty to elaborate always sounded like a weird phrase to me. Of course he
is. As a free citizen in a free society he can speak his mind freely.

~~~
jordigh
People can choose to give up that liberty by signing contracts. :-(

~~~
BinaryIdiot
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.

~~~
ChuckMcM
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)

~~~
BinaryIdiot
> 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.

~~~
emn13
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...)

------
jimrandomh
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.

~~~
belorn
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.

~~~
rdtsc
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!

~~~
teddyh
Your usage of the word “token” shows that it _can’t_ work.

------
ohthehugemanate
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.

~~~
teddyh
What in the world is “The German GPL”? As far as I know there is no such
thing.

~~~
cdavid
I don't know about German GPL, but you have licenses like CeCILL which could
be called "French GPL" I guess:
[https://en.wikipedia.org/wiki/CeCILL](https://en.wikipedia.org/wiki/CeCILL).

------
poizan42
> 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.

~~~
kuschku
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.

~~~
poizan42
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.

~~~
amscanne
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 seems damning.

~~~
poizan42
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.

~~~
mikekchar
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.

------
snockerton
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)?

~~~
joosters
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.

~~~
wolfgke

      > 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.
    

This is something the AGPL
([https://en.wikipedia.org/wiki/Affero_General_Public_License](https://en.wikipedia.org/wiki/Affero_General_Public_License))
tried to fix.

~~~
Tyr42
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.

------
tobias3
Took me a while to get that they are using the Linux kernel as a library, i.e.
[https://www.gnu.org/licenses/gpl-
faq.html#MereAggregation](https://www.gnu.org/licenses/gpl-
faq.html#MereAggregation) applies.

I thought they have a kernel module with a GPL wrapper, like the NVidia
graphics module which would be more contentious.

~~~
jordigh
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.

~~~
SXX
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.

~~~
jordigh
> Both Nvidia and AMD bypass legal issues because they don't distribute mixed
> GPL and proprietary code.

Not in the FSF's opinion. User-does-the-link does not change whether the blob
is derivative work or not.

~~~
SXX
Personally I find Linus opinion on this more reasonable. There is nice
collection of statements about GPL modules on LKML:
[http://yarchive.net/comp/linux/gpl_modules.html](http://yarchive.net/comp/linux/gpl_modules.html)

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.

~~~
tzs
> 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.

~~~
SXX
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.

------
throwaway_81042
Is there a list or registry of products which are GPL derivative [0] but only
release source code under NDA, e.g. Xen derivatives?

[0]
[https://twitter.com/rootkovska/status/518037037480697857](https://twitter.com/rootkovska/status/518037037480697857)

~~~
Natanael_L
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.

------
neekburm
"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.

------
duncan_bayne
I'll boycott VMWare over this!

Oh, wait, I haven't used their stuff in _years_. Heh.

------
ck2
ugh why vmware, I really like their products

hope they make this right

~~~
SwellJoe
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.

------
poizan42
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?

~~~
xorcist
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.

~~~
poizan42
Who said anything about that?

