Leading items

Looking back at 2003

We predicted:

• Governmental use of Linux would increase. Nobody can say that we missed on that one. Legislation requiring (at a minimum) proper consideration of free software in public purchasing has been introduced, and often passed, in many countries. Nations like Brazil and South Korea have committed to increasing their use of free software. Cities like Munich and Key Largo have made big jumps into free software. All this goes to show: it's easier to make correct predictions if you stick to obvious developments.

• There would be high-profile desktop deployments. Opinions remain mixed on whether Linux is ready for serious desktop use now, but few dispute that it is getting there. Desktop Linux provides all the functionality that many users need, and it gets better every day. Big deployments have happened in many places, perhaps topped by Sun's large Linux sale in China, which could eventually add up to millions of desktop systems.

• We predicted a major patent challenge for Linux. A big legal challenge did come in the form of the SCO suit, but patents were not involved. The stage remains set for serious patent problems in the future, perhaps coming from Microsoft's increasing interest in its patent portfolio. But 2003 wasn't the year for that.

• We also predicted "a watershed year" in intellectual property law driven by a number of high-profile cases. Certainly a lot has happened; the Grokster and Skylink rulings went against oppressive copyright enforcement, UCITA died a well-deserved death, and, perhaps most significantly, an attempt to impose software patents on Europe was defeated - for now. On the other hand, the U.S. Supreme Court refused to limit copyright terms in the Eldred case. All told, it was not a watershed year, however; one year later, the situation is almost the same as it was before. All of the problems we had a year ago are still there.

• The 2.6 kernel would be released. That happened, of course, though it wasn't that far from slipping into 2004. We did say it would happen late in the year.

• We predicted a "SourceForge crisis." Some projects have moved away from SourceForge, and the site now has a donation box out to help cover its running expenses. But certainly there has been no "crisis."

• UnitedLinux would not save all four participants; at least one of them would exit the distribution business by the end of the year. Well, that happened, but not quite as we had envisioned. But UnitedLinux member SCO is certainly out of the distribution business, and UnitedLinux has passed into irrelevance. We also said that MandrakeSoft would find a way to pull through and become a viable company. That appears to be happening, albeit via a period in bankruptcy proceedings.

We also missed a few things. The small resurgence in acquisitions of Linux companies (Scyld, Ximian, SUSE, Sistina) was a pleasant surprise, for the people involved if nobody else. The importance and commercial success of "enterprise Linux" distributions, along with the resulting backlash, was and is an important story for 2003. The increasing level of attacks on the community's infrastructure was an ominous development. And the SCO Group's rampage took us by surprise, along with just about everybody else.

What we didn't even bother to predict was that development would continue, the code would get better, and that Linux would continue to grow. That was too obvious even for LWN. But it happened, and will continue to happen. It is still true that the free software story is just beginning.

(Tune in during next week's break, when we will publish our predictions for 2004. We're still trying to get the crystal ball booted up properly as of this writing; contrary to some rumors, the crystal ball has not been taken down by a security compromise. Trust us).

Comments (1 posted)

Johansen wins round two

Johansen was charged with criminal violation of Norwegian law in 2000 for writing and publishing DeCSS. The case was set in motion after the DVD Copy Control Association (DVD CCA) and Motion Picture Association of America (MPAA) complained to the Norwegian Economic Crime Unit (Økokrim) about the distribution of DeCSS. According to the letter sent to Økokrim by the DVD CCA's lawyer, Simonsen Musæus:

However, the court noted that prosecutors had failed to prove that DeCSS had been used for copyright infringement, and that it was reasonable to make copies of DVDs for personal use. As the Electronic Frontier Foundation's Cindy Cohn noted when Johansen was first acquitted by the lower court, "It really feels like there is some sanity creeping in."

Sanity has, apparently, failed to make a stop at the MPAA. The association has rushed to condemn the Norwegian court's decision and released a statement that dubbed Johansen a "serial hacker" and calling on the Norwegian parliament to "move quickly" to "correct this apparent weakness in Norwegian law." It is, unfortunately, also possible that Johansen's legal travails are not quite over yet. Norwegian prosecutors have two weeks to appeal the appellate court decision to Norway's supreme court.

If found guilty, Johansen could have been sentenced to two years in prison. Prosecutors, however, had asked the court for a lesser suspended sentence in the Johansen case, apparently aiming to set precedent rather than seeking to jail Johansen.

The Johansen case makes it quite clear that the entertainment industry is seeking more than a way to curtail illegal copying. While the prosecutors and the MPAA have claimed that DeCSS opens the door to copyright infringement, there is no need to decrypt DVD content to make copies of DVDs -- and no evidence that DeCSS is being used to "pirate" movies.

It is, however, necessary to use DeCSS or a similar tool to decrypt content to make use of the content legitimately on Linux or other systems that lack DVD playback software. The choices available to movie enthusiasts on Linux are somewhat unpalatable: Risk legal prosecution for creating or using tools such as DeCSS, use other operating systems to play movies on laptops and home PCs, or remain unable to watch legitimately-purchased movies on a computer at all.

The Johansen verdict is a welcome victory, but it is hardly a major one. While those in Norway may breathe easier (at least for the moment), those of us in other countries with more repressive laws still lack the legal ability to make copies of legitimately-purchased media.

Comments (3 posted)

Holiday cheer from the SCO Group

We'll start with the quarterly results, as described in this press release. The company lost $1.6 million on revenue of $24.3 million. Of that, $10.3 million came from licensing agreements - all from Microsoft and Sun. It would appear that there are still no other paying licensees. In the conference call, SCO management stated that license revenue in the next quarter would be "minimal." Some direct questions were asked about just what sort of revenue was being received by other licensees, but the answers were, to put it charitably, evasive.

The more interesting part of today's activity is a view into the claims SCO plans to make in the coming months. To that end, there has been another press release, and a new letter being sent to Linux users. What the letter makes clear is that SCO now considers part of the Unix application binary interface (ABI) to be its property. Linux implements the Unix ABI, so SCO has picked out several dozen files which, it claims, violate its copyright. The full list is in the letter, but what it comes down to is each architecture's version of errno.h, signal.h, ioctl.h, plus a few others.

These include files all have the same form: they are really just long lists of #define statements assigning values to symbols. They define the various error codes returned by the kernel, the numbers associated with signals, and the numbers for ioctl() commands. Many of these numbers have nothing in common with any version of Unix, but many others do. So, if you compare the first part of the definitions in the 32V version of user.h with a 2.4 errno.h, you see:

#define EPERM   1
#define ENOENT  2
#define ESRCH   3
#define EINTR   4
#define EIO     5
#define ENXIO   6
#define E2BIG   7
#define ENOEXEC 8
#define EBADF   9
#define ECHILD  10
#define EAGAIN  11
#define ENOMEM  12
#define EACCES  13
#define EFAULT  14
#define ENOTBLK 15
#define EBUSY   16
#define EEXIST  17
#define EXDEV   18
#define ENODEV  19
#define ENOTDIR 20
...

#define EPERM            1
#define ENOENT           2
#define ESRCH            3
#define EINTR            4
#define EIO              5
#define ENXIO            6
#define E2BIG            7
#define ENOEXEC          8
#define EBADF            9
#define ECHILD          10
#define EAGAIN          11
#define ENOMEM          12
#define EACCES          13
#define EFAULT          14
#define ENOTBLK         15
#define EBUSY           16
#define EEXIST          17
#define EXDEV           18
#define ENODEV          19
#define ENOTDIR         20
...

The 2.4 version has comments on each line which have been removed in the above listing, but, even taking those into account, there is clearly a high degree of similarity between the two. The definitions in Linux are obviously taken from older Unix systems. That is not surprising; Linux was intended to implement the same interface. Linux is not alone in having reproduced the Unix error numbers; if you look at the Minix version of errno.h, you see the same interface used. Microsoft uses the same numbers. Modern BSD systems also use the same definitions, of course. The basic Unix numbers for errors and signals have been widely reproduced, to say the least.

If the files in question were, indeed, copied from an ancient Unix distribution, then the Linux developers have arguably violated the associated BSD license by leaving out the copyright headers. This is a copyright violation, but it is also easy to fix by simply restoring those headers. There are enough other sources for these numbers, however, that proving that they came into Linux via any particular path could be hard.

There are a couple of things that one should keep in mind, however, when evaluating SCO's new claims. One is that the copyright status of ancient Unix is uncertain at best, as has been reported many times. The judge in the BSDI case came to the conclusion that USL's chances of enforcing its copyrights were poor. SCO will not have improved those chances. Novell's recent reassertion of its claim to still own the Unix copyrights could also complicate matters for SCO.

The truly important issue, however, is that the old Unix ABI is exactly that: a well established ABI. Copyright law allows for the protection of expressions of an idea, but not the idea itself. Concepts used in an ABI, like "the number 12 means no memory is available," can be very difficult to copyright. If there is only one way to express an idea, you cannot get copyright protection for that expression. In this case, there are truly few alternatives to:

    #define ENOMEM 12

SCO will have a hard time convincing a judge anywhere that copyrights can protect this sort of code - especially given that the error names (but not the associated numbers) are part of the POSIX standard.

SCO seemingly intends to try, however - at least for as long as it takes to shake down some nervous users. To that end, the company is taking two approaches. One is to threaten anybody who distributes Linux with the offending files; that is what the letter was sent out for. From statements made in the conference call, one could conclude that SCO thinks it has users in a bind; constants like error and signal numbers cannot be changed without breaking binary applications. By claiming something that cannot be easily removed, SCO apparently hopes to inspire companies to pay up instead.

The other approach is described in the second press release: SCO is sending notices to its Unix licensees requiring them to "certify" that they are in compliance with the Unix agreement. The letter requires a long list of promises from Unix licensees, including:

It has long been clear that signing a contract with the SCO Group is a Bad Idea. The SCO Group is using its contracts to go after its customers - something which does not generally inspire those customers to buy anything else. The Unix contract is being used as a lever to force those customers to "certify" that they are not running Linux. Needless to say, at this point, few of these customers will be in a position to do that. They are now in a bit of a difficult situation; they can refuse to certify, pay SCO, or claim that Linux does not actually contain any copyrighted ABI code.

As a short-term strategy for SCO, this move must look pretty good. The use of the existing contracts in this way may well succeed in applying enough pressure to make some customers give in. None of those customers are going to appreciate this behavior, however; one would assume that many of them will decide (if they have not already) that entering into any other agreements with the SCO Group is not in their best interests. SCO is destroying whatever future business it may have still had to expedite a short-term shakedown.

A couple of other notes from the conference call are in order. It began with a statement that the call is copyrighted by SCO, and any reproduction ("in whole or in part") is prohibited. Transcripts will certainly be posted; it will be interesting to see if SCO tries to get them taken down. Analyst Dion Cornett (Decatur Jones Equity) appears to be getting a clue: he asked SCO whether it really believed it had a valid license to distribute Samba. Strangely enough, SCO's answer did not address that question at all. Finally, Darl McBride presented the SCO litigation scheme as "a model many companies will adopt" in the near future. If SCO succeeds in its attempts, that statement could well come true. The foundation of SCO's new claims appears weak at best, however. SCO is more likely to become a very different sort of example.

Comments (15 posted)

More SCO cheer

Linus has posted a response to SCO's claims of ownership of various include files in the Linux kernel. In particular, he examines the "ctype" macros, which he wrote personally, tracing their development from very early kernels. Needless to say, he does not concur with SCO's claims in this regard.

Since then, a significant effort has been underway to find the true origins of the errno.h include file. This file, it turns out, was added in version 0.97 of the kernel; Linus has concluded that it was automatically generated from libc-2.2.2 (note that's "libc", not "glibc", which came much later). Tracking down the source for that version of the library was a challenge, but, once it turned up on an FTP site, Linus was able to verify that it was the source for errno.h. The next question would be how the error numbers and descriptions got into libc, but, as Linus says:

In any case, errno.h was not copied from anything owned by SCO.

It is also worth looking into ancient history (October, 2003) to review a quote by SCO's spokesperson Blake Stowell:

Files like errno.h have been in the kernel since well before 2.2, which, apparently, "includes no infringing code." Either SCO has changed its mind in the last couple of months, or they know that this code does not actually infringe upon any copyrights owned by the SCO group. We requested clarification from Mr. Stowell, but, predictably, got no response.

Meanwhile, SCO has announced the abrupt departure of Steve Cakebread from its board of directors, ostensibly due to "personal time constraints." We note (thanks to a pointer from Don Marti) that Mr. Cakebread's day job is Chief Financial Officer at Salesforce.com, which is a heavily Linux-based application service provider. Could it be that Salesforce.com got a shakedown letter from SCO, and has given its response?

SCO's offices are, apparently, shutting down for the holidays. Expect more interesting developments in January after they return to work and, according to the Monday conference call, set a significantly larger staff on the task of shaking money out of Linux users.

Comments (4 posted)

Interview: Public Patent Foundation's Dan Ravicher

The Public Patent Foundation has recently been established for the purpose, as its web site puts it, of protecting "civil liberties and free markets from wrongly issued patents and unsound patent policy by providing those persons and businesses otherwise economically, politically, and socially deprived of access to the system governing patents with representation, advocacy and education."

Dan Ravicher is the patent attorney -- and programmer, incidentally -- who started PubPat, and he is its Executive Director. He was kind enough to answer some questions about patents and the work his organization is doing to educate the public and counter patent abuses. He says he is looking into the Microsoft FAT patents situation and has about a hundred pieces of prior art which were not reviewed by the examiner which they are currently reviewing. Dan was kind enough to answer the following questions.

What made you decide to start your foundation and can you tell us what it does?

If you plan on contesting any patents, can you tell us what patents you have in mind currently? And what would the process involve, from your standpoint?

Should there be software patents at all?

What is the international impact of American patent law on world business?

Computers are extensions of the human brain; computer storage is an extension of human reading and writing; electronic communication is an extension of the human voice. How do you feel about patents which use computers to do things that humans have been doing for millennia?

Comments (1 posted)

Page editor: Jonathan Corbet
Next page: Security>>