|
|
Subscribe / Log in / New account

LinkSys and binary modules

LinkSys and binary modules

Posted Oct 14, 2003 19:18 UTC (Tue) by rknop (guest, #66)
Parent article: LinkSys and binary modules

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


to post comments

Practical vs. Possible

Posted Oct 14, 2003 20:17 UTC (Tue) by ncm (guest, #165) [Link] (3 responses)

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.

Practical vs. Possible

Posted Oct 14, 2003 20:25 UTC (Tue) by rknop (guest, #66) [Link] (2 responses)

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

Practical vs. Possible

Posted Oct 14, 2003 20:38 UTC (Tue) by ncm (guest, #165) [Link] (1 responses)

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

Posted Oct 14, 2003 20:55 UTC (Tue) by Ross (guest, #4065) [Link]

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 :)

LinkSys and binary modules

Posted Oct 23, 2003 11:55 UTC (Thu) by Wol (subscriber, #4433) [Link] (1 responses)

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

LinkSys and binary modules

Posted Oct 23, 2003 21:49 UTC (Thu) by mmarq (guest, #2332) [Link]

"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

Posted Oct 23, 2003 21:23 UTC (Thu) by mmarq (guest, #2332) [Link]

"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 ?


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds