In response to pressure from the Free Software Foundation and the
community, LinkSys has made a new tarball available containing the source
for the firmware running in its WRT56G wireless router. This new source
; get the 1.41.2 version) contains a good deal of new code,
including the modifications to the kernel to support the Broadcom 4702
processor. Many of those who have been pursuing
this particular GPL violation case are now satisfied.
The celebration is not universal, however; the new kernel source still
lacks the driver for the wireless interface. Unlike the other kernel
modifications found in the WRT54G router, the wireless interface is
packaged as a separate, binary module. In the eyes of many, that packaging
is sufficient to ensure that the driver is not a derived product of the
kernel, and, thus, it need not be licensed under the GPL. But not
The status of binary modules remains the subject of a great deal of confusion;
it deserves (yet another) look. There is a widespread impression that
Linus Torvalds has issued a blanket exemption to the GPL for closed-source
modules. There are only two problems with this idea: (1) it is not
entirely true, and (2) the relevance of Linus's opinion is limited.
On the first point, consider this pronouncement
from Linus, issued almost exactly one year ago:
There is NOTHING in the kernel license that allows modules to be
non-GPL'd. The _only_ thing that allows for non-GPL modules is
copyright law, and in particular the "derived work" issue. A vendor
who distributes non-GPL modules is _not_ protected by the module
interface per se, and should feel very confident that they can show
in a court of law that the code is not derived.
On the second point, it suffices to remember that Linus is far from the
only kernel copyright holder. He made a crucial decision years ago to not
copyright assignments from contributors, and, thus, to allow each
contributor to retain copyrights on his or her code. As Linus's role has
shifted from coding to rejecting contributions from others, the portion of
the kernel code base carrying his copyright has shrunk. Linus can speak
for himself, but not for the other kernel copyright holders. And some of
the others are getting increasingly grumpy about closed-source modules.
The crucial question here is whether a court would find that a kernel
module is a derived product of the kernel itself or not. There is a
difference of opinion on that score, to say the least. Eight years ago,
that kernel modules, by virtue of the module API which only allowed
modules to link to "logically independent" functions within the kernel,
were not derived products. As
others have pointed out, the list of
functions available to modules is rather less controlled these days. 2.6
loadable modules have access to a great many kernel functions (a quick
grep turns up over 8000 exported symbols) and require a great deal of inline
code from the kernel header files. By some accounts, any code that is so
intimately tied into the kernel must be a derived product.
Others have taken the view that anything which can be
unplugged and replaced is not a derived product. The existence of a
plug-in interface creates a boundary which the GPL cannot cross.
In some cases, this must
be true; consider, for example, Linuxant's controversial new DriverLoader product. DriverLoader is a
proprietary module which will interface Windows NDIS network drivers to the
Linux kernel. The legal status of DriverLoader may be unclear, but nobody
would argue that a binary Windows driver, when shoehorned into the Linux kernel in
this way, becomes a derived product of the kernel. On the other hand, with
a small (GPL-licensed) patch, the kernel could be opened to "pluggable"
modules implementing proprietary network protocols, memory managers,
schedulers, etc. This scheme, if considered legal, would allow proprietary
code to be lodged within the heart of the Linux kernel. At that point,
there would be no restriction on derived products at all.
Another view, less often heard, notes that the kernel module loader checks
the license of every module loaded into the system. 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.
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.
In the LinkSys case, some developers are claiming that the source for the
binary modules should be released even if they are not strictly seen to be
derived products. This claim is based on the following language from
section 2 of the General Public License:
If identifiable sections of that work are not derived from the
Program, and can be reasonably considered independent and separate
works in themselves, then this License, and its terms, do not apply
to those sections when you distribute them as separate works. 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.
Some feel that the LinkSys WRT56G router is, indeed, a "whole which is a
work based on the Program" and that the entire system must be licensed
under the GPL if it is to be distributed legally. This view relies on the
provisions of the GPL, and not just on copyright law; it is controversial,
to say the least. By this reasoning, a Linux distribution with, say, a
proprietary installer could be seen to be violating the GPL. In the end,
this claim, too, can only be verified in a courtroom. Until then, the
definition of a "whole" is subject to debate.
The status of closed-source modules has always been somewhat unclear, and
one gets the impression that the kernel developers have been happy to keep
it that way. There is a strong desire to discourage such modules, but,
seemingly, little wish to abolish them altogether. The system has worked
reasonably well so far, but it may well be asking for trouble in the longer
term. With the current state of affairs, it seems certain that, sooner or
later, a company or individual holding kernel copyrights will take a
proprietary module vendor to court.
One of the best features of free software is the fact that users don't need
to worry. The rights of users are broad and well defined;
there is no equivalent of the Business Software Alliance looking for
companies to raid. The distribution of closed-source kernel modules is an
exception, however; nobody really knows if this distribution is legal or
not. The free software community is not helped by this uncertainty; it
really is past time to clarify the status of closed-source modules. Doing
so will be a challenging task, but doing nothing will bring unwanted
challenges of its own.
The free software community does not need any more litigation, be it
instigated by ourselves or by others.
Comments (30 posted)
We have recently received two books, both of which attempt to set down the
Unix philosophy. This philosophy is said to underlie the work we all do
with Linux, so discussions of it are worth a look. Maybe we can finally
find out what we have been trying to do all these years.
The first is The Art of Unix Programming by Eric Raymond (published
by Addison Wesley). We have
discussed this book before on these pages,
so a detailed look is not necessary at this time. Suffice to say that
Eric's book is now available in the stores. It is also available on the
net under a relatively restrictive Creative Commons license.
The other entry is Linux and the Unix Philosophy by Mike Gancarz,
published by Digital Press. This book appears to be a fairly
straightforward remake of Mr. Gancarz's The Unix Philosophy,
published in 1994. References to Linux have been retrofitted in, but the
book is little changed. If the underlying Unix philosophy is as enduring
as these books would have us believe, a book from 1994 should still be
current now. Unfortunately, Linux and the Unix Philosophy looks
old; consider, for example, the author's advice that a function's parameter
list should fit on a single line of an (80-column) screen. That might have
been good advice for an old-style C function, but, in the modern world,
where parameter names and types all go together, even a very short
parameter list can take multiple lines.
This book also ignores many of the features of modern Unix/Linux
programming, including scripting languages (beyond the shell) and graphical
interfaces. In Mr. Gancarz's view, all programs are small, and their
functions are minimal; he even states that multi-column output has bloated
the ls command excessively. Or consider:
Why has the metric of MIPS become such a hot issue in the computer
world today? Because as Unix usage has become more prevalent, the
use of small programs has proliferated as well. Small programs,
although they usurp little system memory when executing, derive the
most benefit from the injection of additional CPU horsepower.
This discussion does not fit your editor's world, where the best way to
improve the performance of a system is often to add memory.
The most interesting area of investigation, however, would be how the two
books characterize the Unix philosophy. Happily, both of them provide nice
sets of rules suitable for slides in any executive briefing - or a summary
table in LWN. So, without further ado...
|The Art of Unix Programming
||Linux and the Unix Philosophy|
Write a big program only when it is clear by demonstration that
nothing else will do.
Small is beautiful.
Design for simplicity; add complexity only where you must.
Make each program do one thing well.
Prototype before polishing. Get it working before you optimize
Build a prototype as soon as possible.
(No rule, but portability is listed as one of the things Unix got
Chose portability over efficiency.
Design programs to be connected with other programs.
Store data in flat text files.
Make every program a filter
Avoid hand-hacking; write programs to write programs when you can.
Use software leverage to your advantage. [i.e. reuse code].
Programmer time is expensive; conserve it in preference to machine
Use shell scripts to increase leverage and portability.
In interface design, always do the least surprising thing.
Avoid captive user interfaces.
When a program has nothing to say, it should say nothing.
Silence is Golden
Look for the 90-percent solution.|
Worse is better.
Design for visibility to make inspection and debugging easier.
Fold knowledge into data so program logic can be stupid and robust.
Repair what you can, but when you must fail, fail noisily and as
soon as possible.
Separate policy from mechanism; separate interfaces from engines.
Distrust all claims for the "one true way."
The further expression of these rules shows the relative age and limited
scope of Gancarz's book. He talks about flat text files, while Raymond
discusses the importance of transparent, textual network protocols as
well. Raymond covers the network, modern languages, and the ups and downs
of programming techniques as an integral part of his book; Gancarz has a
brief "Brave New World" chapter at the end where he treats bleeding-edge technologies
like the Internet, artificial intelligence, object-oriented programming,
On the other side, Eric Raymond's tendencies are well known. The Art of
Unix Programming can be verbose and gives a lot of coverage to
Mr. Raymond's own work and beliefs. Most people would have found a way to
write a Unix book without including quotes from famous people on the evils
of gun control, for example.
Both books neglect areas of great concern for any contemporary software
developer. Neither will give as much help as the implementer of a web
browser, office suite, or DVD player might like. No developer can afford
unaware of security issues in the current environment, but neither author
devotes any space to security. What is the Unix philosophy's
approach to security? Silence in response to that question is all too
In the end, if your editor had to choose between the two books, he would go
with The Art of Unix Programming, though both have their merits.
Readers of either would be well advised to heed Mr. Raymond's last rule,
however: distrust anybody who claims to know the "one true way."
Comments (5 posted)
After Citizens Against Government
(CAGW) issued a strongly-worded
press release against the state of Massachusetts's initiative
to move toward open systems, we at LWN decided to take a longer look at
this organization's background and see why they might exhibit such
hostility toward open source.
According to CAGW's website, the group has been in operation since 1984.
It is, according to its press materials "a private, non-partisan,
non-profit organization" on a mission to eliminate "waste,
mismanagement, and inefficiency in the federal government." It claims to
be "nationally recognized as the source of information on
government waste," with more than one million members.
Apparently, Microsoft has
been one of the corporate donors that provided funding to CAGW in the
past. But the group prefers to remain mum on
whether Microsoft continues to fund them and what other groups may
be providing funding.
We contacted CAGW directly to find out whether Microsoft is still
donating money, and how they came to form their opinions on open source
use in government. We spoke to CAGW President Tom Schatz, who also
declined to specify whether CAGW is still receiving money from Microsoft
and said that interested parties could examine CAGW's IRS 990 filing.
CAGW is required to make this document available upon request, but is not
required to provide the names of its donors.
We located CAGW's filings for 2000 and 2001 online, but the donor information had been whited out. According to CAGW's website, about 85 percent of the organization's funding comes from individual contributors, with the remaining 15 percent coming from corporate and foundation gifts. In 2001, three contributors donated a total of $490,765 to CAGW, accounting for only 10 percent of the non-profit group's entire income of $4,898,720 for the year. In 2000, CAGW brought in $4,846,934 with a single anonymous donor of $150,000. If Microsoft or one of the foundations it supports is still a contributor to CAGW, the contributions are only a minor percentage of overall contributions.
To be sure, CAGW does not exist solely as an apologist or mouthpiece for
Microsoft. The organization tracks government spending in many areas
unrelated to the software industry, and provides ratings for members of congress, according to their criteria of eliminating government waste.
However, the group has been unrelenting in its opposition
to the governments' antitrust suit against Microsoft, and was part of the
"grass-roots" effort to stir up public support against the suit. The group
made headlines after some of their form letters were mailed in by CAGW
members who had
Citizens Against Government Waste, on the other hand, distributed
identical letters to citizens. Those varied only by the signature
attached. The two letters from beyond the grave came from the Citizens
Against Government Waste crop. According to the Times, family members
crossed out the names and signed for them. Another letter was sent from
"Tuscon, Utah," a city that doesn't even exist.
When news hit the wires late last month that Massachusetts may be
favoring open source, CAGW was quick to oppose the idea -- apparently
without bothering to get all the facts on the issue first. Schatz admitted
that he later found that, contrary to the position stated in
the release, Massachusetts was not barring proprietary vendors
from competing for state contracts. Schatz says he will issue a second
release with a correction "if something does come out in writing from the
state...we've seen quotes, but nothing in writing."
We asked Schatz if he opposes open source software in government, and he
replied that he was not opposed to open source software but was opposed
to a policy that prefers or requires single-sourcing.
We have been fairly consistent with support for the concept of
dual-sourcing a piece of equipment...the state needs to consider what
the best product is, what's going to operate most efficiently.
We also asked Schatz about the communist rhetoric contained in their
"Mass. Taxpayers Hurt by Proposed Software Monopoly" release. Schatz
denied that comparisons of Massachusetts' open source policy were
designed to tie in with other comparisons of open source and free
software to communism or socialism.
If you read any of our stuff... take a look at our porker of the month,
we're just as strong in our language... I may choose my words more
carefully next time. We're trying to raise an government issue, not an
issue with how people see the world. Communism won't be part of the next
Schatz also mentioned that CAGW group received a number of e-mails from
the Linux community on the topic, and had discovered that the community
does not appreciate comparisons to communism or socialism. He also noted
that CAGW receives strong reactions to many of their releases, not just
those on the topic of Linux or open source. A cursory search of CAGW's
website did not turn up references to socialism or communism as
metaphors for other government waste. The reader can judge for
themselves whether the tone in other CAGW releases is similar to the
tone of the "Proposed Software Monopoly" release.
It may be that CAGW is poorly informed on the benefits of open source,
and too easily swayed by pro-Microsoft studies. Schatz acknowledged that
CAGW had not performed any studies independently to determine the cost
benefits of open source products versus proprietary software.
We honestly don't have the expertise here to fight the studies, or to
make our own, we rely on things that are out there...since open source
is newer for government experience, we should probably wait and see how
it works and what the expenses are on the other side.
It's clear that CAGW carries a substantial amount of influence with a
widespread public audience, and with elected officials. Open source
advocates would do well to keep tabs on future pronouncements from the
group, and to work toward politely educating CAGW on the benefits of
free software and the unnecessary waste of government funds on proprietary
Comments (7 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Open filtering rules considered harmful; new vulnerabilities in glibc and tomcat.
- Kernel: Looking forward to 2.7; Write barriers; Sysfs and small-memory systems; Letting sleeping processors lie.
- Distributions: A Review of LindowsOS 4.0, Mandrake Linux 9.2, Ankur Bangla Live, Office optimized Linux (OoL)
- Development: The Meld Graphical Comparison Tool,
new versions of ALSA, MICO, ZODB, CUPS, ESP Ghostscript, Gallery,
Ardour, PNGwriter, Gaim, GStreamer.
- Press: FUD of the month, a look at Linus, Samba faster than Windows,
open source in the UK and Asia, Filesystem resources.
- Announcements: Linux More Secure Than XP, LSB needs init test reviewers,
GNOME Summit 2003, ObjectWeb Conf, SCOX stock bubble.
- Letters: Monocultures