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 March 4, 2004This week's SCO funIt has been a busy week for people watching the rapidly growing set of SCO cases. Here we will try to summarize the current state of affairs.The company announced its first-quarter results, which were just as bad as had been expected. SCO's revenues are down almost 20% from one year ago, and the reported loss is $2.3 million. The actual loss, however, was $5.2 million; some residual accounting weirdness in the BayStar deal allowed SCO to paper over the difference. SCO will not be able to use that trick in the future, however; instead, the restructuring of the BayStar deal will likely force the reporting of a significant loss in the second quarter. The end result is that SCO is not making any money. The Unix business is dying, helped along by SCO's "sue your customers" business model. The company has only managed to sell "a handful" (Darl McBride's word) of "Linux licenses" - $20,000 worth in the first quarter. The company's stock has fallen to about half of its peak value ($22.29, last October). Things are not looking good for the SCO group. In such a situation, the quarterly conference call did not look like it would be much fun for SCO's management. So it was time to set up a diversion. That diversion came in the form of two new lawsuits - the long-promised end-user suits, sort of. The first is against AutoZone, a former SCO customer which switched to Linux. SCO claims "AutoZone violated SCO's UNIX copyrights by running versions of the Linux operating system that contain code, structure, sequence and/or organization from SCO's proprietary UNIX System V code in violation of SCO's copyrights." The actual complaint (available as an 8-page PDF file) is surprisingly vague; the core of the suit can be found in two paragraphs:
On information and belief, parts or all of the Copyrighted Material
[Unix] has been copied or otherwise improperly used as the basis
for creation of derivative work software code, included one or more
Linux implementations, including Linux versions 2.4 and 2.6,
without the permission of SCO.
Defendant has infringed and will continue to infringe SCO's copyrights in and relating to Copyrighted Materials by using, copying, modifying, and/or distributing parts of the Copyrighted Materials, or derivative works based on the Copyrighted Materials in connection with its implementations of one or more versions of the Linux operating system, inconsistent with SCO's exclusive rights under the Copyright Act. In the IBM case, SCO has alleged that IBM helped AutoZone misuse SCO's Unix shared libraries on Linux. When dealing directly with AutoZone, however, that claim has gone away. The complaint as a whole looks like a desultory effort, not something that was months in the making. The second suit is against DaimlerChrysler. In this case, SCO is picking on a Unix licensee which has refused to answer SCO's "compliance certification" demand from last December. This suit is not directly related to Linux, yet; SCO is just trying to force compliance with a Unix license clause (allegedly) giving SCO the right to demand this sort of certification. Darl McBride admitted in the conference call that less than half of the recipients of the demand letter have responded to it. Conceivably, SCO might actually have a case here - but it has little to do with Linux users. SCO did announce one new SCOsource customer: EV1Servers.Net. This company (formerly RackShack) bought a license to cover its 20,000-some Linux servers. EV1Servers claims that it is just trying to protect its customers, but quite a few of those customers have been rather vocal in their discontent. Surely EV1Server.Net's appearance in this Microsoft case study last September is purely coincidental. The Novell case is currently waiting for SCO's response to Novell's motion to dismiss the case. SCO has asked for more time (until March 5) to put together this response; Novell has indicated that it will not oppose that request - but only as long as SCO files no other motions during that time. In this way, perhaps, Novell will be able to get quick consideration of its motion without being slowed down by the usual SCO delaying tactics. In the IBM case, the long-awaited ruling on the various motions to compel discovery has finally been issued; we have it in PDF format. Both sides are ordered to come up with a lot of stuff. SCO is told to be very specific about what lines of code it's complaining about, and also "the lines of code that SCO distributed to other parties." IBM has to come up with a lot of AIX and Dynix code, and to talk more about its Linux contributions. The ruling does not appear to be a clear victory for either side. The Utah court also allowed SCO to amend its complaint against IBM, deleting its trade secret claims and adding copyright violation claims. IBM had not contested this change, so there was no real reason for the court to turn it down. The Red Hat case is still waiting for the judge to rule on SCO's motion to dismiss. This ruling should be easy; SCO, remember, claimed that it was not threatening Red Hat or its customers. Red Hat had plenty of evidence to the contrary already, but the fact that AutoZone was a Red Hat customer has clarified the situation even further. In Australia, CyberKnights has taken the next step and filed a formal complaint with the Australian Competition and Consumer Commission. The ACCC has already been sitting on one complaint; time will tell if the second complaint results in action. In Germany, SCO reached an out-of-court settlement with Univention stating that SCO will refrain from making claims against Linux without evidence. It is a minimal agreement which does little to truly shut the company up, however. Increasingly, the SCO story looks as if it is entering the final chapters. Regardless of how many more suits the company files, it appears unable to halt the decline of its stock price and of how the company and its claims are perceived (the questions at the latest conference call were rather less friendly than in the past). SCO, by all appearances, is going down; unfortunately, the company may well be able to make quite a bit more trouble before its story ends.
The Committee for Economic Development on digital copyrightThe Committee for Economic Development is a 60-year-old pro-business think tank. This group has recently dedicated some of its resources to the problems associated with intellectual property rights in a digital setting. The resulting report could easily have become another rabid missive on the evils of "piracy" and the need for heavy governmental involvement. But the CED took a different approach. The report (available as a 100-page PDF file) takes a surprisingly broad view of the situation. It contains little that is truly new for people who have been following the situation, but it does show that the business community is beginning to figure out that there is more to think about than the entertainment industry's immediate complaints.The introduction talks about the challenges posed to publishers by ubiquitous computers and high-speed networking. It notes that sales of audio CDs have dropped significantly, but also discusses a number of (non-piracy) reasons for why that is happening. Movie sales, in contrast, are better than ever; bandwidth limitations have something to do with that, but the fact that movie customers feel they are getting their money's worth also is relevant. Potential responses to unwanted copying of copyrighted materials are discussed. The report notes, however:
New business arrangements have consistently emerged in response to
new technologies. Over the long term, the creators of advances in
science and the arts have profited from advances in new production
and distribution technologies. And attempts to protect existing
production and distribution arrangements by law have failed.
The report then goes into a detailed history of copyright law. The authors are clear on the fact that the real purpose of modern copyright law is to promote artistic and scientific advancement; the provision of certain monopoly rights to copyright holders is simply a means to that end. It is often repeated that creators of copyrighted materials rely heavily on work that was done before; there is little that is truly and completely original. The importance of fair use rights and the public domain is discussed several times. There is a discussion of responses to piracy which covers most of the usual topics: the DMCA, various other legislative efforts (broadcast flag, the CBDTPA), enforcement actions, digital rights management schemes, etc. The authors are not enthusiastic about legislative "solutions" to the problem; they see laws like the DMCA and state "super DMCA" proposals as anti-competitive, inimical to fair use rights and the public domain, and ineffective. Among other things, they point out that legally-required copy protection schemes can enshrine weak technology and inhibit the development of stronger alternatives. The report has little good to say about digital rights management (DRM) systems. For starters, DRM systems usually fail in the long term; once a DRM system has been broken, the exploit code can be spread far and wide over the net. DeCSS is used as an example - and the authors even note that DeCSS was created to play DVDs on Linux systems rather than as a piracy tool. Privacy issues with DRM systems are mentioned. The report talks about the innovation which has resulted from the widespread dissemination of general-purpose computers, and how legally-mandated DRM threatens to put an end to that. There are a few paragraphs dedicated to the effect on free software:
The role of open source software is being systematically ignored in
many of the proposals under discussion in this report, and
particularly in the broadcast flag context. Open source software
is increasingly important as a source of innovation; it can be
far more reliable and secure than proprietary software because
talented programmers around the world can examine the code and try
to break its security, without having to worry about hidden
backdoors or holes. Yet such examination and the resulting
improvement appears incompatible with a prohibition on tampering.
There are also societal costs to be paid. Widespread use of DRM systems threatens the public domain and fair use rights, and will thus inhibit further development.
We grant limited privileges to creators because we want them to
create and to share their works for the benefit of society as a
whole, not in order to give them total control over how their works
are used. The central problem with broad use of DRM is not that
software code will be regulating users, but that content creators
will be unilaterally regulating private uses of content and
controlling the course of subsequent innovation.
Almost every innovation is "subsequent" to many others, and, as the authors point out, this subsequent innovation is usually done by new, unrelated creators. Allowing creators to choke off subsequent works will thus result in fewer works being created, which is contradictory to the original purpose of copyright protection. The biggest complaint that the authors have with DRM, however, would appear to be the fact that such systems shift copy protection costs from copyright holders to consumer electronics manufacturers and users. Finally, the report points out that oppressive DRM (and rights enforcement in general) is bad for the social contract which holds the whole system together:
The existence of private license agreements containing
"unreasonable" terms -- terms inconsistent with shared values --
undermines the societal interest in self-enforcing contracts. The
self-enforcement aspect of private agreements is essential; after
all, voluntary compliance with private agreements is what makes a
society livable. If we create a world where license terms do not
appear to represent a fair bargain, and are contrary to shared
values, we are likely to have built a world where there is little
inclination for voluntary compliance and much delight taken in
rule-breaking. Such a world will be filled with obtuse letters
threatening dire legal consequences, or (more likely) widespread
remote disabling of the machines upon which we rely.
One might well argue that we have already proceeded far down that path. The report concludes with a set of recommendations:
For those of us who are concerned about ever-increasing copyright terms, criminal charges against software developers, and the lack of ability to use and control our computers as we see fit, this report will fall short of what we would like to see. It is, however, a clear sign that the wider business community is starting to become aware of the costs of unrestricted copyright rights. We are seeing the beginning of a real debate where, before, there was only the illusion of consensus. That can only be a step in the right direction.
FreeS/wansongThe FreeS/WAN project is winding down after five years. For those unfamiliar with the project, FreeS/WAN was created by John Gilmore, who has contributed more than his share to the Internet era. He helped create the "alt" newsgroups, co-founded the Electronic Frontier Foundation and Cygnus Solutions (now part of Red Hat), and has contributed to a number of other important projects.FreeS/WAN was designed to provide a Secure Wide Area Network (S/WAN), and has been widely used to deploy IPSec Virtual Private Networks (VPNs). But Gilmore was looking to go beyond VPNs with FreeS/WAN and to push the concept of Opportunistic Encryption (OE). The idea behind OE was to provide software that would encrypt packets, without intervention from the user, when communicating with machines that support encryption. Using OE, a FreeS/WAN machine would automatically create an ad hoc Virtual Private Network (VPN) when encryption was available at both ends, and send data in the clear when encryption was not available. Either way, the operation would be transparent to the user. Gilmore was optimistic that OE would offer the "fax effect" for encryption:
As each person installs one for their own use, it becomes more valuable for
their neighbors to install one too, because there's one more person to use
it with. The software automatically notices each newly installed box, and
doesn't require a network administrator to reconfigure it. Instead of
"virtual private networks" we have a "REAL private network"; we add privacy
to the real network instead of layering a manually-maintained virtual
network on top of an insecure Internet.
Gilmore wanted to secure 5% of Internet traffic against passive wiretapping by 1999, and eventually all communications on the net. Perhaps someday FreeS/WAN, or similar software, will drive widespread adoption of encrypted communications. But users have been slow to utilize FreeS/WAN for OE, even within the Linux community. FreeS/WAN has been popular for setting up VPNs, but OE just hasn't caught on in a big way. This is one of the FreeS/WAN project's stated reasons for quitting:
Nine months after the release of FreeS/WAN 2.00, OE has not caught on as
we'd hoped. The Linux user community demands feature-rich VPNs for
corporate clients, and while folks genuinely enjoy FreeS/WAN and its
derivatives, the ways they use FreeS/WAN don't seem to be getting us any
closer to the project's goal: widespread deployment of OE. For its part, OE
requires more testing and community feedback before it is ready to be used
without second thought. The project's funders have therefore chosen to
withdraw their funding.
Gilmore also wanted to challenge U.S. crypto export regulations with FreeS/WAN, and barred U.S.-based developers from contributing code to the project. While there have been some small victories, including the U.S. government's retreat in the Bernstein case (which Gilmore was heavily involved in), the ability to export strong cryptography from the U.S. is far from guaranteed:
After the watershed Bernstein case, US export regulations were
relaxed. Since then, many US companies have exported strong cryptography,
without seeming restriction other than having to notify the Bureau of
Export Administration for tracking purposes.
This comfortable situation has perhaps created a false sense of security. The catch? Export regulations are not laws. The US government still reserves the right to change its export regulations on short notice, and there is no facility to challenge them directly in a court of law. This leaves the US crypto community and US Linux distributions in a position which seems safe, but is not legally protected -- where the US government might at any time *retroactively* regulate previously released code, by prohibiting its future export. This is why FreeS/WAN has always been developed outside the US (in Canada and in Greece), and why it has never (to the best of our knowledge) accepted US patches. It probably shouldn't be surprising, then, that FreeS/WAN suffered from lack of community support. The decision to exclude U.S.-based developers from working on FreeS/WAN meant that many kernel developers, including Linus himself, would be unable to contribute to the project. But while U.S.-based developers were barred from contributing to FreeS/WAN, they were not barred from working on other implementations of IPSec. The 2.6 kernel now includes an IPSec implementation of its own, negating the need for an add-in implementation like FreeS/WAN. Though the FreeS/WAN project is ending, the situation is not as dramatic as it sounds. No open source application is dead if the community does not wish it so, and FreeS/WAN will live on for some time after the last official release. The FreeS/WAN team plans to push out at least one more release, including changes to allow its use with the 2.6 kernel series. Openswan, a fork of the FreeS/WAN project, seems poised to continue development where FreeS/WAN leaves off. Linux users are not being left out in the unencrypted cold. The code remains, and development of IPSec VPNs for Linux continues without a hitch. At some point, we may even realize Gilmore's goals of a fully-encrypted Internet.
Page editor: Jonathan Corbet Inside this week's LWN.net Weekly Edition
|
|||||||||||||