Wasabi white paper on kernel modules
As attorneys ourselves, we cannot find a coherent legal argument for excluding LKMs from [GPL] coverage. So why does the Free Software Foundation tolerate them? Because of its dual interests. On the one hand, it seeks to enforce the GPL. On the other hand, it seeks to promote the use of free software such as Linux." Or, perhaps, because the FSF has little copyright interest in the kernel.
Posted Feb 22, 2006 22:51 UTC (Wed)
by danieldk (subscriber, #27876)
[Link] (6 responses)
It is rather unfortunate to see a company that has gcc customization ("GNU Toolchain Development and Optimization") as one of their sources of income, try to cast doubt about the GPL through their "The Sarbanes-Oxley Act" and "Loadable Kernel Modules" articles.
Of course, there are implications of using GPL-licensed software that companies should know. But they seem to push their agenda with one sided arguments. I'd say 'keep your friends your friends'.
Posted Feb 24, 2006 10:20 UTC (Fri)
by man_ls (guest, #15091)
[Link] (5 responses)
Posted Feb 24, 2006 20:43 UTC (Fri)
by set (guest, #4788)
[Link] (4 responses)
Posted Feb 25, 2006 10:49 UTC (Sat)
by man_ls (guest, #15091)
[Link] (3 responses)
Posted Feb 25, 2006 14:55 UTC (Sat)
by sepreece (guest, #19270)
[Link]
Which is actually not surprising. A large-scale text entry project in the sixties found that, during one period, correcting an entry error added, on average, 1.3 errors.
scott
Posted Feb 22, 2006 23:03 UTC (Wed)
by lonely_bear (subscriber, #2726)
[Link] (1 responses)
Posted Feb 22, 2006 23:17 UTC (Wed)
by GreyWizard (guest, #1026)
[Link]
Posted Feb 23, 2006 0:08 UTC (Thu)
by johnchx (guest, #4262)
[Link] (2 responses)
In fairness, if you want to sell closed-source binary drivers, you are probably on firmer legal ground if the underlying OS is BSD-licensed than if it's GPL-ed. So their point is well taken, even if their motives are perhaps less than completely altruistic.
Posted Feb 23, 2006 1:11 UTC (Thu)
by tzafrir (subscriber, #11501)
[Link]
(Maybe the second case does not exist at all. That point has been discussed too many times here. But that white-paper is not a very relible source to answer that question)
Not to mention that closed source means extra maintinance overhead. Because you can't sell them anyway.
Posted Feb 23, 2006 8:20 UTC (Thu)
by gvy (guest, #11981)
[Link]
Wasabi seems to be one of the more original proprietary dinosaurs who is especially irritated for being so irrelevant because they are parasiting on open-source but dumb-licensed software which isn't able to defend itself (whoever might jump to defend BSDL would first look at its origin, it was quite competent for gov-funded research but it's just not the primary case these days).
Posted Feb 23, 2006 0:41 UTC (Thu)
by dwheeler (guest, #1216)
[Link]
Posted Feb 23, 2006 1:28 UTC (Thu)
by tzafrir (subscriber, #11501)
[Link] (20 responses)
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?
Posted Feb 23, 2006 3:11 UTC (Thu)
by bk (guest, #25617)
[Link] (14 responses)
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.
Posted Feb 23, 2006 11:28 UTC (Thu)
by ekj (guest, #1524)
[Link] (13 responses)
The relevant term is "derived work".
It absolutely complete bullshit to claim that a driver that is:
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.
Posted Feb 23, 2006 15:27 UTC (Thu)
by khim (subscriber, #9252)
[Link] (11 responses)
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.
Posted Feb 24, 2006 10:33 UTC (Fri)
by man_ls (guest, #15091)
[Link] (10 responses)
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.
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.
Posted Feb 25, 2006 11:07 UTC (Sat)
by man_ls (guest, #15091)
[Link] (8 responses)
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.
Posted Feb 25, 2006 19:47 UTC (Sat)
by giraffedata (guest, #1954)
[Link] (3 responses)
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.
Posted Feb 25, 2006 21:50 UTC (Sat)
by man_ls (guest, #15091)
[Link] (2 responses)
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.
Posted Feb 26, 2006 0:53 UTC (Sun)
by giraffedata (guest, #1954)
[Link] (1 responses)
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.
Posted Feb 26, 2006 12:02 UTC (Sun)
by man_ls (guest, #15091)
[Link]
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.
Posted Feb 25, 2006 20:05 UTC (Sat)
by giraffedata (guest, #1954)
[Link] (3 responses)
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.
Posted Feb 26, 2006 15:27 UTC (Sun)
by man_ls (guest, #15091)
[Link] (2 responses)
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.
Posted Feb 26, 2006 23:43 UTC (Sun)
by giraffedata (guest, #1954)
[Link] (1 responses)
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.
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.
Posted Feb 28, 2006 9:13 UTC (Tue)
by man_ls (guest, #15091)
[Link]
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.
Posted Feb 24, 2006 0:25 UTC (Fri)
by caitlinbestler (guest, #32532)
[Link]
In the true spirit of component oriented design this reuse
So the real question is whether GPL prevents a component
If it did, how would web services ever work?
Is it different because one is "remote" or "message
Either component oriented construction of systems
Posted Feb 23, 2006 8:37 UTC (Thu)
by jamesh (guest, #1159)
[Link] (4 responses)
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.
Posted Feb 23, 2006 9:17 UTC (Thu)
by tzafrir (subscriber, #11501)
[Link] (2 responses)
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)
Posted Feb 23, 2006 10:32 UTC (Thu)
by drag (guest, #31333)
[Link] (1 responses)
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:
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.
Posted Feb 23, 2006 20:11 UTC (Thu)
by mightyduck (guest, #23760)
[Link]
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.
Posted Feb 23, 2006 8:02 UTC (Thu)
by frazier (guest, #3060)
[Link]
-Brock
Posted Feb 23, 2006 11:07 UTC (Thu)
by coriordan (guest, #7544)
[Link] (5 responses)
GPLv3 has in its new definition of Complete Corresponding Source Code: "any shared libraries and dynamically linked sub-programs that the work is designed to require". I'm not sure about the legal basis (whether the copyright holder has the control to enforce that) but the text of the GPLv3 does its best, and can help a judge to interpret the intent of a licensor.
Posted Feb 23, 2006 16:57 UTC (Thu)
by AJWM (guest, #15888)
[Link] (3 responses)
But, to use the obvious example, Linux isn't designed to require binary modules, it's merely designed to allow them. Of course it will operate fine (on certain classes of hardware) without them. It may even operate fine on hardware that requires binary modules for additional functionality, it just won't have that functionality.
Not that the GPLv3 may ever apply to Linux, of course.
Of course if a hardware vendor tailored a version of Linux so that it required a module to run at all on vendor's hardware (Trussed Computing, for example) then they'd run afoul of that clause (if the kernel were v3 GPL'd).
Posted Feb 23, 2006 20:10 UTC (Thu)
by coriordan (guest, #7544)
[Link] (2 responses)
Posted Feb 24, 2006 4:19 UTC (Fri)
by roelofs (guest, #2599)
[Link]
I think you might be hard-pressed to convince a judge that the kernel is either a shared library or a sub-program of the module... But perhaps it's just poor wording in this draft of GPLv3.
Greg
Posted Feb 24, 2006 17:18 UTC (Fri)
by giraffedata (guest, #1954)
[Link]
In that direction, how is it relevant to the discussion? That means if I distribute a binary-only LKM, and if that LKM is covered by GPL (possibly by being a derivative work), then I must supply source code for Linux (in addition to source code for my LKM).
But the article is about source code availability for the LKM, not Linux.
Posted Feb 24, 2006 17:25 UTC (Fri)
by giraffedata (guest, #1954)
[Link]
Remember that these are just conditions on the license, not some right granted to the copyright owner by copyright law.
There are virtually no restrictions on conditions to a license, because of the fact that the copyright owner isn't required to give copying/deriving permission at all. The most onerous of conditions are no worse than no license at all.
I really don't think the judge cares. It's what the licensor licensed, not what he intended to license. It's not like a contract, where the judge looks for the common intent of all the parties. But maybe it helps with the "spirit" of the license, which is something the licensee might be expected to understand and abide by.
From their site: "OEMs and others who use LKMs are thus left in a precarious position of (1) trusting that the FSF and others maintain their current laissex-faire approach and (2) hoping that no other third parties choose to enforce the GPL at their expense."Wasabi white paper on kernel modules
I could not believe that the paper actually said "laissex-faire", but it's true. Folks, it's laissez faire, which means "let do". On this day and age, where ortographic verifications online take about two seconds, it's unforgivable to display your ignorance so blantantly.
Wasabi white paper on kernel modules
Perhaps you meant to spell 'orthographic'? ;)Wasabi white paper on kernel modules
(Blush) I meant to, sorry :)
How embarrasing
In over thirty years of newsgroups and other on-line postings, I think I have managed to make a spelling error every time I've corrected somebody else's spelling publicly.How embarrasing
FSF is not the copyright holder of the kernel, it cann't enforce GPL even it wants to. If FSF were the copyright holder like their GNU projects, I think binary only LKM may not exist.Wasabi white paper on kernel modules
I believe the Free Software Foundation does own the copyright for a small amount of Linux kernel code, either because they contributed it directly, someone assigned the copyright to them or a little of both. But of course you're right about the larger point, which is that the FSF does not have much control. I'm surprised that as attorneys themselves, the folks at Wasabi Systems are unaware of such basic things.Wasabi white paper on kernel modules
Also from the Wasbi website: "Wasabi Certified BSD, a certified, tested, and optimized version of the BSD operating system, offers the rich functionality of BSD Unix without Linux's troublesome GPL License." And elsewhere: "Wasabi Certified BSD is available on a per-seat, annual subscription basis."What Wasabi Sells
You normally don't want to sell closed-source drivers. The drivers are usually a part of a product. Sometimes they are derived of the kernel and thus have to be released due to its license (the GPL), and sometimes they aren't and thus their author is free to choose their license.What Wasabi Sells
It's just that to be competitive you need to first have at least some technical ground, not exactly "legal" (at least where things are supposed to work and not require a lawsuit to).Ground must be proper too (theirs' not to me)
This is a company that makes money selling a BSD-derived operating system. This is simply a competitor saying that the other guy is horrible. This is a clearly biased source; that should be noted in any reference to them. Discussing the issues they try to raise is still valid, of course, but it's important to understand where they are coming from.
Makes money selling BSD-based OS
Here's a nice quote:
Wasabi as true believers
When kernel modules are considered in the light of this definition, we believe that LKMs are derivative works under the statute. First, considering that a kernel module is essentially a portion of the kernel functionality that has been placed in a separate module, one could easily argue that it is "based upon one or more preexisting works" - it is essentially a piece of the preexisting work, or, in the case of device drivers, an extension of the preexisting work that allows it to work on particular hardware. Merely that an LKM may be independently written and conceived fails to remove it from derivative work status: even if it is "an original work of authorship," if it is essentially an "elaboration or other modification," it is still a derivative work of the original Program.
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?
Wasabi as true believers
No. Not "arguably yes", but instead definitely no.Wasabi as true believers
Wasabi as true believers
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".
Wasabi as true believers
Windows driver as derivative work
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.
Windows driver as derivative work
Windows driver as derivative work
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,
Windows driver as derivative work
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.
Windows driver as derivative work
Richard Stallman, as creator of the GPL, might clarify this point; or at least Linus Torvalds and the creators of the licensed code
Windows driver as derivative work
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.
Windows driver as derivative work
... 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.
Windows driver as derivative work
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.
I don't think there is a derivative work claim among SCO's claims. SCO says actual SCO code is being distributed with Linux.
Windows driver as 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.
Windows driver as derivative work
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).
In the true spirit of open source software I should be freeCompositing needs to be free, as in free speach
to create new systems from existing components, as long as I
have the right to use those components.
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.
built using GPL from being part of a component oriented
collaborative whole.
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?
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.
The GPL would apply if you wanted to distribute linux + ndiswrapper + driver.Wasabi as true believers
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.Wasabi as true believers
Well.. Wasabi as true believers
1. Generally much less buggy then closed source software.
I don't understand what OpenAFS has to do with your rant against closed Wasabi as true believers
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
The pages mentioned are a section of a larger work that has been covered in LWN before:Wasabi white paper on kernel modules
http://lwn.net/Articles/168497/
GPLv3 does its best to clarify this
that the work is designed to require (emphasis added)
GPLv3 does its best to clarify this
The binary module is designed to require Linux.other way around
The binary module is designed to require Linux.
other way around
The binary module is designed to require Linux.
other way around
GPLv3 does its best to clarify this
I'm not sure about the legal basis (whether the copyright holder has the control to enforce that)
...can help a judge to interpret the intent of a licensor