LWN: Comments on "VMware update to GPL-enforcement suit"

GPL-insulator

redden0t8 — Mon, 23 Mar 2015 13:38:15 +0000

So basically the defense they're setting themselves up for is:

+------------------+    +-----------------+
|proprietary kernel|    |GPL Linux drivers|
+------------------+    +-----------------+
                  |       |
           derivative   derivative
                  |       |
                  V       V
                 +--------+
                 |GPL shim|
                 +--------+

In other words, their kernel and the GPL'ed drivers are completely independent of each other. The only thing that's a derivative of the Linux kernel is the shim. The fact they also have native drivers for their kernel supports this. Their kernel works 100% fine without any GPL code (as long as the hardware you're running it on has native drivers available). You can argue what you want about the moral aspects of this case, but I can see why VMWare believes that they're in the *legal* right here.

VMware update to GPL-enforcement suit

ploxiln — Wed, 18 Mar 2015 04:51:56 +0000

I think it's an appropriate joke.

If you're a company and you get sued, you get legal counsel. If you get legal counsel, they say "we believe this case is without merit". There is no conditional here, it doesn't matter what the company or lawyers really think, this is what they have to say. It's their job, it's how the system works. So it's meaningless.

GPL-insulator

paulj — Tue, 17 Mar 2015 13:29:03 +0000

On 2, note that if you have a licence that says "You are allowed to do this", then you're safe. You don't need to answer the potentially very tricky question of "Is my work derived from that other work it relies on?", because you have permission from its author either way. Your lawyer will be happy if you have a clear licence to let you use that other work and consider that the end of the matter.

Is a small programme that relies heavily on supporting infrastructure (libraries, a VM to interpret it, etc.) derived from the work implementing that supporting infrastructure? Quite possibly! Why couldn't it be? Even compilers can have licence clarifications to clearly state compiler outputed programmes are not affected by the compiler's licence (e.g. GCC has this, though a GCC compiled programme can still be subject to the libgcc runtime library's licence).

Now, in the case of your Java HelloWorld, you could perhaps argue:

1. Your JVM came with a licence that explicitly lets you run programmes in it without further licensing implications for your programme.

2. Your programme depends only on functional, standardised interfaces (e.g. as de facto proven by there being multiple, wholly independent implementations), and so can not derive from any specific work.

Case 1 is what your lawyer would much rather prefer to have you rely on. Being able to say "The copyright author has published declarations that clearly state they are fine with this" puts you in a very good place.

Case 2 would worry your lawyer. It means the copyright holder might disagree and try sue you. That's annoying even if you prevail in the end. Worse, this can be a murky area of law (even murkier while Oracle v Google is ongoing).

The situation with your BIOS is probably similar. Use is probably covered by a licence, so the derivation question would then be moot (that said, I can't remember ever seeing an end-user usage licence for any BIOS I've had in a machine). Otherwise you're off in the murkier area of functional interfaces and derivation.

For the Linux case, assuming Oracle v Google is resolved in a way that we go back to the "strong interfaces are not copyrightable" standard from before, then maybe yes a Linux driver re-implementation could "underive" any binary drivers, or maybe not. I honestly don't know. (Note that in the VMWare case they are alleged to have re-used GPL-only Linux code in both the re-implementation, as well as having re-used GPL-only Linux drivers, IMU from the FAQ - which would make it a different case from your hypothetical).

I'm not trying to interpret the law here - IANAL. I'm trying to point out that, IME, lawyers will strongly advise you to avoid, if at all possible, getting yourself into a position where your only defence is to argue that a murky area of law falls in your favour. The lawyers will advise you that ideally you should either ensure you have a clear licence allowing your use of the other work, or else clearly not use that other work. My experience of this with lawyers predates Oracle v Google too.

Relying on the vagaries of copyright law to have your work ruled not deriving is risky and something lawyers I've had experience of would try dissuade you from.

GPL-insulator

NAR — Tue, 17 Mar 2015 12:46:20 +0000

I'm not asking you to believe me. I'm stating that there's a difference between my gut feeling and what legal advice says.
The licenses generally tell what can (or cannot) be done with the derived work. Generally they do not state what is a derived work, that's for the copyright law (although some licenses can clarify this). For example the Java license does not contain the "derived" word.

I'm not talking about a generic program - I'm talking about the very specific HelloWorld program. Do you really think that's a derived work?

For the BIOS-analogy - suppose someone implements from scratch a kernel that provides the same driver interface as Linux. Would this make the nVidia kernel module "underived", because there are multiple implementations of the driver interface?

GPL-insulator

mathstuf — Tue, 17 Mar 2015 12:06:44 +0000

Generally, a corporate lawyer's job is to reduce risk. An accountant's job is to reduce waste and/or increase ROI. These behaviors seem to be direct consequences of that difference.

GPL-insulator

zlynx — Tue, 17 Mar 2015 05:19:15 +0000

And yet, accountants and tax attorneys don't think that way. In their world if the laws were written with a loophole then they are perfectly free to use that loophole until it is closed by rewriting the actual text of the law, not some judge's opinion.

GPL-insulator

raven667 — Mon, 16 Mar 2015 19:09:10 +0000

It's funny, there is the perfect example of this thinking in another thread where someone mentioned Aereo trying to get around copyright by using thousands of individual antennas to record TV and how that didn't work out for them because intent was more important than following the rules as written.

https://lwn.net/Articles/636759/

GPL-insulator

paulj — Mon, 16 Mar 2015 15:52:41 +0000

Oh, on the interface thing, figuring out if an interface is sufficiently fixed and independent from any specific implementation to make it a copyright barrier probably requires a judge and jury. Indeed, the whole issue of functional interfaces and copyright may well be evolving as we speak, at least in US copyright law (which may influence other copyright systems over time).

From another angle: As programmers / techies, we so desperately want logical, well-defined answers to these questions. It may be hard to accept that in reality this isn't obtainable, unless you're very careful not to specifically depend on any one elses' code.

GPL-insulator

paulj — Mon, 16 Mar 2015 15:48:31 +0000

I'll note two things:

1. You're asking me to believe your gut feeling over legal advice

2. A Java VM generally comes with a licence, which allows you to run programmes in it.

I don't see why a programme running in a VM and greatly dependent on it couldn't derive from it.

On the BIOS question, does the bootloader depend on a /specific/ BIOS (I used "specifically" in my last paragraph deliberately)? Or is the BIOS interface that it uses sufficiently well-defined that there are multiple implementations of it, and the bootloader could run on any one of them? If "yes" to the latter, it becomes hard to say that this bootloader derives from any specific BIOS.

You can apply similar reasoning to the Java VM / Helloworld case.

GPL-insulator

NAR — Mon, 16 Mar 2015 15:09:35 +0000

Let's take a look at this piece of code:


public class HelloWorld {

 public static void main(String[] args) {

  System.out.println("Hello world!");

 }

}

Is it independent of the Java VM and API? Clearly not, uses the System class and uses the special main method to execute. Is it derivative work of the Java VM and API? I seriously doubt since I haven't even looked at the Java VM and API sources. My gut feeling conflicts with the legal advice you got.

Of course, the HelloWorld.class and the JRI bundled together are derivative works, because they do contain the actual Java VM and system libraries.

The Linux kernel (intentionally or not) provides an interface to 3rd party kernel modules. I don't think merely using that interface makes the user code derivative work. Following this line a bootloader using BIOS would be also a derivative work of BIOS.

GPL-insulator

paulj — Mon, 16 Mar 2015 14:52:12 +0000

I used independent because my understanding is that when one work clearly is independent of another (its function does not depend on that other work), then it is highly unlikely that the work could derive from that other work.

If one work has a functional dependency on another, in whatever way, then that indicates there may be derivation issues that you'd need a lawyer to look at, and potentially a judge and jury to resolve authoritatively.

That's my understanding from US corporate legal advice given to engineering, at a previous job. Legal gave functional dependence as a good rule of thumb that engineering could easily apply to determine if/when there was an issue that needed to go to the legal department.

The interesting bit was that the legal people there didn't really care about the technical details. For them, the issue seemed to be whether code A could work, with the same features, with or without code B in the *abstract*. It didn't matter to them if A used function calls, IPC or network protocols to use B - if it resulted in A specifically depending on B for functionality, then legal considered that an issue.

Legal simply short-circuited all the complicated, technical discussions the programmer/engineering types like to get into on free software licensing, and went with a much more abstract and fundamental test. A test that seems much easier to resolve too. "Does that code still provide the same functionality without that other bit of code, specifically?". It changed my whole perspective on free software licensing arguments.

GPL-insulator

NAR — Mon, 16 Mar 2015 13:56:56 +0000

no longer obvious that the closed core is independent of Linux.

The question is not whether the driver is independent of Linux, the question is whether the driver is derivative work of Linux. My gut feeling is that a derivative work is a modified version of the original - if it merely uses the original, then it's not derivative. The combined work may be derivative, but nVidia makes pains not to distribute that.

GPL-insulator

paulj — Mon, 16 Mar 2015 12:45:14 +0000

The core was definitely windows specific before they wrote the Linux shim.

However, that was a /long/ time ago. Their GPUs since then have changed a lot. Their drivers have changed a lot. They have done a lot of development since that original obviously-not-linux-influenced core with Linux officially supported.

For NVidia to have retained a obviously-not-linux-specific core they would have had to maintain a firewall between their Linux and core driver teams, to ensure their Linux driver writers could never influence the core driver team. Otherwise, this core may well have had adaptations made to it to benefit Linux support. At which point, it is no longer obvious that the closed core is independent of Linux.

In short, given the many years NVidia have officially been producing Linux drivers, it is not possible now to say NVidias' driver consists of a Linux-independent core and an open shim into Linux. At least, it would now require a review of their internal driver development history and processes to make that determination.

All that is certain now is that NVidia have a Linux driver that consists of a large, closed blob, and a smaller open shim to wedge the blob into a Linux kernel.

GPL-insulator

paulj — Mon, 16 Mar 2015 12:36:41 +0000

“Argued like a programmer. Unfortunately for the overly-literally-minded, the law takes intent into account,”

+1 on this. One of the most surprising things to me, when I came into contact with computer industry lawyers, was how little they cared about the finer technicalities that programmers might think are important.

GPL-insulator

etienne — Mon, 16 Mar 2015 11:13:24 +0000

> Which part of Nvidia's code would that be, exactly?

The whole part. The fact that a company ask its costumers/users to do "complex" things because said company cannot do it itself, while still claiming total ownership of said source code may look strange to a judge.
The judge may ask what is the intend.
If you are the owner/costumer of such system, are you allowed to back-up (i.e. create a copy) of your system - maybe even in the cloud? Is that clearly explained to their costumers before buying?
Note that I would not say NVidia is doing anything wrong if really the closed part has never been debugged, optimised or modified on/for Linux...

GPL-insulator

zlynx — Mon, 16 Mar 2015 02:40:11 +0000

> Unfortunately for the overly-literally-minded, the law takes intent into account, and, as we saw with Objective C, way back when, distributing a module that can only work with someone else's code clearly shows intent to produce a derivative work on the distributee's system. "

Which part of Nvidia's code would that be, exactly? The fully GPL licensed (yes, dual license GPL/Nvidia) glue code? Or the code which is the same core code that they use on Windows?

A too liberal reading of derivative code would make it impossible to read EXT2/3/4 filesystems on Windows or BSD, make it impossible to run ZFS or NTFS FUSE modules, and disallow using NDIS wrappers. WINE and Samba would probably become copyright infringers as well.

After all, code interop in the same address space, or in the same computer system, or on the same network is all a matter of arbitrary boundaries.

GPL-insulator

xtifr — Sun, 15 Mar 2015 20:10:09 +0000

nVidia does not distribute other peoples' GPL'd code therefore there is no copyright violation.

Argued like a programmer. Unfortunately for the overly-literally-minded, the law takes intent into account, and, as we saw with Objective C, way back when, distributing a module that can only work with someone else's code clearly shows intent to produce a derivative work on the distributee's system. "I make the end user glue the pieces together" is not a valid excuse. At best, you might be able to argue that it's contributory infringement, which isn't exactly a whole lot better.

NVidia, as I understand it, is using the documented public API of the kernel, intended by the kernel devs for exactly that sort of use. That, not some legal trickery about not distributing the kernel themselves, is why they can do what they do.

If what you suggest were true (or completely true--there's obviously some truth to it), then gcc wouldn't have an Objective C module. NeXT didn't really want to release the source code to it, and they weren't actually distributing any part of gcc. Nevertheless, their (NeXT's) lawyers were persuaded that the FSF had a solid infringement case.

GPL-insulator

Otus — Sat, 14 Mar 2015 12:58:55 +0000

It was about Nvidia in general, I guess, but in reponse to a question about Optimus, i.e. GPUs.

GPL-insulator

neonsignal — Sat, 14 Mar 2015 03:54:46 +0000

> the problem the GPL is trying to solve is to require equitable sharing of modifications to code

No, the problem the GPL is trying to solve is the restriction of user freedoms. "the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users". Modifications to the code have to be made available to the users of that modified code. There is no specific requirement to provide the modifications back to the original author, and that would be an unnecessary restriction.

The users of the GPL code include users of any derivative works. The only area which is not crystal clear here is where the boundary of 'derivative' work lies in relation to software; but that is a copyright question, not a GPL one. (The framers of the GPL clearly believe that linking constitutes derivativation of a work, which is why the LGPL is provided as an alternative for rare cases where allowing linkage to proprietary code may actually benefit users in the larger scheme of things.)

If linking to a GPL file is found to not be a derivative work, then this has significant ramifications for all software libraries, not just ones under a GPL licence.

GPL-insulator

mathstuf — Sat, 14 Mar 2015 01:24:07 +0000

IIRC, that was about their ARM stuff, not the video cards.

VMware update to GPL-enforcement suit

UnwashedMeme — Fri, 13 Mar 2015 11:42:49 +0000

> In particular, VMware devotes significant effort supporting customer usage of Linux and F/OSS based software stacks and workloads.

Making workloads that their customers desire run properly is their business. This isn't a defense of breaking copyright; it's just trying to sell to a broader market segment.

GPL-insulator

jezuch — Fri, 13 Mar 2015 09:57:12 +0000

> Nvidia's defense, which Linus agrees with

...by giving it a middle finger? :)

Just a confusion over acronym, perhaps?

rdnetto — Fri, 13 Mar 2015 09:49:03 +0000

That's quite unlikely - it's pretty common to refer it as just the GPL, and I can easily see someone unfamiliar with it writing it out like that. (Not to mention there's a complete copy of the license included in the kernel...)

GPL-insulator

vapier — Thu, 12 Mar 2015 21:54:49 +0000

the license in the Linux source itself states this at the very top

https://git.kernel.org/cgit/linux/kernel/git/torvalds/lin...

GPL-insulator

ttonino — Thu, 12 Mar 2015 20:35:23 +0000

The GPL FAQ - and probably the court - will look whether the components are separate or not. Whether parts are replacable. A BIOS can load any OS and the OS does not come with the BIOS of the licenses are incompatibe.

Courts are quite good at making this distinction.

GPL-insulator

raven667 — Thu, 12 Mar 2015 18:10:07 +0000

> Whether the scenario you describe creates a derivative work is an unanswered legal question.

IIUC it would be more accurate to say that whether something is a derivative work is a judgement call so it's something that is answered in a case-by-case basis and there isn't a lot of precedent in software cases to point to like instances and make a strongly informed opinion as to which way it's likely to be judged.

GPL-insulator

Wol — Thu, 12 Mar 2015 15:10:37 +0000

I think you'll find the nVidia setup IS EXPLICITLY allowed.

There's also no question that it IS a derived work.

nVidia does not distribute other peoples' GPL'd code therefore there is no copyright violation.

The END USER creates the derived work, and the GPL explicitly states that what the end user does is of no concern to the licence.

Of course, the result cannot be distributed, that *would* be a GPL violation, but the whole point of the nVidia dance is to avoid said distribution.

The vmWare thing seems to be different ...

Cheers,
Wol

VMware update to GPL-enforcement suit

jhoblitt — Thu, 12 Mar 2015 12:18:54 +0000

Do you mean IBM's GPFS? The Linux kernel module component, which essentially allows the GPFS user space daemon to interface with the vfs layer, is GPL'd. IBM only distributes it as source at the end-user is responsible for compiling it.

It would be a hard sell that use space component of GPFS is a derived work of the kernel. GPFS is currently supported no Linux, AIX, and Windows. It is also merely a re-branding of MMFS which (all GPFS porcelain commands are prefixed `mm...`), which I believe predates the existence of the Linux kernel.

VMware update to GPL-enforcement suit

dunlapg — Thu, 12 Mar 2015 11:56:01 +0000

It took decades for the first GPL cases to actual go to court; the reason was that *any* lawyer brought in would almost always tell their client to just settle, because in most cases the law is really clear and comes down heavily on the side of the copyright owner (which in this case is the person who wrote the GPL'd code).

VMWare isn't a sketchy fly-by-night operation, or a front for some other company like SCO. They're a massive publicly traded company with billions in revenue; they have a lot to lose from being wrong. They have lawyers, and you can bet they're good ones. If they haven't budged, it means that their lawyers think they're on sound legal ground.

From what I understand, the basic problem is that there is not a clear definition -- either in the law or in case law -- about what it takes to be a "derived work". The GPL FAQ makes a simple rule, and says if it's in the same address space, then it's a derived work; if it's in a different address space, it's not. But lots of people (Linus Torvalds and Lawrence Lessig for example) think that's too simplistic.

I think both sides are honestly convinced that they are correct and have been behaving above board. The fact is that the law isn't yet clear; which is why it really needs to go to a court.

GPL-insulator

nye — Thu, 12 Mar 2015 11:28:54 +0000

>ISTR that, allegedly, the .ko was, in fact, largely the Windows driver. Which can't be literally true

I'm sure it is literally true. Given that there's the GPLd translation layer, I'd expect almost every line of code in the binary .ko to be cross platform, and hence written to target Windows first by default.

(The people writing the code for the supercomputer probably don't care much about the OS running on that pathetic co-processor we laughably call a 'CPU', except to provide a very thin interface between them.)

GPL-insulator

SLi — Thu, 12 Mar 2015 11:04:40 +0000

Any citations to Linus agreeing with this? I think Linus has said consistently that the license is what it is, and there are no exceptions. AFAICT he has refused to take a clear stance either way, essentially reserving the right to bring enforcement action if he so feels.

GPL-insulator

SLi — Thu, 12 Mar 2015 11:02:19 +0000

No, it's not "clearly allowed by the GPL". In fact, nowhere does the GPL (version 2) speak about linking.

It speaks about derivative works (which is everything it can restrict anyway). Whether the scenario you describe creates a derivative work is an unanswered legal question. I think the only thing that is safe to say is that it most certainly will not be as simple as "whether X links to Y" or who does the linking. Instead the territory will likely be charted on a case-by-case basis and it most likely will not end up being a bright line.

GPL-insulator

eru — Thu, 12 Mar 2015 05:26:25 +0000

In some way isn't that the case for any proprietary closed source software running on a GPL base OS?

In the case of Linux, Linus has explicitly stated that the GPL does not affect user-mode code that just uses the kernel API.

GPL-insulator

dfsmith — Wed, 11 Mar 2015 23:16:52 +0000

Define "linking". That's the problem. GPL 2 uses the term "incorporating".

GPL-insulator

HenrikH — Wed, 11 Mar 2015 22:35:04 +0000

The BIOS loads the kernel, it does not link with it. There is no way that the vmkernel can load the GPL vmklinux without also linking with it else it cannot use any of the functions from the GPL driver/application.

GPL-insulator

dfsmith — Wed, 11 Mar 2015 21:45:49 +0000

IANAL but consider, for example, your BIOS. This is closed source proprietary software, which can load a GPL kernel; and in turn the kernel can call the BIOS.

BIOS <-> GPL Linux kernel <-> GPL driver/application

Compare this with what VMWare's letter said:

vmkernel <-> GPL vmklinux <-> GPL driver/application

As a software guy, I'm kind of hard-pressed to see the difference. I don't know how a jury would see it.

GPL-insulator

Wol — Wed, 11 Mar 2015 20:28:20 +0000

And it's also clearly allowed by the GPL.

I think the thing there, is if the software house is clearly going through the pain of avoiding the GPL, that's okay, not least because it's obvious to the user that that is what is happening.

The VmWare thing certainly looks dodgy to me - linking vmWare proprietary code to a vmWare GPL shim (clearly legal) to other peoples' GPL code - very definitely a lawyerly attempt to get round the clear intent of the GPL.

Cheers,
Wol

GPL-insulator

jwarnica — Wed, 11 Mar 2015 19:39:23 +0000

The "push compilation of stub to the end user" step is a one-time effort (more or less).

*Having* a stub means that the .ko can interface with *many* kernels with only a very small external interface that needs to change. ISTR that, allegedly, the .ko was, in fact, largely the Windows driver. Which can't be literally true, but there isn't any doubt that there is a bunch of stuff done in software that you think is hardware. Or at least header files for data structures.

GPL-insulator

raven667 — Wed, 11 Mar 2015 17:30:14 +0000

> If this is the case, and the court accepts it, it becomes pretty easy to include any GPL'ed code into your closed proprietary software. Just write your own GPL'ed intermediate layers.

In some way isn't that the case for any proprietary closed source software running on a GPL base OS? ISTM that the problem the GPL is trying to solve is to require equitable sharing of modifications to code, if I wrote something and you modify and ship a better version, you have to share those changes back with me, but if I write something and you just use it unmodified as a component in another work in what way am I being harmed? I may like it if your whole software stack was Free Software but I might also like a pony, that doesn't mean I must get what I want.

GPL-insulator

SEJeff — Wed, 11 Mar 2015 16:21:32 +0000

Nvidia's defense, which Linus agrees with, was that the Nvidia driver was ported from windows and made to work on Linux. It didn't start on linux so it is not a derivative work