LWN: Comments on "LinkSys and binary modules"

LinkSys and binary modules

mmarq — 2003-10-23T21:49:18+00:00

"Personally, I wouldn't have any problem with hardware driver source being released under a "you can only run this driver if you have this hardware" licence, but I suspect others would"

Correcty if i'm wrong, but couldnt the LANANA function as a support and guarantee mechanism that that really happens( no need for licences),... and considering a split driver model being it kernel/userland(like USB) or kernel/kernel, or not, the fact of any driver being "source" or "binary only" dosent really make any diference. I mean the coupling of specific hardware device with specific sofware driver, is always a given. If there is to much generalization inside Linux kernel, is because of design and lack of proper specs.

LinkSys and binary modules

mmarq — 2003-10-23T21:23:07+00:00

"I'd rather we inconvenience ourselves a bit now and continue trying to make the argument to hardware vendors that releasing programming specs is a good thing than risk leaving ourselves open to this kind of future trap."

This is not easy, but imagine that they, HV, not only dont release more specs "as usual", but with the closing of binary loadable modules, and the advent of M$ NGSCB/Paladium they will cease on any disclosure at all.

Wouldn't that represent the end of Linux ?

LinkSys and binary modules

mmarq — 2003-10-23T20:51:47+00:00

IMHO Linux need a split driver model

LinkSys is an example of continuous abuse, because they didn't released "that module driver" source, and legally the author(s) of specific "interfaces" involved could sue LinkSys... That could prove to be very bad for both sides.

The flexibility of the C language, as a procedural paradigma, dosent stop there, and there are proves from the GNOME project and others of the possibility of "craving" a real Object Oriented model with "full?" inheritance out of plain C.

So the "full objectivation" of the kernel is the next logic step of "modulation", with hierarchy and classes, like subsystems to kobjects, and char, block, video and sound devices class. But being out of a procedural language, this objectivation, IMO, also speak API allover the place. So the "glue" necessary to make kobjects talk with other kobjects could be completly negligenciable and wrapped inside the kobjects themselfes...

And that could be what is all about a "split driver model":- kobjects talking to other kobjects,... that already have a high natural tendency to be "logically independent functions within the kernel"... only remaining the formality of publishing the APIs... and "hardening" against possible abuses of other functions diferent from the published APIs(important:-saves sueing).

(no bypassing of copyright laws, no special favores to no one)

Being not a expert, and beliving i didn't express to much mistakes, but if so, then please let me know, because in a sense nothing really changes, and a clever configurantion mechanism is plently capable of configure the compiling sources out of diferent paths into a unic binary or into diferent binarys in diferent places(like kernel loadable modules);

Actual:
from /usr/src/Linux to /boot and or /lib/modules/3.0.1(example)

With a split driver model:
from /usr/src/Linux and /usr/src/Drivers to /boot and or /lib/drivers/3.0.1

In the late model, a proprietary binary only driver, that is copyed directly into /lib/drivers/3.0.1(example) would lose the ability to be compiled "in" the specific characteristics of the target machine, and relying on hardware detection mechanism and something like DKMS to be inserted...

In the late model also, all open source drivers could be compiled into a unic kernel image, like is happening today.

And what new world is to have a separated main Linux and Drivers, in terms of time and man/brainpower wasted in fixing bugs or broken things, and accelarating development, at least, well inside the 2 years time frame!!...

binary modules include GPL code from kernel headers

khim — 2003-10-23T13:14:49+00:00

Something to bear in mind when you write your own header files, anything you put there is being exported* (i.e. it's now outside your library), that is what header files are for.

*Export: to carry or send to some other place (Merriam-Webster)

Such a bold statement will be more believable if you'll supply link to any law where C headers are mentioned at all. Otherwise you can, of course, apply it to your programs - but only to your programs.

Yes, it is a problem for things like libstd++ and such - that's why all quite non-trivial inline fuctions in libstd++ are not LGPL-copyrighted - exactly to make then usable for non-GPL programs!

Wrapper which separates the non-GPLed code from the GPLed code ?

khim — 2003-10-23T13:04:55+00:00

They try to make module usable with >1 version of kernel. You can not write such a wrapper NOW. You need to add exception like it's done for userspace programs ! And only copyright holder can add such exception.

LinkSys and binary modules

Wol — 2003-10-23T11:55:49+00:00

Or go down the microkernel approach :-)

If the module runs as part of the kernel in kernel-mode, it's a derived work and must be open source.

If it runs as a user-land driver (like all drivers in a microkernel), then it is not a derived work, but it suffers all the penalties that usermode code (and microkernels in particular) suffer from.

This also has the nice side effect that binary-only code can no longer taint and/or crash the kernel.

Personally, I wouldn't have any problem with hardware driver source being released under a "you can only run this driver if you have this hardware" licence, but I suspect others would!

Cheers,
Wol

binary modules include GPL code from kernel headers

cross — 2003-10-17T11:53:27+00:00

This is a clearly ridiculous argument. Most software in C includes all sorts of headers with different licences and cannot be considered to be subject to the same license as all of them. The header defines the interface to the library, it should not be considered to be the library itself. Something to bear in mind when you write your own header files, anything you put there is being exported* (i.e. it's now outside your library), that is what header files are for.

*Export: to carry or send to some other place (Merriam-Webster)

binary modules include GPL code from kernel headers

dododge — 2003-10-17T06:14:33+00:00

If a binary module require GPL kernel headers files to build, then it is certainly GPL since kernel headers contain macro and inline functions,

Not necessarily. Earlier this year there was a big argument on LKML regarding header use. RMS stated the FSF position as:

Our view is that just using structure definitions, typedefs, enumeration constants, macros with simple bodies, etc., is NOT enough to make a derivative work. It would take a substantial amount of code (coming from inline functions or macros with substantial bodies) to do that.

Granted they do not define "simple" and "substantial", but they do at least believe a distinction exists and that some macros and/or functions would not automatically produce a derived work.

More info here: http://www.ussg.iu.edu/hypermail/linux/kernel/0301.1/0362.html

LinkSys and binary modules

andrel — 2003-10-16T18:22:29+00:00

As far as the legal system is concerned, the only people harmed by copyright infringement (that's what a GPL violation is) are the copyright holders. So the kernel authors could sue, but people who purchase the router can't.

Binary drivers aren't in any of our long-term interest -- cases like this which push hardware manufacturers to publish the bus-level interface instead of crappy drivers are a good thing. If I wanted to be forced to use closed source drivers I'd run SCO or Microsoft, not GNU/Linux.

The GPL is in fact quite clear.

leonb — 2003-10-16T15:03:46+00:00

I believe that the GPL is quite clear about the binary module issues. Simply recall that the GPL only regulates copying. When Nvidia distributes binary modules, this distribution involves no copying of GPLed code. What users do with these modules is their sole business.

  "The act of running the program is not restricted"

The so-called viral nature of the GPL applies only when you distribute a "whole" containing sections covered by the GPL, and sections that would not necessarily be GPLed if they were distributed independently.

  "But when you distribute the same sections as part of a whole             
  which is a work based on the Program, the distribution of             
  the whole must be on the terms of this License, whose             
  permissions for other licensees extend to the entire whole,             
  and thus to each and every part regardless of who wrote it."

The key word here is distribute.

Linksys is indeed shipping boxes containing both the linux kernel and binary modules. The binary modules might not be GPLed if they were distributed separately. But this is not the case here. Therefore the GPL applies.

Overall this is very annoying because it can be argued that Linksys was acting in good faith. It could make sense to settle by giving them a break for a few years only, and ask them, in return, to make a donation to some worthy open source cause. This is very unlikely to happen. Such a break must be approved by all the kernel contributors without exception.

When Linus decided not to request copyright assignment, he made the GPL a lot nastier, because nobody has the power to soften it when it makes sense.

- Leon

P.S. --- Incidentally this also clarifies the dynamic linking versus static linking issues. Such technical issues are irrelevant. What matters is the composition of the products you are shipping. The GPL only bites when you are shipping GPLed code copyrighted by someone else.

LinkSys and binary modules

zmower — 2003-10-16T09:57:38+00:00

So potentialy anyone who owns a LinkSys router could sue LinkSys for non-compliance with the GPL. I think (but IANAL) that the source for the binary module would have to be released if anyone did this. I'd defer to the FSF's judgement on this issue though as they have lawyers. And I don't have this hardware. I do have a Nvidia card (still getting my moneys worth out of a Geforce 256) but they seem to have thought about this issue much more than Linksys/Broadcom.

I don't think this case has been good for linux though. If you have proprietry hardware and want to keep your drivers closed then you really are at best entering an area of shady legality. I wonder if xBSD will gain on linux from this? Nightmare scenario: Desktop BSD with drivers to run all kit but still runs GPL software. Wake up screaming nightmare: released by M$. Now that would be embrace and extend.

LinkSys and binary modules - temporary closed modules?

lacostej — 2003-10-16T07:24:45+00:00

Isn't there a way to define temporary binary modules in the kernel, i.e. binary modules are accepted for a while, but must be opened after some time?
I couldn't find a working solution but there's perhaps an idea behing that?

LinkSys and binary modules

coriordan — 2003-10-16T05:29:29+00:00

> It is permissable to use GPL'd code with non-GPL'd additions

Yes. The GPL only covers distribution.

LinkSys and binary modules

pjm — 2003-10-16T05:04:35+00:00

If the module lacks a free license, the kernel complains, but loads the module anyway. One could argue that this behavior is an explicit acknowledgment that closed-source modules are permissible.

It is permissable to use GPL'd code with non-GPL'd additions: copyright law places no restriction on such private modifications. The above-mentioned code is useful for noting the presence such private modification.

What is not permitted is to redistribute the copyrighted code other than under the terms of the GNU GPL [or, more generally, under the terms of any other license one has been granted by the copyright owner]. The behaviour of checking for a free license does not constitute permission to distribute a derived product of the kernel without licensing it under the GNU GPL.

Correct

Ross — 2003-10-16T04:17:42+00:00

This is why most binary modules use a wrapper which separates the non-GPLed code from the GPLed code. See the NVIDIA driver for an example.

binary modules include GPL code from kernel headers

ballombe — 2003-10-15T18:19:52+00:00

Note the "user space programs" exception in Linux/COPYING.

Outside the above exception, kernel headers are under the GPL, not the
LGPL as are GLIBC headers.

So whereas non GPL programs can use GLIBC headers, non GPL modules cannot
use kernel headers.

binary modules include GPL code from kernel headers

pizza — 2003-10-15T16:26:15+00:00

So under this intrepretaion, glibc has to be GPL, as it relies on kernel headers to build. Since glibc is therefore GPL, any applications which run on linux must also be considered GPL.

Food for thought. You can't have it both ways.

binary modules include GPL code from kernel headers

ballombe — 2003-10-15T12:20:27+00:00

If a binary module require GPL kernel headers files to build, then it
is certainly GPL since kernel headers contain macro and inline functions,
which are copyrighted code not just interface definitions as the macro code
and inline functions are copied by the compiler in the binary module.

This is clear GPL violation and should be treated as such.

What exacly are FSF doing?

coriordan — 2003-10-15T04:21:39+00:00

Interesting, thanks.

What exacly are FSF doing?

set — 2003-10-15T02:48:31+00:00

Here is the post to linux-kernel characterising their efforts:

http://www.spinics.net/lists/kernel/msg214541.html

LinkSys and binary modules

vmole — 2003-10-14T23:14:45+00:00

Just to clarify:

Of course, the Debian folks might well decide that non-free firmware violates the DFSG, but that's a separate matter.

Note that the DFSG argument is strictly based on us shipping free software: binary code loaded into a DSP just doesn't qualify. We don't claim that the the fact that it's mixed up with a kernel driver inherently violates the GPL. It's purely a Debian thing.

What exacly are FSF doing?

coriordan — 2003-10-14T21:21:34+00:00

What I don't get is, since FSF don't hold copyright on the driver interface code, what basis would they have for such threats?

From the Forbes article: the Free Software Foundation ... has been making threats to Cisco Systems and Broadcom over a networking router that runs the Linux operating system.

One possibility is that they haven't been making threats at all. Maybe they're just working with them to clear this issue up. When you don't have the grounds to prosecute, and you tell a company that they are breaching contract, you are not threatening, you're informing. Useful info too.

Practical vs. Possible

Ross — 2003-10-14T20:55:44+00:00

I don't think copyright's concept of derivative works have anything to do
with encyption. The only part of copyright that does is the DMCA and we
aren't talking about that here, at least I hope not :)

Practical vs. Possible

ncm — 2003-10-14T20:38:52+00:00

If it's in a header file, it's probably published. Even if it's not in header file, the source is published. No matter what the FSF says, a judge is likely to decide that if you physically can plug into it without "circumventing" anybody's encryption, then you're allowed to. Of course, the more of that you do, the more fragile your module becomes.

None of these fine points apply to Linksys, of course. They can't just ship the module, they have to ship the kernel, too, or they don't have a router to sell. That puts them squarely under my second alternative, above, shipping what is unambiguously a derived work.

Practical vs. Possible

rknop — 2003-10-14T20:25:11+00:00

If the module is distributed independently of a kernel, and contains no code lifted from the kernel, and uses only published interfaces into the kernel, then (again) it doesn't matter what Linus or any other copyright holder says. Then, it's probably not a derived work.

The issue then becomes more continuous... just how much ought to be published interface? As the article notes, it's not too far to imagine making publishable interfaces such that pretty seriously core parts of the kernel could have proprietary plug-ins. Right now, we mostly have that just for device drivers.

-Rob

LinkSys and binary modules

JoeBuck — 2003-10-14T20:24:23+00:00

There are two cases: burning the Linux kernel and other programs into a ROM, or having a driver load firmware into a completely separate processor, such as the DSP chip in a modem or onto an external graphics processor.

In the latter case, from the point of view of the kernel, firmware is data, or, to use the language from the GPL, "can be reasonably considered independent and separate works", since the identical firmware is loaded by a Linux or a Windows kernel. Even RMS would not argue that the GPL requires firmware to be GPLed in such a case.

Of course, the Debian folks might well decide that non-free firmware violates the DFSG, but that's a separate matter.

Now, in the former case, if the ROM can't be altered, then one could argue that we can't even call the user programs separate works any more and the vendor would need to provide source for the whole thing.

Practical vs. Possible

ncm — 2003-10-14T20:17:34+00:00

The question of whether binary-only modules are allowed comes down to whether, and under what circumstances, it's possible to restrict them.

If such a module contains code copied from GPLed modules, then it is simply and unambiguously forbidden. The person whose code was copied has standing to sue, no matter what Linus or anybody else says. The trick is discovering whose code was copied, and persuading the injured party to pursue the matter, or delegate pursuit to somebody willing.

If the module is distributed along with a kernel, and it only works with that kernel, it's unambiguously forbidden. The combination is a derived work, and the GPL states clearly the rules for derived works. Anybody who has code in the kernel has standing to sue, no matter what Linus or anybody else says.

If the module is distributed independently of a kernel, and contains no code lifted from the kernel, and uses only published interfaces into the kernel, then (again) it doesn't matter what Linus or any other copyright holder says. Then, it's probably not a derived work. A judge might be persuaded either way. What Linus announced, and clarified, is just that fact: as best he understands, copyright law doesn't allow him to enforce the GPL in that case. What he said doesn't change the license, it just explains his understanding of what the license (and the copyright law it relies on) covers and doesn't cover.

LinkSys and binary modules

proski — 2003-10-14T19:56:59+00:00

If a Linksys router is considered "a work based on the Program" (i.e. Linux), then the firmware falls under GPL requirements as well. Maybe the hardware blueprints should be GPLed as well. However, the final "regardless of who wrote it" assumes that the work is assumed to be a piece of software.

Hardware manufacturers want to use free software using the most liberal interpretation, but when they release the source, they would prefer the more restrictive version to prevent competitors from reusing their work.

Somebody should compile a list of unclear places in GPL. If there are too many of them, maybe GPL should be just forked into the "soft" and the "hard" versions. It's important that everybody plays by the same rules, whatever they are. If it happens, I expect Linux to use the "soft" version, while such projecvts as Qt and MySQL will most likely stick with the "hard" variant.

LinkSys and binary modules

james — 2003-10-14T19:29:48+00:00

The only way to get a definitive answer on the location of the GPL boundary will be to go in front of a judge. Even then, the answer is unlikely to be useful beyond the specific case considered there.

And then, of course, that decision won't be binding outside that legal system.

Under the Berne Convention, most countries' copyright rules these days are similar, but they're not identical. It would be quite possible for the same code to be declared legal in an American court under US law, but illegal in a German court under German law.

One could take the viewpoint that this uncertainty is a good thing, especially with the FSF around. Companies generally don't like legal uncertainty and the possibility of lawsuits, at least if they can acheive the same ends by obviously legal means. Uncertainty about where the boundary lies is an incentive to keep well on the right side of it.

Of course, there are companies who just hope they won't get sued. And we're back to the FSF's "enforcer" brigade.

James.

LinkSys and binary modules

rknop — 2003-10-14T19:18:09+00:00

The problem with clarifying whether or not binary loadable modules should be legal is that it will tear the free software community apart.

There are some who feel very strongly that they clearly should not be. This will range everywhere from the FSF argument that all proprietary software is bad, and therefore anything we do to support it is bad, from the more moderate argument that the GPL is incompatable with binary modules and therefore they shouldn't be allowed.

There are some who feel just as strongly that binary modules *should* be allowed. You're being just as exclusionary, the argument goes, by forbidding binary modules as proprietary vendors are by not supporting Linux. It's a practical thing; we want the hardware supported, vendors are supporting Linux by supplying those drivers, and we're ingrateful zealots to reject them.

The problem is, few on either side of the argument will want to yield to the other side. And, if we as a community settle on one side or the other, definitively, there will be a lot of ugly second-guessing and objection and fighting inside the community that doubtless Forbes and others will gleefully write about to show how anti-business and self-destructive the open source community is.

Many people like me feel ambiguously about the matter-- I really do not like being trapped into binary-only modules, because you're at the mercy of the vendor, and I want to have a fully free operating system. On the other hand, I'm a little leery of the hard-line answer that you must be fully free or not be supported at all, as then we do lock ourselves out. (E.g., I could no longer use the Lucent modem on my laptop; I'm not happy about the binary driver, but at least I can use it.)

In the end, I'd probably fall on the side of wanting to disallow binary kernel modules. Yeah, it could be inconvenient. On the other side, though, there's a very real danger that some sort of tightly-integrated binary plugin because a de-facto standard that everybody "running Linux" assumes that you mean "using this binary plugin", and it becomes nigh impossible to run a fully free OS any more and maintain any kind of compatability with hardware or the rest of the world. I'd rather we inconvenience ourselves a bit now and continue trying to make the argument to hardware vendors that releasing programming specs is a good thing than risk leaving ourselves open to this kind of future trap.

(Indeed, already we risk being in this trap for video cards. If ATI stops playing nice with releasing programming specs, we'll be stuck with having to choose one binary module or the other if we want to have graphics on our machines. Already, too many people say "just buy nVidia" for Linux, because you can download their drivers. I find myself arguing against that, and trying to make the *practical* argument, when people around where I work are buying hardware for Linux systems.)

-Rob