In-kernel driver or FUSE based?

Posted Aug 26, 2009 16:38 UTC (Wed) by mjg59 (subscriber, #23239)
In reply to: In-kernel driver or FUSE based? by lkundrak
Parent article: Tuxera signs up with Microsoft

Given that turning a module into linked-in code is basicaly a mechanical transformation, it's not clear that it's relevant from a copyright point of view. We really have no idea where the derived work boundry is here, and I suspect what your lawyer tells you will depend to a certain extent on what you want to hear. It'd be fascinating to actually gain some case law on this topic, but the risks of losing are sufficiently high for both sides that it's not obviously in anyone's interest to let things get that far - hence the commonly tolerated practice of one side shipping binary modules and the other side claiming that they're all illegal, but nothing happening anyway.

to post comments

In-kernel driver or FUSE based?

Posted Aug 26, 2009 17:31 UTC (Wed) by JoeBuck (guest, #2330) [Link] (1 responses)

Actually, a good lawyer is going to be extremely cautious on matters like this: if you ask "If I take action X, am I taking a legal risk?", the lawyer's going to be off and running, generating lots of billable hours giving you all the possible scenarios where something can go wrong. He/she isn't just going to tell you what you want to hear.

FUSE is in user space, so I would think that a FUSE filesystem can have a GPL-incompatible license. But IANAL.

In-kernel driver or FUSE based?

Posted Aug 26, 2009 20:13 UTC (Wed) by hingo (guest, #14792) [Link]

Fortunately, the CEO himself is a good lawyer, so he can run around (which he does, running) as much as he wants for free :-)

In-kernel driver or FUSE based?

Posted Aug 26, 2009 17:33 UTC (Wed) by jzbiciak (guest, #5246) [Link] (7 responses)

I thought that the kernel's licence was "GPL+exception", where the "exception" was that loadable modules are OK as long as they report their license correctly and only referred to symbols that were exported for that license. There are some symbols that only GPL code can use (because they're "too internal" to the kernel), and some that are exported for all modules. This in effect creates a kernel interface with a somewhat clearer delineation of what's on the GPL side and what's not.

Did I miss something?

The fact that something can be linked into the kernel doesn't imply anything. The NVidia proprietary driver could be linked with the kernel through the mechanical means you mention. The argument is that if it must be linked with kernel internal interfaces (ie. the ones exported as GPL-only symbols), it is at that point that the code is seen as clearly derived from the kernel and subject to the GPL.

In-kernel driver or FUSE based?

Posted Aug 26, 2009 17:45 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

Linus denies there is any such exception

http://lkml.org/lkml/2007/6/15/262

In-kernel driver or FUSE based?

Posted Aug 26, 2009 17:46 UTC (Wed) by corbet (editor, #1) [Link] (5 responses)

You missed something: there is no special GPL exemption for loadable modules. They must comply with GPLv2, period. As has been remarked, the fact that they are a module does not itself say much about compliance; it's really a matter of whether the module is a derived product of the kernel or not. Lots of modules pretty clearly are. A Windows driver shoehorned in with ndiswrapper clearly is not.

In between, though, is a very fuzzy line. GPL-only exports are an attempt to create a little clarity there; the reasoning is that, if your module needs one of those symbols, it really has to be a derived product. But the only sure way that line could be made less fuzzy would be through the creation of legal precedents, and, as mjg59 pointed out, that's a sufficiently scary minefield that few want to tread there.

In-kernel driver or FUSE based?

Posted Aug 26, 2009 18:16 UTC (Wed) by JoeBuck (guest, #2330) [Link]

In this case, we're talking about a FUSE filesystem. It's userspace code, it is not a kernel module.

In-kernel driver or FUSE based?

Posted Aug 26, 2009 21:30 UTC (Wed) by rickmoen (subscriber, #6943) [Link] (3 responses)

corbet wrote:

More exactly, anyone distributing modules whose licensing doesn't comply with the terms of GPLv2, and which module is a derivative work of someone else's code in the kernel, commits the tort of copyright violation against the latter person.

Fuzzy line? Not as much as you might think. The key point of contention, which few in these discussions ever seem willing to actually study, is the legal term of art "derivative work" -- and it's really not all that difficult to understand. In USA law, the ruling case (concerning non-literal copying of copyrighted works) is CAI v. Altai, Inc., (2nd Circuit, 1992), which provided a mechanism (abstraction, filtration, comparison) for judges to isolate "expressive elements" of the work alleged to have been derived from, as opposed to "functional elements". Purely functional elements within a copyrighted work (elements dictated by efficiency, elements dictated by external factors, standard programming techniques and program features), along with elements taken from the public domain, inherently don't qualify for copyright coverage in the first place. (Why inherently? Because of 17 U.S.C. 102(b), clarifying that if you want a monopoly properly covered by patent, i.e., "any idea, procedure, process, system, method of operation, concept, principle, or discovery", then you can't get it using copyright.)

Don't take my word for that, Jon. Read Justice John M. Walker's opinion. It's pretty short, and very clear.

Among other things, on account of those considerations, the oft-heard contention that works needing the kernel's GPL-only exported symbols are inherently derivative works of (something in) the kernel seems doubtful on its face: Those seem like the very picture of a "functional element", in which category Walker (quoting Nimmer) lists elements dictated by "compatibility requirements of other programs with which a program is designed to operate in conjunction".

The notion that derivative work theory has anything to do with the nature of linking, or of use or non-use of this-or-that programming interface, has always been hooey. It's about time that these misconceptions were dropped.

Rick Moen
rick@linuxmafia.com

In-kernel driver or FUSE based?

Posted Aug 27, 2009 4:58 UTC (Thu) by BrucePerens (guest, #2510) [Link] (2 responses)

Walker's opinion actually creates some confusion. He shows how code that exists only to interface to an API, within an application program, is not protectable. He doesn't distinguish that the expression in the creation of an API that serves to applications is protectable and that unprotectable code that is derived from the API is indeed a derivative work of it. He doesn't point out that his version of the test (filtering the work derived from) might show the API as a protectable work when the lower court's version of the text (filtering the derivative work) would not. He also puts in some text regarding "code that exists to fulfill expectations of the application" that further confuses the issue.

In-kernel driver or FUSE based?

Posted Aug 28, 2009 22:21 UTC (Fri) by Wol (subscriber, #4433) [Link] (1 responses)

I would also *feel* that if an API is declared "GPL only" by its author, then a Judge would be inclined, at least, to bow to the *clearly* *expressed* wishes of the author.

It's one thing giving a deriver the benefit of the doubt where the law is unclear and the original author's wishes are unclear. It's a whole different kettle of fish where the original author has made their wishes abundantly clear - if the law isn't clear then benefit of the doubt should go to the author. I know it's not really a legal principle, but I do feel that if someone goes asking for trouble they have no grounds for complaint when they get it!

Cheers,
Wol

In-kernel driver or FUSE based?

Posted Aug 28, 2009 22:28 UTC (Fri) by BrucePerens (guest, #2510) [Link]

I would also *feel* that if an API is declared "GPL only" by its author, then a Judge would be inclined, at least, to bow to the *clearly* *expressed* wishes of the author.

That is definitely the ethical thing to do where Free Software is involved. The developer gets no "consideration" (that means money or some other valuable) except for compliance with his license, and if you can't comply you shouldn't use his code.

But I just re-read Walker's opinion in CAI v. Altai, and he doesn't mention the author's intentions at all in his long and detailed description of how to determine if a work is infringing. He goes entirely by copyright law.

So, it doesn't seem to me the judge is going to agree with us.