It 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
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,
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
Comments (10 posted)
The Committee for Economic Development
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
) 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
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,
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
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
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
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
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
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:
- No quick legislative schemes. The report proposes a two-year
moratorium in legal "fixes" while a broader consensus on digital
copyright protection is worked out.
- A high priority should be placed on the development of new business
models around creative content. There should be no legal protection
for any particular business model.
- Existing enforcement and education efforts should continue. In
particular, the industry should use the legal tools it has against
- Despite the report's criticism of DRM systems, it recommends that DRM
efforts should continue, but that such systems must respect the fair
use and first sale rights of users. The report suggests that the DMCA
anti-circumvention clause should be reconsidered.
- There should be "economic incentives" for copyright holders to
facilitate further use of their works. Compulsory licensing is one
idea mentioned in the report. It should also be easier for works to
enter the public domain; the report mentions the idea of requiring
periodic, low-cost renewals to keep copyrights in force.
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.
Comments (15 posted)
The 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
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"
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
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
Comments (7 posted)
Page editor: Jonathan Corbet
Next page: Security>>