In-kernel driver or FUSE based?

Posted Aug 26, 2009 17:46 UTC (Wed) by corbet (editor, #1)
In reply to: In-kernel driver or FUSE based? by jzbiciak
Parent article: Tuxera signs up with Microsoft

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 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.