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
Posted Oct 14, 2003 20:17 UTC (Tue)
by ncm (guest, #165)
[Link] (3 responses)
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.
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
Posted Oct 14, 2003 20:38 UTC (Tue)
by ncm (guest, #165)
[Link] (1 responses)
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.
Posted Oct 14, 2003 20:55 UTC (Tue)
by Ross (guest, #4065)
[Link]
Posted Oct 23, 2003 11:55 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (1 responses)
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,
Posted Oct 23, 2003 21:49 UTC (Thu)
by mmarq (guest, #2332)
[Link]
Posted Oct 23, 2003 21:23 UTC (Thu)
by mmarq (guest, #2332)
[Link]
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 ?
The question of whether binary-only modules are allowed comes down
to whether, and under what circumstances, it's possible to
restrict them.
Practical vs. Possible
Practical vs. Possible
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.
Practical vs. Possible
I don't think copyright's concept of derivative works have anything to doPractical vs. Possible
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 :)
Or go down the microkernel approach :-)LinkSys and binary modules
Wol
"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"LinkSys and binary modules
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.
"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."LinkSys and binary modules