LinkSys and binary modules

Posted Oct 14, 2003 19:18 UTC (Tue) by rknop (guest, #66) [Link]

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 19:29 UTC (Tue) by james (subscriber, #1325) [Link]

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.

Posted Oct 14, 2003 19:56 UTC (Tue) by proski (guest, #104) [Link]

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.

Posted Oct 14, 2003 21:21 UTC (Tue) by coriordan (guest, #7544) [Link]

Posted Oct 15, 2003 12:20 UTC (Wed) by ballombe (subscriber, #9523) [Link]

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

Posted Oct 16, 2003 5:04 UTC (Thu) by pjm (subscriber, #2080) [Link]

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.

Posted Oct 16, 2003 7:24 UTC (Thu) by lacostej (guest, #2760) [Link]

Posted Oct 16, 2003 15:03 UTC (Thu) by leonb (guest, #3054) [Link]

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

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.

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

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