Alright, BUT. [LWN.net]

Alright, BUT.

Posted Dec 7, 2005 12:32 UTC (Wed) by rknop (guest, #66)
In reply to: Alright, BUT. by dash2
Parent article: Linux in a binary world... a doomsday scenario

My idealism hasn't run out. I still try to buy and run things that work with free only drivers. But I'm getting increasingly tired trying to evangilize. "You keep saying Linux is so great," people tell me, "but it's so hard to get the computer working. What's great about that?" This is after they have to futz around downloading a bunch of binary drivers for their laptop. This is after installing Debian, only to find that they can't just upgrade the kernel, but have to go through a bunch of downloading again to make it all work. This is after finding out that some of the features just don't work. "Why don't you just run Windows?."

Or they're submitting a proposal, and it has to be in Word format, and OpenOffice.org is (for whatever reason) formatting it less efficiently so they get fewer words per page than they do with Word. The call comes to have a Windows machine available for all the students to use. (I say, sure, do what you want, but I will have nothing to do with it.)

And, society has become so jaded and cynical that any talk of "freedom" makes me sound like a silly crazed zealot. Never mind that every so often I've got a practical point that makes it clear that freedom is important. (E.g., last week in Chile, a couple of students weren't able to do the homework assignment they had thought they could do in IDL because the school wasn't letting external connections to the port that the license server was running on.) By and large, maintaining freedom nowadays seems, at least, to introduce more hassles than being tied to propreitary stuff, and I've not succeeded in making the long-term arguments about selling out your flexibility to proprietary vendors. I crow when I can about situations like this IDL situation, but too often the hassles seem to go the other way.

In the early days of Linux, it was often hard to get free drivers for Linux because Linux wasn't on anybody's radar. Of course, back then, you were a bit more likely to get specs on hardware than you are now, but it wasn't always true. (Remember when laptops didn't work with free X for a while because of the NeoMagic chipset?) Nowadays, it's getting harder to get free drivers for Linux because too many companies think that putting out binary drivers is a reasonable solution. I can't help but wonder if Linux is big enough now that the lkml people should start throwing their weight around, and explicitly disallow binary modules. That will break the hardware of companies that won't play at all with the free software communiyt. And, yes, it will be a pain for the people who have a laptop and say, "hey, I want to try Linux!" But for those who plan ahead, it will help publicize the fact that only some hardware really works with Linux.

I dunno. It's a pain in the butt and a thorny issue. And the fact that so many people in "technical" physics (I'm thinking Physics grad students here) are now coming in thinking they're computer literate because they use Windows IM and IE, and if they've programmed they've used MATLAB or IDL or something else proprietary on Windows, the pressure from the geeks is making it harder and harder for zealots like me to keep free software a seeming necessity.

I just wish one could argue for freedom out loud without sounding silly.

-Rob

to post comments

Alright, BUT.

Posted Dec 7, 2005 22:44 UTC (Wed) by bojan (subscriber, #14302) [Link]

Exactly what I feel every day at work too. The battle for freedom is an uphill one. I'm lucky enough that people around me are old Unix hands, so pointing out that source is the ultimate "everything" when it comes to software is relatively easy.

But what about regular folks that only care if the system works or not? How to convince them that having a slow driver for their NVidia graphics chip, that doesn't support 3D and/or dual head on the same card is better than the latest and greatest proprietary driver? And how to convince them that a system that requires manual intervention on a kernel change (not that they wuold know what that means anyway) is better than the one that doesn't? Unfortunately, I don't know the answer to this question. Not without sounding silly from their point of view. For them, their computer is just like their mobile phone, TV, fridge or the car. They want it to be cheap to buy and run and to be reliable and hassle free. All else is a non-issue.

As I posted above, I'm all for full source drivers. But I'm not so sure where and how the pressure needs to be applied to convince hardware manufacturers to drop binary only drivers.

If only there was one manufacturer that openly supports Linux, like IBM or HP, that had a complete line of products that work 100% with vanilla Linux, at least there would a "fallback" plan. At least we could say that if you want a 100% free Linux OS, you can buy models of PDAs, notebooks, desktops, workstations and servers from them, where every imaginable hardware feature is turned on and works. A bit like what Apple does with their systems, only with vanilla Linux.

I know. I should keep dreaming...

Alright, BUT.

Posted Dec 9, 2005 16:10 UTC (Fri) by Duncan (guest, #6647) [Link]

> I can't help but wonder if Linux is big
> enough now that the lkml people should
> start throwing their weight around, and
> explicitly disallow binary modules.

A number of kernel developers, most notably Greg KH, have predicted that
this will practically be the case, in a few years. They ARE gradually
tightening down on it, and asserting themselves. A couple, with copyright
ownership enough to make it stick, have legal cease and desist orders
pending against certain distributions for shipping binary modules on the
same media as the kernel, violating the legal requirements of the GPL, and
there's the (successful) efforts of the German guy (forgot his name)
that's behind the netfilter stuff to get source released for the various
stuff on routers and the like using it. Likewise, more and more of the
newer kernel functions are being exported GPL_ONLY, and while few of the
older functions are being actively restricted to GPL_ONLY, a fair portion
are now deprecated and will eventually be removed from the kernel.

Note the references in the original article to "glue" code. Both ATI and
NVidia use BSD source licensed glue code to interface their binary-only
core with the kernel, using the BSD licensed code as a "glue" layer, as do
certain other "binary-only" module providers. This accomplishes a number
of things, both legally and technically.

First, the legal side, BSD licensed code, because it's less restrictive
than the GPL, is GPL compatible, so it can freely link the kernel without
issue. Second, BSD code, unlike GPL, allows itself to be taken
proprietary or to link with the binary-only core as it does in these
cases. Third, as long as it's the user that links the compiled core/glue
combo into the kernel, /and/ as long as it was shipped separately from the
kernel, many legal minds hold that no violation of the GPL has occurred,
because the GPL applies to distribution, end-users are free to use it as
they see fit.

Legally, there's still the issue of whether the combined unit is "derived"
from the kernel and therefore subject to the non-distribution clause, even
separately, but that's a very controversial gray area, at this point, with
the current situation basically being an agreement not to specifically say
one way or the other, thereby letting the practice continue in this gray
area. It's anyone's guess how a court would resolve it, if it came to
that, but it's currently in enough folks' interests on both sides not to
let it come to that at this point.

Practically, this glue code model is what allows the core to be
dynamically matched to any arbitrary kernel out there, tho the glue code
must be recompiled in ordered to do so. That's what allows such modules
to be used on other than kernels officially supported by the hardware
manufacturer, for which precompiled modules are available for download.
Were it not for this glue code, only those manufacturer supported kernels,
and those "close enough" to work even if not supported, would work with
these binary modules, which is the situation many who do /not/ use this
glue-code method find themselves in.

Within 2-3 years, it's going to become /very/ difficult for the
non-glue-code folks to ship binary modules, technically. Probably at
about the same point, legal enforcement efforts will be stepped up to the
point where it becomes nigh impossible to distribute them anyway, save for
locations where copyright laws aren't enforced to any serious degree
anyway.

It'll remain possible altho less and less practical, and less and less
approved of within the community, for glue code folks to ship binary
modules, for some time. At some point, most will probably give in and
stop shipping them, either providing at least limited support/cooperation
on open drivers, or leaving the Linux market. The idea from the Linux
side is to have a large enough market share by then that it won't be
feasible to leave that market share on the table, and we'll get proper (if
limited) open specifications or drivers.

Ultimately the glue code legality question will probably be resolved in
court as well, but note that particularly where the same core can be shown
to be used on other OS platforms, especially where said core is developed
for those other platforms at the same time or first, it's going to
be /very/ hard to argue that the same is "derived" code. Of course, if
the glue code is held to be derived, as is MUCH more likely, then it can
be held to be required to have the GPL license itself, and linking to the
binary core as it must do would then become very iffy, at best. Even
then, however, that code would be owned by whoever authored it, presumably
the hardware manufacturers, and they can't be obligated to relicense under
the GPL. What they *CAN* legally be obligated to do, however, is to stop
shipping said code, because it's derived from GPL licensed code, and
therefore, according to the GPL, cannot be shipped at all if it cannot be
shipped under the same license. (Note that the loophole used for more
permissive licenses such as BSD, is that because they are more permissive,
they allow shipping under the less permissive GPL as well. If it were
held that the BSD license was invalid because the code was in fact derived
from GPL licensed code, and thus /cannot/ be shipped under the more
permissive license, then that loophole would disappear. In any case,
however, it could only be the distributor held liable, NOT the user, as
the user can always use the software, under the GPL, tho /not/ always
distribute it, but users don't normally distribute the kernel complete
with loaded-in modules, anyway -- nobody does.)

Anyway, things are likely to get pretty interesting in the next few years,
if the tightening trend continues as it has the last few years.

Duncan