LWN: Comments on "Binary modules and derived works"

Binary modules and derived works

giraffedata — Sat, 13 Dec 2003 20:12:57 +0000

There's an underlying implication in this article that a program might be a derived work of the Linux kernel if it uses the Linux kernel in some way. There's absolutely nothing in the definition of derived work even to suggest that.

The binary module/derived work question is whether a package that contains both the Linux kernel and a binary loadable kernel module is a derived work of the Linux kernel. If it is, then the package cannot be distributed except according the terms of the Linux kernel license, which means in particular that you have to make the source code for that binary module available.

There's also a separate binary module/derived work question that wasn't mentioned here: Some people believe that in creating the binary module, you may be copying the Linux kernel because 1) you may be #including .h files from the Linux kernel, and 2) you may be copying example code from the Linux kernel, since it's the only way you could figure out how to use the LKM interface.

Law of Conservation of Argument

wa1hco — Fri, 12 Dec 2003 23:51:53 +0000

... There would be one minor disadvantage in that the kernel developers would have to find something else to argue about. One suspects that they are probably up to the task, however.

Ah! The law of conservation of arguement rediscovered again!

Binary modules and derived works

maolson — Thu, 11 Dec 2003 18:30:38 +0000

The problem with your example, as I see it, is that having enough exposure to the kernel source to create the exports strongly suggests that the binary module would be a derived work. To understand which new exports would be needed, the person creating them would need to be intimately familiar with GPL'd code and would be working from that knowledge when creating the hypothetical binary module.

Binary modules and derived works

JoeBuck — Thu, 11 Dec 2003 17:55:35 +0000

Ted T'so is, I think, incorrect about the FSF's opinion on GPL'ed libraries where alternative implementations exist (I assume you're interpreting what he said accurately).

We had this fight a few years ago, when GMP (the GNU arbitrary-precision math library) was under the GPL. Someone distributed patches to make RSA's RIPEM work with GMP, which was much faster than the math routines RIPEM contained. The FSF objected that this was a license violation. People objected that the FSF was claiming a user interface copyright. The FSF denied this, saying that the new code could work with nothing but GMP and was therefore a derivative work of GMP. There were some troubling aspects to the FSF's position, as they were in essence objecting to the distribution of a rather small patch, which in itself did not contain any of their code.

Someone whacked together something called FGMP, which provided the same interface as GMP for the subset of routines used by the patched RIPEM. RMS agreed that, under the changed circumstances, he could no longer claim that the patched RIPEM was a derivative work of GMP -- even though FGMP was far inferior to GMP in performance terms, meaning that no one would really use it.

In the end, the FSF changed the license of GMP to the LGPL to end that fight.

Now, in the readline case, I'm not sure what the facts are, but it would seem that the FSF would need to back off if there truly are complete BSD-licensed readline implementations. And if so, they probably will; generally, their goal has been to use the GPL to leverage the creation of more free software, and they've used less restrictive licensing for libraries that implement standards or where competing implementations exist.

Binary modules and derived works

elanthis — Thu, 11 Dec 2003 17:31:36 +0000

Unfortunately, with a changing API even in stable kernel series, Open Source or Free drivers are still just as much of a pain in the arse to end users.

End users don't upgrade kernels. They don't even know a kernel is. They don't *want* to know what a kernel is. They just want to slap in the new whizbang thingie they bought, load a driver, and have it work.

If it's assumed that all drivers will be distributed with a kernel, and that users of older versions of the kernel without the driver must upgrade, the system will not work for these users. But, even if the distributor of the hardware supplied drivers, it's still very, very likely the driver won't build.

Even if we toss ABI compatibility out the window, a *true* solid API is needed. One that will not change, *ever*, for 90% of driver needs. The API can of course be versioned, so that newer/better APIs can be added, but every kernel neesd to (perhaps only optionally) support the older APIs as well, to guarantee that modules released before the current kernel version can be compiled and installed.

Because these APIs would be intended for non-mainline modules, it's quite feasible to make them abstract and high-level, and thus perhaps slower, in order to make it very easy to keep them frozen solid, but let the underlying implementation change.

Binary modules and derived works

zmower — Thu, 11 Dec 2003 16:55:24 +0000

Linus also said about NVidia "I think the NVidia people can probably reasonably honestly say that the code they ported had _no_ Linux origin."

NVidia's "Linux Advantage" document (off their website) says "Allows NVIDIA to easily support numerous operating systems - 95% of all code base is shared between all operating systems".

Sounds to me (but IANAL) like the NVidia binary modules are not derived works and thus legal (if not moral from a Free Software perspective).

Binary modules and derived works

corbet — Thu, 11 Dec 2003 15:35:32 +0000

Free drivers with source are obviously the right solution; I didn't really see any point in even mentioning that. That's the only kind of driver I'm interested in running on my systems. But there will always be code that, for whatever reason, will not be licensed that way. I don't believe I've ever said "make life easy for closed-source modules" or any such. What I am saying is that ambiguity helps nobody. It would be best if people simply knew what is, or is not, allowed.

Binary modules and derived works

kreutzm — Thu, 11 Dec 2003 15:29:09 +0000

Looking from the user side, I don't see the advantage you imply at the end of your article. If I happen to have the wrong kernel version (e.g. 2.6/2.2) or even worse the wrong architecture (3D with nvidia on non-x86) or the module simply does not work as advertised - I am busted. I'd rather see the vendor supplying source and some precompiled modules as service than some semitechnical means to calm down the debate.

Binary modules and derived works

zone — Thu, 11 Dec 2003 15:15:13 +0000

Restricting the symbols that are available to binary modules would effect modules such as NVidia's that are distributed as binary modules meant to be used with standard distributor kernels. However, for Linux-based appliances, which symbols are available in the mainline kernel might be a non-issue. An appliance manufacturer could just apply EXPORT_SYMBOL() to every symbol in the kernel that they needed, release their changes under the GPL, and then create a binary module that uses their newly created interface. Some kernel developers might cry foul, but the GPL protects the right of the appliance manufacturer to create a derived work, and deciding which symbols to export to binary modules could definitely be seen as a valid technical change.