Wasabi white paper on kernel modules [LWN.net]

Wasabi as true believers

Posted Feb 23, 2006 3:11 UTC (Thu) by bk (guest, #25617) [Link]

A nice piece of legal work. Let's test this with a well-known example: suppose you load a windows driver through ndiswrappers, does the GPL apply to that driver?

Arguably yes, provided that someone was foolish enough to distribute the driver + ndiswrapper with the kernel. I'd be willing to bet, though, that this would violate the copyright or EULA of the driver author and would guarantee the distributor would receive a C&D letter (or possibly a lawsuit) very quickly.

In other words, this scenario has little chance of ever happening so your analogy is not particularly relevant.

Wasabi as true believers

Posted Feb 23, 2006 11:28 UTC (Thu) by ekj (guest, #1524) [Link]

No. Not "arguably yes", but instead definitely no.

The relevant term is "derived work".

It absolutely complete bullshit to claim that a driver that is:

Written for another OS than Linux.
Without using Linux.
Possibly by someone who's never seen any part of the Linux-sourcecode.
Without using any part of the Linux-kernel-API

Is a derivative of Linux.

Now, the *combination* of a binary kernel-module *and* ndiswrapper migth be a derived work. But that in no way whatsoever implies that the driver is a derived work, or becomes a derived work when distributed this way.

Wasabi as true believers

Posted Feb 23, 2006 15:27 UTC (Thu) by khim (subscriber, #9252) [Link]

Now, the *combination* of a binary kernel-module *and* ndiswrapper migth be a derived work.

And that is the only thing bk said: "Arguably yes, provided that someone was foolish enough to distribute the driver + ndiswrapper with the kernel". Please read message you are answering to...

It was never in question if windows driver distributed separately from linux kernel is derived work or not (of course not). It's still unclear if you can distribute binary linux driver without linux kernel (like nVidia does). But some argue that since ndiswrapper is GPLed and windows driver is not derived work of Linux kernel it's Ok to ship combination of linux kernel, NDIS wrapper and windows driver. No, it's not Ok to ship this combination - and this is main issue Wasabi Systems is raising... The only way to ship GPLed program and non-GPLed program is where "mere aggregation" is in effect - and it's kinda hard to claim that NDIS driver is not related to kernel in your package when the whole thing is unusable without any component...

Once more: sometimes it's Ok to distribute just binary driver (like IBM did for AFS long ago and nVidia is doing today). Of course it's Ok to distribute ndis driver without ndiswrapper. But it's not Ok to distribute NDIS driver and ndiswraper in the same package - never mind adding linux kernel to the mix.

Wasabi as true believers

Posted Feb 24, 2006 10:33 UTC (Fri) by man_ls (subscriber, #15091) [Link]

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 (subscriber, #1954) [Link]

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 (subscriber, #15091) [Link]

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 (subscriber, #1954) [Link]

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 (subscriber, #15091) [Link]

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 (subscriber, #1954) [Link]

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 (subscriber, #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 (subscriber, #1954) [Link]

... 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 (subscriber, #15091) [Link]

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 (subscriber, #1954) [Link]

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 (subscriber, #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.

Compositing needs to be free, as in free speach

Posted Feb 24, 2006 0:25 UTC (Fri) by caitlinbestler (guest, #32532) [Link]

In the true spirit of open source software I should be free
to create new systems from existing components, as long as I
have the right to use those components.

In the true spirit of component oriented design this reuse
of existing logic is not a derivative of either component
but truly a new work itself. Trying to claim otherwise is
sticking to a ancient single-build throway-code mentality.

So the real question is whether GPL prevents a component
built using GPL from being part of a component oriented
collaborative whole.

If it did, how would web services ever work?

Is it different because one is "remote" or "message
based" and the other is "local" or "call based"?
What about RPC or RPC/XML? What if RPC/XML is used
and the other end of the connection is in fact local?
What if RPC is implemented by a hypervisor between
partitions?

Either component oriented construction of systems
from mixed components complies with GPL or it doesn't.
If it does then the method of connecting components
that are defined and built independently is irrelevant
to the discussion. A LKML that is clearly defined as
an add-on to linux probably does count as an extension,
but I don't see how that applies to interfacing Linux
to an existing linux independent driver.

Wasabi as true believers

Posted Feb 23, 2006 8:37 UTC (Thu) by jamesh (guest, #1159) [Link]

The GPL would apply if you wanted to distribute linux + ndiswrapper + driver.

Of course, if you weren't the copyright holder on the Windows driver you probably wouldn't be able to satisify the source code requirements, so would not be able to distribute the combination.

The above example would not place an obligation on the driver manufacturer to release source code though: it is the person distributing the linux+driver combination who has violated the GPL.

Wasabi as true believers

Posted Feb 23, 2006 9:17 UTC (Thu) by tzafrir (subscriber, #11501) [Link]

One simple point first: if the code was not derived from GPLed work, the GPL does not apply to it. This has nothing to do with the formulation of the GPL. This is because the GPL is a copyrights license and nothing more.

The big question is what does "derived work" mean. Now please explain to me how does a driver that was written for a totally separate OS and uses no Linux-specific interfaces becomes derived work of the Linux kernel. Just by being in the kernel space?

And if I load it as a pure data blob into the kernel space?

(For the sake of argument, let's take a hypithetical public domain windows NDIS driver)

Wasabi as true believers

Posted Feb 23, 2006 10:32 UTC (Thu) by drag (subscriber, #31333) [Link]

Well..

Linus understands this and there is already a implimentation that exists that follows closely to your scenero...

OpenAFS is a implimentation of the Andrew File System. This is a very old network protocol (along the lines of NFS), however it is superior in most respects to CIFS or NFS. It is ideal for distributing files over slow links and is safe enough to use over the internet with no VPNs and such.

OpenAFS project started when IBM released the source code from it's own AFS implimentation.

This source code exists partially as a kernel module for the Linux kernel. This can be interpreted as not being Linux-derived software since the majority of it's code would still of existed if Linux never happenned and has existed before Linux.

It's under a 'Free Software', but not GPL-compatable license.

Keep in mind though as a end user you can link whatever the hell you want with the kernel.

You could legally link code from Microsoft with the Linux kernel if you wanted. You could load closed source drivers all day long and have it be 100% compliant with the GPL. You can take code from the kernel and use it in your own software and never ever distribute the software in any manner.

The GPL 'must distribute the source code' clauses only kicks in when you distribute software to other people, and you only have to give the source code to your end users and you can charge any amount of money for the binaries if you feel like it. You can tell everybody else, "just f-off, you are not going to get anything from me unless you pay for it" including the kernel developers... just as long as you provide the source code at minimal cost to your end users. (they could in turn give the code to other people if they felt like it though, just as same as you did with GPL'd code yourself)

However as far as closed source drivers go... They SUCK.

Not only are they not GPL compliant and do not follow the spirit of Free software but there are very very good technical reasons why they should be avoided.

Some reasons why open source drivers are better:
1. Generally much less buggy then closed source software.

2. Bugs that do turn up get fixed much quicker.

3. Much easier to adapt to new circumstances (for instance if you want to try out Novel's XGL or Redhat's AIGLX opengl accelerated X Windows your S.O.L. if your using the ATI propriatory drivers. It simply isn't going to happen.)

4. Open source drivers are cheaper to maintain (for hardware vendors) and improve and adapt to new hardware. Closed source drivers make life hard for whoever has to maintain them.

5. Once a driver makes it into the 'Vanilla Kernel' it becomes aviable for all platforms that Linux runs on and will be maintained for the forseeable future. (pretty much as long as that hardware exists probably)

If your using a Nvidia video card on a PowerPC machine your never going to get 3d acceleration, while 9250 and earlier ATI cards have full 3d acceleration on PowerPC since the drivers are open source.

Closed source stuff generally only works on x86. You'll never get a NDIS wrapper-based driver to work on a Ibook, as another example.

This is the difference between a 'binary blob' and 'firmware'.

On my Ibook I am using a firmware image extracted from a Windows XP driver to run my Broadcom 'Apple Extreme' 802.11g wifi card. Firmware is OS independent and platform independent. I would never be able to use a Atheros 'binary blob' in a PowerPC or Sparc machine.

6. Once a driver make it into the kernel it becomes aviable immediately to all people and all distributions that use that Linux kernel version or newer ones.

This is the ONLY way to EVER get things to 'just work' with Linux. Not only it is illegal to distribute binary only drivers along with a Linux kernel in a distribution, but open source officially kernel-included drivers will work irregardless of what kernel version your using (now and into the future).

You won't have to worry about a vanilla kernel driver going away if you upgrade from 2.6.4 kernel to 2.6.16 kernel, for instance. However there is absolutely no garrentee that a binary-only driver will ever work. Sometimes you would end up with a binary-only driver that would cause you to have to live with kernel vunerabilities and bugs because it won't work with a newer kernel.

And if you get thinking about a 'Stable ABI' with the Linux kernel keep in mind this:

That Linux has the best hardware support of any OS anywere. Not only does the Linux kernel support more hardware out of the box then Windows XP, but it does support that hardware on every computer platform that Linux has been ported to. (which is a lot). It is also consistantly more stable and has higher performance then most any other OS out there. (although many other OSes can be faster and more stable under specific circumstances.. I am talking generally).

The major Linux for 'the unix desktop' rival at this time is probably OpenSolaris.(for the sake of argument lets set aside FreeBSD for now) Solaris has a VERY stable in-kernel ABI and you can use binary drivers from many years ago with little to no problem.

Solaris has very poor hardware support and only supports that hardware on 1 or another platform. Some hardware that is supported in Sparc is not going to be supported in x86-64 and visa versa.

In order for you to get 3d acceleration on Solaris and to get support for many popular sound cards (and some other hardware) you have to PURCHASE drivers from 3rd parties. For many popular hardware your either stuck going to pay for drivers from companies like Xi Graphics (Accelerated-X), or 4Front Technologies (OpenSound drivers otherwise known as OSS).

This is also probably what would happen if Linux developers decided to go for 'stable abi' to support some binary drivers.

Wasabi as true believers

Posted Feb 23, 2006 20:11 UTC (Thu) by mightyduck (guest, #23760) [Link]

I don't understand what OpenAFS has to do with your rant against closed
source drivers? Last time I checked it was open source, just not GPL. Do
you want to paint it with the same brush as the Nvidia driver for
instance? I don't think that's a fair comparison.

Wasabi as true believers

Posted Feb 23, 2006 13:18 UTC (Thu) by gdt (subscriber, #6284) [Link]

The GPL would apply if you wanted to distribute linux + ndiswrapper + driver.

The license for the the binary driver would apply as well as the GPL license. Many binary licenses do not allow redistribution.