Alright, BUT.

Alright, BUT.

> 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