LWN.net Weekly Edition for October 16, 2003

LinkSys and binary modules

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 distribution (available here; 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 everybody agrees.

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:

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 require 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, Linus suggested 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:

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 contract 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)

Two views of the Unix philosophy

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:

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 it.	Build a prototype as soon as possible.
(No rule, but portability is listed as one of the things Unix got right).	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 time.	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, and Java.

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 to be 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 telling.

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)

Background on Citizens Against Government Waste

After Citizens Against Government Waste (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 died.

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

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.

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

Comments (7 posted)