|
LWN.net Weekly Edition for December 24, 2003Looking back at 2003 This is the last LWN.net Weekly Edition for 2003, so this is an appropriate time to look back at the last year and ponder what has happened. As a way of maximizing our own embarrassment, we'll start with the predictions we posted at the beginning of the year and see how we did.We predicted:
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).
Johansen wins round two Jon Johansen received an early Christmas present from the Norwegian appeals court in Oslo. Judge Wenche Skjeggestad handed down the unanimous decision of the seven-judge panel Monday, which upheld the lower court's ruling. According to the appeals court, Johansen had done nothing wrong in the creation and distribution of the DeCSS DVD descrambling code, and Norwegian citizens are free to access content and make personal copies of legally-purchased DVDs. While many have been watching the case with interest, it still came as a surprise that the verdict, which was not expected until January, was rendered so quickly.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:
DeCSS makes it possible with simple means to decrypt the encrypted
audio/video-vob files on the DVD discs, and stores them on the PC's hard
disk unencrypted. DeCSS also makes it possible to transmit
audio/video-files over the Internet in unencrypted and unprotected
form. This facilitates duplication of an unlimited number of unauthorized
copes. Consequently, Jon Johansen has contributed to illegal distribution
of movie files stored on DVD discs, or attempted to contribute to such
illegal distribution.
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.
Holiday cheer from the SCO Group The SCO Group has kicked off the holiday season with a couple of new press releases, some interesting disclosures of which code it is claiming, its fourth quarter results, and, of course, the inevitable conference call. This article will look at all of the above, with an emphasis on the company's new copyright claims. Those claims look to be on shaky ground, to say the least.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:
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:
The company is not running Linux binary code that was compiled from
any version of Linux that contains SCO's copyrighted application
binary interface code ("ABI Code") specifically identified in the
attached notification letter.
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.
More SCO cheer Since the above article was published, a few more things have happened on the SCO front...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:
But it shouldn't much matter, since I don't think SCO really is
going to try to claim copyright ownership of the result of standard
C library interactions like using "sys_errlist[]". (I take that
back - _of_course_ they are going to try to claim ownership. After
all, they already claimed ownership of code I provably wrote).
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:
End users have a choice. They can go back to using Linux based on
the 2.2 kernel which includes no infringing code, or they can
continue using SCO's UNIX code as it is being found in Linux and
properly compensate the company for using it.
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.
Interview: Public Patent Foundation's Dan Ravicher While the SCO saga is absorbing our attention in the short term, many are concerned about software patents and they worry that the real test for GNU/Linux will be in the future, from patent lawsuits. There have been numerous patents granted that to programmers seem to have been wrongly issued. The Amazon One Click patent springs to mind. Now Microsoft has announced it will be charging for use of the FAT filesystem, and that too makes some worry.
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?
The patent system is being abused by private actors to the
detriment of
the mostly unaware public. Our health, our freedom, and our economic
prosperity are all under assault from bogus rights meted out to the few
with the power and expertise to game a system originally established
hundreds of years ago to promote progress within society as a whole.
The
government, through primarily a captured patent office utterly failing
to
achieve its mission and skewed policies implement into patent law by
Congress and the courts, is not just failing to defend the public
interest
from abuse of the patent system, but is complicit in and supportive of
such efforts.
In information technology industries, abuse of the patent system means illicit restraint of civil liberties and unjustified disproportionate burdening of small businesses. In life science industries, abuse of the patent system has even more devastating results, including the exacerbation of pain and suffering by those who cannot afford medical technologies covered by undeserved patents. This situation is abhorrent and the Public Patent Foundation is beginning a campaign against such abuses. PubPat's four core activities are (1) challenging patents that threaten the public's health, freedom, or other interests, (2) helping small businesses defend themselves from patents being asserted against them, (3) establishing patent commons within markets crippled by patent thickets, and (4) educating the public regarding these issues and advocating for reform of the patent system.
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?
At the moment we have under consideration several patents,
including
Microsoft's FAT patents, the Optima patent on CD burning, and a patent
on
co-transformation and protein production. Upon completing our review,
there are many ways to neutralize the harmful effects of a patent,
including asking the Patent Office to revoke it and publicizing ways to
avoid infringing it.
To expand on one of the examples above, the Microsoft FAT patents are part of Microsoft's first attempt at building a licensing line of business akin to the one rolled out by IBM several decades ago. This causes concern for us because Microsoft is an admitted monopolist with a proven track record of driving competition from various markets through any mechanism available to it. They may now be focussing on patents as yet another avenue to foreclose competition, including specifically that from free software. Beyond these atmospheric concerns, our analysis of the FAT patents has produced a substantial amount of prior art that was not before the patent office when it issued those patents to Microsoft. For a company with a nefarious past to be seeking revenue for patents that very likely did not deserve to be issued, is a malign scenario indeed. PubPat intends to ensure that the public's interest in being protected from such bahavior is properly represented. Should there be software patents at all?
Many feel passionately about this issue. As a empiricist, I
infrequently
speak in categorical broad-brush terms unless presented with sound data
and
analysis to support a particular conclusion. With respect to software
patents, everyone can agree that none which fail to meet the
requirements of
novelty and unobviousness should be granted or maintained. Beyond
that, I
have grave concerns about the lengthy term of patents being applied to
technologies with short life cycles, especially those with life cycles
shorter than the term of the patent. Such patented technologies never
provide a public benefit, because by time the patent expires, the
technology
is no longer useful.
What is a "wrongly issued patent"? Should patents only be
issued for a demonstrable, produced invention? One thing the Public Patent Foundation is doing is compiling the data and performing the analysis I mentioned above, so that all reasonable persons can be presented with evidence supporting or condemning the policy decision made by the courts that "anything under the sun made by man" is patent eligible.
A patent can be "wrongly issued" for several reasons, including
that the
patent office was not aware of significant prior art during the
examination
process or that the patent office simply made the wrong conclusion
regarding
whether or not the patented technology was new and unobvious. I'm
unsure
what you mean by "demonstrable, produced invention", but the current
standards of novelty, non-obviousness, and reduction to practice are
good
standards. The problem arises from either a lack of evidence on which
to
base a judgment as to whether something is new, unobvious, and reduced
to
practice, or a lack of competency in making those judgments.
Should the inventor state/swear that they intend to use the
patent?
Many countries have patent laws that force a patentee to exploit
her
invention, else it becomes subject to a compulsory license at a minimum
royalty rate. Such a rule is better than what we have in the United
States,
which does not require exploitation of patented technology. At the same
time, however, such a shift may penalize small businesses who may not
have
access to the resources necessary to exploit a certain technology. Such
small player patentees would have their leverage in negotiating a
license
with a larger competitor undercut by the statutory compulsory
license.
It seems like many patents these days involve
"good ideas" which are never implemented by the patent
holder. Should "inventors" of software and/or business
methods be required to provide evidence that they've made the
system work before a patent is granted?
Patent law requires a patent applicant to reduce the patented
technology
to practice prior to applying for the patent; else any patent resulting
from the application is invalid. To reduce a technology to practice,
the
patent applicant must either actually create the technology or describe
it
in such detail that one of ordinary skill in the art with the requisite
resources could create the technology without undue experimentation.
For
instance, if you invent a time machine, but can't afford to make it, you
can still get a patent so long as you tell others how to make it with
sufficient detail such that they can successfully make the time machine
at
least 70-75% of the time. If, however, your instructions are
insufficient
for one of ordinary skill in the art with requisite resources to create
the patented technology at least about 2/3rds of the time, then your
patent is invalid for what is called "lack of enablement."
What about patents granted for obvious methods and technology?
Should a patent be more than a unique design of a
commonplace item such as a document or file?
The law requires a patented technology to be both new and
unobvious. The
crux of your question resides in defining the term "unique." If
something
is "unique" enough that ones of ordinary skill in the relevant art
recognize
it as being a new and unobvious technology, then current patent policy
suggest rewarding the publication of that technology with a patent.
Otherwise, the developer will keep the technology secret and other
members
of society will not be able to learn from and improve upon it.
What is the international impact of American patent law on world business?
First, half of the world's economy takes place in the U.S.. That
fact alone
means that U.S. patent law directly regulates half of all the world's
business. Second, through international treaties, many of the policies
of
U.S. patent law have been adopted and implemented by other countries.
This
results in regulation of business wholly outside the U.S. closely
mimicking
the regulation of business within the U.S..
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?
A patent cannot cover pure functionality; else it is invalid for
indefiniteness. Rather, a patent can only cover specific structure
used to
accomplish a particular function. As such, it is only the structure
that is
patented, not the resulting function. Many people misunderstand this
very
important facet of patent law because sometimes, especially for the most
publicized patents, the structure covered by the patent is the only
known
structure for accomplishing the particular function. This leads people
to
assume that the function itself is patented, which is not the case.
Designing around patents is highly encouraged in patent law, and someone
else is free to learn from the patent and come up with different
structure
for accomplishing the same, or a substitutable, function.
Do you feel that public discussion should be allowed before a
patent is granted? If a patented technology accomplishes a very old function, but with structure that is new and unobvious, then that satisfies the requirements for patentability. Further, one may need to recognize that functions are not necessarily the same simply because their result is the same. For instance, few humans who can do in a day (week, year) the complex calculations machines do today in mere nanoseconds. The function, in that case, is not getting the answer; it is getting the answer in virtual real time, which is something that humans have never done.
Public comment on patent applications prior to issue is an idea
with some
merit. Such is the law in many foreign countries, and recently the
patent
office abolished its prohibition on receiving third party correspondence
regarding patent applications. However, if the process of pre-issuance
public discussion includes a mechanism for third parties to delay the
patent
application from issuing, that mechanism might become unjustifiably
abused
and manipulated, particularly by larger corporations who can afford to
"hold-up" a smaller companies "crown jewel patent."
Page editor: Jonathan Corbet Security Security news Linux security in 2003 Here in the free software world, we had no shortage of security problems in 2003. Vulnerabilities were announced in many packages, including (but not limited to) apache (several), balsa, bind, bugzilla, cdrecord, cfengine, cron, cups, cvs, ethereal (many), evolution, exim, fetchmail (many), fileutils, gdm, ghostscript, glibc, gnupg, gzip, hylafax, inetd, iproute, KDE, kerberos, kernel (several), lprng, lsh, lynx, mailman, man, mozilla, mpg123, mplayer, mutt, MySQL, openssh, openssl (several), perl, pine, PHP, postfix, PostgreSQL, proftpd, python, rsync, samba, screen, sendmail, snort, stunnel, sudo, tcpdump, vim, webmin, wget, wu-ftpd, xchat, XFree86, xinetd, xpdf, and zlib. All told, 304 entries were added to LWN's vulnerability database in 2003. Needless to say, that is far too many - and it does not count all of the problems which were silently fixed without going though a security alert process. As a community, we have to strive to do better in 2004. For all that we believe Linux and free software are more secure, there is no doubt that they are not, yet, secure enough.The truly worrisome security trend in 2003, however, is the increasing level of attacks on the community's infrastructure. Servers were compromised at the GNU Project (twice) and the Debian Project (multiple servers in one incident). A mirror server for the Gentoo distribution was also broken into. There was also a compromise of the kernel's CVS server and an attempt to insert a trojan horse into the kernel itself. None of these attacks ended up with compromised code being made available to users, but most of them could have been exploited in that way. Maybe these are all just random attacks (though an attempt to trojan the kernel can only be so random), or maybe somebody is making an attempt to mess with the server structure which holds this community together. Either way, chances are that, eventually, one of these attacks will succeed in causing serious damage, far beyond the service disruptions and lost time we have seen so far. The real lesson from 2003 is that there really are people out there with evil intent, and they are looking our way.
New vulnerabilities ethereal: protocol dissector and other vulnerabilities
irssi: remote denial of service
Updated vulnerabilities 2.4 kernel - several vulnerabilities
CUPS: denial of service
Net-SNMP: security bugs in versions before 5.0.9
Multiple-use vulnerability in Safe.pm
apache: buffer overflows in mod_alias, mod_rewrite
apache2: Denial of Service vulnerability
bind: cache poisoning
cvs: unauthorized file creation
ethereal: multiple remote and local vulnerabilities
Filename disclosure vulnerability in fam
fetchmail may crash on specially crafted message
fileutils/wu-ftpd: denial of service
glibc: DNS stub resolvers contain buffer overflow vulnerability
GnuPG: ElGamal signing keys compromised
gtkhtml: malformed messages cause crash
iproute: local denial of service
KDE: Two issues in KDM
kernel: local root exploit in 2.4.22
kernel-utils: setuid vulnerability
lftp buffer overflows
libnids: remotely exploitable buffer overflow
libpng, libpng3: buffer overflow
mikmod: buffer overflow
mpg123: heap overflow
mplayer: remotely exploitable buffer overflow vulnerability
Nessus NASL scripting engine security issues
nfs-utils xlog() off-by-one bug
openssh: timing attack leads to information disclosure
postfix: denial of service vulnerabilities
proftpd: remote root shell
rsync - remotely exploitable heap overflow
sane-backends: several vulnerabilities
screen: privilege escalation
File overwrite vulnerability in tar and unzip
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||