Wasabi as true believers

Posted Feb 24, 2006 10:33 UTC (Fri) by man_ls (guest, #15091)
In reply to: Wasabi as true believers by khim
Parent article: Wasabi white paper on kernel modules

I am no lawyer, but this argument looks bogus to me. A windows driver is in no way a derivative of the kernel; ndiswrapper of course is a derivative of the kernel, but it is licensed under the GPL. And if the windows driver has a license that allows redistribution in binary form, then I would argue that it is "mere aggregation".

The "work" being the kernel, ndiswrapper is a "derivative work" and it is licensed under the GPL. Joint distribution is OK.

The "work" being ndiswrapper, a Windows driver is not a derivative work; it was created independently and with a different target in mind.

The "work" being the Windows API, ndiswrapper is no derivative but a clean room implementation.

So if the driver and the wrapper are independent works (with an alien API in between), then distribution of both is "mere aggregation". One could be GPL and the other closed.

Windows driver as derivative work

Posted Feb 24, 2006 17:05 UTC (Fri) by giraffedata (guest, #1954) [Link] (9 responses)

You guys are arguing two different points. The original question was "is the driver covered by GPL," and the answer was "arguably yes" in a certain circumstance. Later, there is an assertion, claiming to be a contradiction, that the driver is not a derivative work.

Both are true. Distributed with a Linux kernel, the Windows code may be covered by GPL, and in no case is it a derivative work of the Linux kernel.

The theory under which code distributed "with" a Linux kernel might be covered by GPL is entirely separate from the derivative work concept, but also not germane to the article/paper, which is about LKMs that are distributed separately.

Windows driver as derivative work

Posted Feb 25, 2006 11:07 UTC (Sat) by man_ls (guest, #15091) [Link] (8 responses)

Maybe I'm missing something? If the Windows driver is not a derivative work, how can the GPL apply to it? As tzafrir argues below, a copyright license can only apply to things under copyright, like aggregation works and derivative works. If the Windows driver and the wrapper (which is just a compatibility layer) are distributed together, it is just an aggregation work so they can have different licenses. Even more so if distributed separately.

I have not read the paper, but a driver which is a derivative work must be distributed under the GPL. It does not matter how it is distributed, jointly or separately. If I write a new Harry Potter novel (a derivative work of the old ones) I will not be able to distribute it, jointly or separately.

tzafrir's root comment was just a counterexample of the theory that linking anything into the kernel makes it a derivative work, and which according to the quote seems to be Wasabi's central point. It is obviously false, and ndiswrapper makes it obvious.

Windows driver as derivative work

Posted Feb 25, 2006 19:47 UTC (Sat) by giraffedata (guest, #1954) [Link] (3 responses)

If the Windows driver is not a derivative work, how can the GPL apply to it? As tzafrir argues below, a copyright license can only apply to things under copyright,

The thing under copyright is Linux. The license to copy Linux specifies conditions, and those conditions can apply to anything at all -- they need not be related to copyright.

The license to copy Linux (GPL) says you can copy it as long as you make source code available for the entire program of which your copy is part. It doesn't matter whether copyright law gives the owner of the Linux copyright any particular rights over the other code in that entire program.

Having to supply the source code (and other stuff) is what we mean by the GPL "applying" to the code.

Now we have to get rather hypothetical, because all I'm trying to do is show that you can make a plausible argument without involving derivative works.

If the combination of Linux and the Windows driver contemplated in the original comment is tight enough that the whole mess qualifies as a single "program" containing Linux, the GPL applies to the Windows code through the mechanism I just described.

Another hypothesis is that what I said about having to supply source code for the "entire program" is really in GPL. As is discussed in the paper, GPL is maddeningly contradictory about that. Section 0 says quite clearly that the conditions apply to a program containing the licensed work, but the same section says that is merely a restatement of the definition of derivative work, which it definitely is not. If a court were to resolve the contradiction by tossing out the part about a work "containing" the licensed work and go with the derivative work thing alone, then I'm totally wrong.

Where you need the derivative work concept to extend GPL to the Windows code is where you distribute the Windows code separately instead of in a single lump with Linux.

Windows driver as derivative work

Posted Feb 25, 2006 21:50 UTC (Sat) by man_ls (guest, #15091) [Link] (2 responses)

If a court were to resolve the contradiction by tossing out the part about a work "containing" the licensed work and go with the derivative work thing alone, then I'm totally wrong.

Ok, I was missing that part. So it is a bit hypothetical, and it might be risky to take it in any sense. I would argue that Richard Stallman, as creator of the GPL, might clarify this point; or at least Linus Torvalds and the creators of the licensed code, the kernel. I don't think any of them would argue in favour of the interpretation "a program containing the licensed work", and I thought it was a settled issue. But maybe not.

Is there any provision in GPLv3 about this point? I think I remember something in Eben Moglen's talk, but don't have the time right now to look it up.

Windows driver as derivative work

Posted Feb 26, 2006 0:53 UTC (Sun) by giraffedata (guest, #1954) [Link] (1 responses)

Richard Stallman, as creator of the GPL, might clarify this point; or at least Linus Torvalds and the creators of the licensed code

The paper says it's clear that the FSF believes LKMs are derivative works and therefore controlled by the copyright owners of the Linux kernel. It also says it is clear that Linus gives permission for binary LKMs. And that this is of academic interest only, because a person's legal rights are determined by the license that Linus et al gave, not the license they meant to give. (And the viral effect of GPL exacerbates the problem, because it means we're forced to license our Linux-based code under the same ambiguous license).

I'd like to know why Stallman and FSF copyright lawyers think Section 0 makes sense, in the light of others' explanations that what is says is the legal definition of derivative work isn't. Nonetheless, their interpretation of the license they wrote isn't of legal significance.

I just checked, and GPL v3 has the same wording.

Windows driver as derivative work

Posted Feb 26, 2006 12:02 UTC (Sun) by man_ls (guest, #15091) [Link]

And that this is of academic interest only, because a person's legal rights are determined by the license that Linus et al gave, not the license they meant to give.

I know you are a lawyer while I'm not, but I respectfully disagree. In this interview with Eben Moglen, he says that linux kernel modules in binary-only form are allowed because there is a certain refinement to the rules in the GPL, evidenced by the existence of GPL-only exported symbols. He cleverly calls it "an exception", indicating that it is not endorsed by the FSF. And then he says it would be helpful if Torvalds et al. would clarify this exception and formalize it, so everyone knew what the rules are.

To me this is further evidence that the intentions of the licensor are important when a clarification is required; but it follows from common sense too. If the language of a license is clear, then there is no taking it back. But when some expression is ambiguous, the only way to clarify it is to know what each party thought was being granted or forbidden. Since the GPL is a one-way issue, then the licensor's opinion becomes very important.

Windows driver as derivative work

Posted Feb 25, 2006 20:05 UTC (Sat) by giraffedata (guest, #1954) [Link] (3 responses)

... The theory that linking anything into the kernel makes it a derivative work, and which according to the quote seems to be Wasabi's central point.

That's not the central point I saw. First of all, if the linking itself were what made it a derivative work, then the distributor of the LKM wouldn't have much cause for concern, because he's not linking anything. The paper says what makes the LKM a derivative work is that it functions as an integral part of Linux, was created specifically to do that, and has little other use. It mentions the use of Linux header files as evidence that the code is engineered specifically to Linux. So I'd say the authors have provided for the fact that the NDIS-linked driver is not a derivative work of Linux, while all the regular Linux LKMs might still be.

FYI, the paper also discusses the related issue of the "shim" LKM, which is a lot like NDIS: One splits a device driver into two modules. One is binary-only, the other GPL. The GPL one dynamically links to the base kernel; the binary-only one links to the GPL one. Because the binary-only one doesn't link to any Linux code, it is supposedly safe from GPL requirements. But the paper says that doesn't work because linking isn't the issue -- it's the fact that the binary-only portion is still designed specifically to be part of Linux.

Windows driver as derivative work

Posted Feb 26, 2006 15:27 UTC (Sun) by man_ls (guest, #15091) [Link] (2 responses)

The paper says what makes the LKM a derivative work is that it functions as an integral part of Linux, was created specifically to do that, and has little other use. It mentions the use of Linux header files as evidence that the code is engineered specifically to Linux.

The use of (what is essentially) Unix System V headers in Linux has been considered to be a requisite for functional equivalence or interoperability; nothing that denotes a derivative work under copyright. That is why SCO's theories about copyright violations in Linux have been laughed at and discarded.

Meanwhile, Samba code was made to work with Windows, integrates directly into a Windows network and as a Windows server and was created specifically for this purpose; it has little other use. But Samba definitely cannot be considered to be a derivative work of Windows, since it's a clean room implementation and again only replicates those functional parts designed to ineroperate (something which is out of bounds for copyright law, at least in the EU).

Or, to offer another counterexample, drivers for Windows satisfy the above conditions but are not derivative. They function as an integral part of Windows, are created specifically to do that, and often have little other use; of course they will use Windows headers. But why should they be considered a derivative work of Windows? They are the product of their respective authors, and Microsoft has explicitly allowed their existence. Sure, Windows is not under the GPL, but we are talking about "derivative works" under copyright law in general.

Finally, a driver written to work both under Windows and Linux (probably using different makefiles and with a lot of macros) would not satisfy the above conditions, but would probably be considered a derivative work of Linux. If there is a "shim layer" licensed under the GPL, and a binary portion written both for Windows and Linux, it is again out of the proposed criteria, but could easily be considered a derivative work.

If I were nVidia or ATI, I would rather trust Linus Torvalds than Wasabi. In fact, that's exactly what they do. There are better reasons for distributing your drivers under the GPL than Wasabi's FUD.

Windows driver as derivative work

Posted Feb 26, 2006 23:43 UTC (Sun) by giraffedata (guest, #1954) [Link] (1 responses)

I don't think there is a derivative work claim among SCO's claims. SCO says actual SCO code is being distributed with Linux.

I do know that header files figure significantly into the SCO case, in an entirely different way. SCO has pointed out lines of code in Linux header files that look just like lines in SCO-owned code. The defense to that is that those lines look that way because that is the only reasonable way to express the interface in question. That means it could be original code that just coincidentlly is the same as in Unix. Plus, in copyright law, you get a pass even if you directly copied material if the material is the only way to say something. BTW, the headers SCO identified are external interfaces (system calls).

In contrast, in the LKM-as-derivative-work arena, we already know the work is original, and the header files aren't for any standard interface. They're for intra-kernel interfaces that are particular to Linux. So the fact that you use them in compiling your code is useful evidence that you wrote it particularly to be part of a Linux kernel. And that helps it to be a derivative work.

drivers for Windows satisfy the above conditions but are not derivative.

Says who? By Wasabi's analysis, they are.

Microsoft has explicitly allowed their existence.

Well, there you go. It looks like Microsoft believes they're derivative works; they wouldn't need explicit permission from Microsoft if they weren't.

a driver written to work both under Windows and Linux

I believe by Wasabi's analysis, this would be a derivative work both of Windows and Linux (you'd need permission from both to produce it). Because I know that the two are so different that it would have to be specifically engineered to each -- you can't make a generic device driver that just happens to work with those two systems.

Concerning Samba: The clean room process avoids a copying claim, but does little for a derivative work claim, because a derivative work is acknowledged to be original. In a derivative work analysis, I see a CIFS client program as far more separate from a CIFS server program than a Linux device driver LKM is from the Linux base kernel. But it's all a matter of degree. A judge has to draw a line somewhere.

Windows driver as derivative work

Posted Feb 28, 2006 9:13 UTC (Tue) by man_ls (guest, #15091) [Link]

It looks like Microsoft believes they're derivative works; they wouldn't need explicit permission from Microsoft if they weren't.

I did not mean it in that sense; Microsoft has encouraged the existence of drivers, and never claimed they are derivative works, to my best (and shallow) knowledge. It would be quite absurd also; they might as well claim that programs written for Windows are derivative works. There is no difference actually: Microsoft publishes an API, a developer uses it to write some software (be it a device driver or a regular program).

So, you say that the only criterion for considering something a derivative work is the one established by a judge. Well, we did not need Wasabi's study to tell us that. But I would think that the developer's opinion should matter something; if Torvalds and the gang think that some symbols are GPL only (implying a high degree of interaction), while the rest can be used in binary drivers; and the FSF as authors of the license think that it is a reasonable "exception" to the linking clause, I would say that development of binary drivers should be safe enough. Ignoring both opinions seems like an important omission to me.