LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Linux in the news
Announcements
Letters to the editor
->One big page
This page
Previous weekFollowing week
| |||||||||||||
LWN.net Weekly Edition for October 2, 2003LinkSys and the GPL - againLast June, we published a story about LinkSys and its WRT54G wireless router product. That router runs Linux, but LinkSys was not making the source for its Linux kernel available as the GPL requires. In response to pressure from the community, LinkSys eventually released a kernel tarball, and it appeared that the episode had come to a close. Another apparent victory for the GPL.In this case, however, it seems that the victory celebrations were a bit premature. A group of programmers has been working with the LinkSys tarball in the hopes of creating a new, more accessible firmware image for the WRT54G. Over time, this group has come to the conclusion that the kernel source released by LinkSys is incomplete. Efforts to resolve the situation with LinkSys have not been conclusive, so, on September 28, this group sent out a letter describing its findings. Much of the code in the WRT54G kernel gets there by way of loadable modules. In particular, much of the truly interesting stuff - the code that implements the low-level wireless functionality - is packaged in modules. The question of whether loadable modules are a derived product of the kernel - and thus subject to the GPL - is a topic of ongoing debate; not all kernel hackers are happy to see their work used by binary-only modules. A definitive conclusion in that debate may never come about; in the real world, however, binary-only modules are tolerated. Nobody has made any serious public effort to get LinkSys to release the source to its binary kernel modules. (Update: it turns out that claim is not entirely true; see the comments added to this article for details). The results of the investigation by the WRT54G hackers, however, indicate that the WRT54G kernel contains a substantial amount of built-in code. There is no ambiguity around code which is patched directly into the kernel; it is clearly a derived product. A kernel which is patched in this way can, by the GPL, only be distributed if the source for those patches is released under the same license. LinkSys (or the contractor which did its kernel work) has tried to slip in a kernel source tarball which does not include the code found in its binary image; that is a GPL violation, and the company has been caught. It is not clear how the people involved thought they would get away with this attempt; perhaps they thought nobody was really interested in looking at their source. What happens now? The WRT54G hackers have released their information in the hope that a wider public awareness of the problem will help push LinkSys into living up to its obligations under the GPL. It turns out, however, that the Free Software Foundation is working on this case, and they are asking for patience.
GPL violations sometimes take time to resolve. We wish that we
could force resolution quicker, but we haven't found a way to do
that. We have, however, discovered a variant of Brooks's Law:
adding more lawyers to a GPL violation usually makes it take
longer. Lawyers are reluctant to admit to mistakes, because they
fear it could be used against them. Engineers and product managers
are typically interested in fixing mistakes, so we try our best to
work with them first before escalating to legal teams on both
sides. Such escalation has happened on this violation, so it will
take additional time to resolve the matter.
The FSF also points out that the kernel is only a part of the GPL-licensed software running on a WRT54G router. The FSF is trying to represent the copyright holders of all the affected software and resolve the whole problem. They will, they say, keep the community informed as things progress. The FSF's work on GPL enforcement is usually hard to see; it is done in a quiet and diplomatic manner that is invisible behind the rhetoric that comes out of other parts of that organization. The FSF claims to have built the free software community, but it toots its own horn rather less on the subject of GPL compliance. But the FSF's GPL work plays a crucial role in keeping the free software community going; we owe them a debt of gratitude for the work they do to ensure that the terms of our licenses are respected. In the LinkSys case, we also owe them some space and time to do their work. The FSF has been highly successful in resolving GPL violations without the need for long and expensive court cases. With some luck and patience, we can hope to see a similar resolution here.
This week in SCOlandAs much as we might have wished that the SCO case would have gone away over the last week, it's still there. So here's the obligatory update on what has been happening...IBM has filed a new set of counterclaims against SCO. The full, new filing is available in PDF format. The new material is relatively small, and makes three points. The first of those points is a promissory estoppel claim. SCO, says IBM, promised that it would distribute Linux only under the terms of the GPL. IBM, acting on those promises, has now been burned, and has suffered an injury as a result. IBM claims damages to compensate for that injury, but the real purpose of the estoppel claim is to shut SCO up:
In addition to an award of damages, IBM is entitled to declaratory
and injunctive relief, including but not limited to a declaration
that SCO is not entitled to assert proprietary rights with respect
to products distributed by SCO under the GPL except upon the terms
set out in the GPL.
"Estoppel" says that a company cannot behave in one way, allow others to act based on that behavior, then change the rules afterwards. IBM is claiming that this is exactly what SCO is trying to do in this situation, and is asking the court to put a stop to it. The second new counterclaim alleges copyright infringement based on violations of the GPL. This claim is different from (and additional to) the GPL violation claim in IBM's first counterfiling. Whereas the previous claim was a breach of contract claim (SCO did not live up to the obligations it took on when it accepted the GPL), the new one is a pure infringement claim. IBM lists several contributions for which it has registered its copyrights (they include EVMS, dynamic probes, PowerPC support, the Omni print driver, JFS, and others), and claims:
SCO has infringed and is infringing IBM's copyrights by copying,
modifying, sublicensing and/or distributing Linux products except
as expressly provided under the GPL. SCO has taken copyrighted
source code made available by IBM under the GPL, included that code
in SCO's Linux products, and copied modified, sublicensed and/or
distributed those products other than as permitted under the
GPL. SCO has no right - and has never had any right - to copy,
modify, sublicense and/or distribute the IBM copyrighted code
except pursuant to the GPL.
The last new counterclaim is a request for a declatory judgement along the line of Red Hat's suit. Essentially, IBM is asking the court to make SCO shut up. SCO's response came in the form of yet another strange press release. SCO has nothing to say about IBM's description of its behavior; instead, the company has gone for a flat-out attack on the GPL:
IBM, not SCO, has brought the GPL into the legal controversy
between the two companies. SCO believes that the GPL -- created by
the Free Software Foundation to supplant current U.S. copyright
laws -- is a shaky foundation on which to build a legal case. By
contrast, SCO continues to base its legal claims on well-settled
United States contract laws and United States copyright laws.
The GPL has never faced a full legal test, and SCO believes that it will not stand up in court. We asked SCO how it is that the GPL serves "to supplant current US copyright laws" while its own software licenses do not, but SCO chose not to answer us. Regardless, what SCO hopes to gain by attacking the GPL is unclear; its legal theories on the subject are bizarre at best. But if the GPL fails, then SCO will never have had a valid license to distribute Linux at all. It would be interesting to hear how SCO justifies its continued distribution of the Linux kernel if it believes it lacks a valid license to do so. Red Hat, meanwhile, has filed a "memorandum in opposition" of SCO's attempt to get Red Hat's lawsuit summarily dismissed. Groklaw has posted the motion in PDF format. Also on Groklaw is this detailed analysis of Red Hat's motion which covers the relevant points.
SCO also claimed that its speech was protected by the First
Amendment. Frankly, that argument is so funny it seems pointless to
stay up late to explain it to you... Red Hat had to actually
research the point and answer it in detail. I'll bet they were
rolling on the floor laughing though. Once they pulled themselves
together, they point out to the judge that there are laws
specifically written that forbid companies from making 'false or
misleading statements' about another's product, and it's called the
Lanham Act...
As expected, the SCO Group has also expanded the battle to include SGI. Very little has been said in public (we're waiting for the inevitable conference call), but a couple of alert readers found the following in SGI's annual report as filed with the U.S. Securities and Exchange Commission:
We have received a letter from SCO Group alleging that, as a result
of our activities related to the Linux operating system, we are in
breach of the fully-paid license under which we distribute our IRIX
operating system. The letter purports to terminate our UNIX System
V license effective October 14, 2003.
SGI believes, like IBM, that its Unix license cannot be terminated in this manner. SCO arguably has a better case against SGI, since SGI did actually allow a small amount of SYSV code to slip into its Linux kernel contributions. SCO will have a hard time talking a tiny infringement involving code that, by some reckoning, is in the public domain into a major case, however. Speaking of SGI's actions, the company has posted a letter to the Linux community from software VP Rich Altmaier. The letter admits that the ate_malloc() code shown by SCO could have been taken from SYSV, though SGI also reiterates the claim that the code in question may well have entered the public domain. SGI has sent patches to its customers removing the code in question, but it has not stopped there:
Following this occurrence, we continued our investigation to
determine whether any other code in the Linux kernel was even
conceivably implicated. As a result of that exhaustive
investigation, SGI has discovered a few additional code segments
(similar in nature to the segments referred to above and trivial in
amount) that may arguably be related to UNIX code. We are in the
process of removing and replacing these segments.
In other words, the Linux kernel has now been compared to the Unix code base by somebody other than SCO, and it has been given an (almost) clean bill of health. SGI's letter also denies that SCO has any claim to the XFS filesystem. XFS is explicitly claimed as SGI's work.
It may be that SCO is taking the position that merely because XFS
is also distributed along with IRIX it is somehow subject to the
System V license. But if so, this is an absurd position, with no
basis either in the license or in common sense. In fact, our UNIX
license clearly provides that SGI retains ownership and all rights
as to all code that was not part of AT&Ts UNIX System V.
The position described is, of course, exactly the claims SCO has made against IBM. Finally, remember that the SCO City-to-City Tour starts on October 7. Those of you in or near Toronto, Boston, Chicago, Vancouver, Dallas, Orlando, Newark, Minneapolis, St. Louis, Irvine, or Atlanta may want to consider signing up to share your views with the company.
Distributing 2.6As the 2.6 kernel slowly approaches release, it is natural that vendors and users are becoming more interested in what this kernel has to offer. But some distributors may be jumping the gun a bit with this kernel. Consider these announcements:
The only problem, of course, is that there is no 2.6 kernel. The 2.6.0-test series is not the 2.6 kernel. It remains in active development, and many parts of it are still volatile. The most recent release (2.6.0-test6) included a fundamental change in the dev_t device number type, a bunch of scheduler work, numerous power management patches, and a lot of other changes. A number of important kernel interfaces are still in flux. Auditing for security problems still needs to be done. One should also bear in mind that most stable kernels do not truly stabilize until several releases after "dot-zero." The 2.5 kernel development series looks to be one of the most successful in quite some time. Many important objectives have been attained, and the 2.6.0-test kernels appear to be quite stable for most users. It is certainly an appropriate time for distributors to consider offering a 2.6 preview kernel, as SuSE will do with its 9.0 release. But it is too soon to present a 2.6-based distribution as being "production ready." Any distributor which is offering the 2.6 kernel as anything other than an early preview for testing purposes is not being entirely honest. We'll have our stable, 2.6-based distributions sometime in 2004; some things cannot be rushed.
Page editor: Jonathan Corbet Inside this week's LWN.net Weekly Edition
|
|||||||||||||