When SCO launched its SCOsource initiative one year ago, it must have known
that it would encounter resistance at some point. Even so, the SCO Group
may not have expected Novell to emerge as one of its largest obstacles.
But Novell has done exactly that. Novell has disputed SCO's claims to the
Unix copyright (and submitted copyright registrations in its own name),
initiated audits of SCO's Unix licensing activities (with an eye, perhaps,
on a 95% cut of the money from Sun and Microsoft), claimed - and exercised
- the right to override SCO's actions against IBM and others, and acquired
a Linux distributor of its own.
As a result of Novell's actions, even the most weak-willed corporate
officer will have to think twice about
buying a "license" from SCO. Said officer may not
feel capable of deciding whether SCO's claims have merit, but a disputed
copyright is easy to understand. SCO's chances of prevailing on its claims
are minimal even in Novell's absence, but Novell's entry into the game
makes those claims moot for now. Given that, SCO's lawsuit
against Novell is not particularly surprising. It was, instead,
inevitable. SCO had to make a show of getting Novell out of its way.
SCO's full complaint is available as an 11-page PDF file. It
is, in fact, a relatively straightforward suit, the sort of thing one would
expect to see from a company which feels that its copyrights are being
stolen in plain sight. It states that Novell has laid claim to the Unix
copyrights, that it has made statements with the intent of causing people
not to do business with SCO, and has damaged SCO's reputation and
business. All of these claims are demonstrably true. Of course, SCO also
states that Novell's copyright ownership claims are false, which is not so
clear.
SCO is asking the court to find that the copyrights belong to SCO; force
Novell to pay actual, special, and punitive damages; issue preliminary and
permanent injunctions requiring Novell to assign copyrights and cease
claiming to own those copyrights; and to make Novell retract its past
claims.
Given that the relevant
purchase agreement is available online, one would think that
understanding what SCO really bought would not be that hard. In
fact, the agreement is written in a sort of obscure legalese that would
appear to invite misunderstandings and lawsuits from the beginning. To try
to figure out what SCO bought, you have to read through to the very end;
the assets to be transferred are listed in schedule 1.1(a):
All rights and ownership of UNIX and UnixWare, including but not
limited to all versions of UNIX and UnixWare and all copies of UNIX
and UnixWare (including revisions and updates in process), and all
technical, design, development, installation, operation and
maintenance information concerning UNIX and UnixWare, including
source code, source documentation, source listings and annotation,
appropriate engineering, notebooks, test data and test results, as
well as all reference manuals and support materials normally
distributed by Seller to end-users and potential end-users in
connection with the distribution of UNIX and UnixWare...
This paragraph provides a lengthy list of things to be transferred to SCO,
but "copyrights" does not appear on that list. So it would be up to a
court to decide whether "all rights and ownership" include copyrights or
not. SCO claims that the issue was clarified in Amendment 2
to the agreement, which revises Schedule 1.1(b). That section lists the
things which were not sold to SCO; the wording was changed to read:
All copyrights and trademarks, except for the copyrights and
trademarks owned by Novell as of the date of the Agreement required
for SCO to exercise its rights with respect to the acquisition of
UNIX and UnixWare technologies. However, in no event shall Novell
be liable to SCO for any claim brought by any third party
pertaining to said copyrights and trademarks.
This language suggests that some copyrights would be transferred to
SCO, but does not actually list those copyrights in any way. In summary,
it is a messy agreement that will require a court to sort out.
The interesting thing is that SCO has not actually asked the court to sort
it out. Regardless of what the agreement really says, one thing is
strikingly clear: Novell has not actually assigned any copyrights to SCO.
Novell might have signed a contract obligating it to assign
copyrights to SCO, but SCO agrees that said assignment has not happened.
Given that, SCO really needed to file a breach of contract suit to force
Novell to live up to (what SCO sees as) its obligations. SCO's lawyers
certainly know this; one wonders
what they are really trying to accomplish.
More to the point, however, one might well wonder whether the end result of
this suit matters to Linux users in the first place. In fact, this action is a
significant development in the wider SCO affair. If Novell prevails, SCO's days of
threatening Linux users will be done, and that would certainly be a good
thing. The IBM case, which has nothing to do with copyrights, might
continue, but it would be an isolated contract dispute. All Linux
users would have to worry about at that point is what Novell intends to do
with its newly-defended copyrights. As we have said before, Novell owes
the community a statement regarding its intentions.
If SCO prevails - with an amended complaint bringing up the contract issue,
presumably - Linux
users would find their position unchanged. SCO would still have to prove
that Linux contains its copyrighted code, something it has not done in any
convincing way so far. It is increasingly apparent that, in fact, Linux
contains no significant amount of copyrighted Unix code. So a Novell
defeat would not really set back Linux users in any way.
It seems fairly clear, however, that no court will allow an SCO-initiated
copyright suit to proceed until the Novell case is resolved. Until then,
SCO's threats against users are even emptier than before.
Meanwhile, SCO has completed a
new S-3 filing updating its "risk factors" to include a few marginally
relevant items, like Novell's copyright claims. The fact that SCO has
known about these claims for several months but only now updated its
regulatory filings could come back to haunt it later on. Groklaw has put
together a nice
table of differences between the old and new filings; it paints a grim
picture of where things are going with SCO. Worth a read.
The new S-3 also discusses the strange accounting required by the BayStar
investment. For each $1 drop in the company's stock price, SCO must record
approximately $1 million in income. Don't be surprised if this
phantom income somehow pushes the company into a paper profit in future
quarters.
Red Hat has made a fair amount of noise about its new Open
Source Assurance Program, which is automatically extended to all
Enterprise Linux customers. The program, however, does not offer very
much: it states that any code in Red Hat Enterprise Linux which is found to
infringe upon intellectual property rights will be replaced. For users who
fear, say, a patent problem, this warranty will be a comforting thing to
have. It does not go far beyond what the community would do anyway,
however.
Finally, it would appear that the SCO Group has sent a letter to the
U.S. Congress (available in PDF format)
describing the evils of free software. Among other things, it will destroy
the U.S. economy and provide vital computing capabilities to America's
enemies. And create some business discomfort for the SCO Group, of
course. The letter is an impressive bit of work, worth a read. If you
are an American citizen, you may want to consider writing a letter yourself
to counter SCO's claims. The fact of the matter, however, is that SCO is
unlikely to be able to out-lobby companies like IBM and HP.
Comments (13 posted)
Your editor is back and rested - if somewhat jet lagged - from the 2004
![[Not a developer]](/images/ns/lca/didg-sm.jpg)
production of
Linux.Conf.Au in
Adelaide. Some 540 people attended this event -- the highest attendance
in this conference's five-year history.
Here's a quick summary of what happened as seen by LWN.
Greg Ungerer gave an introductory talk on uClinux which will be
interesting to those who haven't actually looked at how this kernel (which
runs on systems without a memory management unit) works. Modern uClinux
supports a vast number of architectures, and will run on systems with as
little as 1MB of memory (though "you can't do much" on such a system).
There's a few little things missing, of course: virtual memory support, the
fork() system call (vfork() works), no dynamic stacks, no
sbrk(), etc. And, of course, nothing protects the system and
applications from each other. Even so, making applications work on uClinux
is usually not a particularly big deal. Future plans for uClinux include
supporting more hardware, adding to the list of ported applications, and
integration with the RTAI real-time system.
Running device drivers in user mode was discussed by Peter Chubb.
This topic will get a more detailed treatment on this week's Kernel Page.
Your editor has come to the conclusion that Jon 'maddog' Hall serves
as a mutual exclusion mechanism for Linux conferences. Since he,
inevitably, shows up at every Linux event, his scheduling constraints serve
to keep multiple conferences from happening at the same time. In Adelaide,
he discussed the differing expectations of developers, users, and
managers. Among other things, he predicted that 2004 will be the year when
the Linux desktop truly begins to take over. Maddog's talks are invariably
fun to hear.
Greg Lehey discussed his Vinum
volume manager. Vinum runs on FreeBSD and NetBSD, but a Linux port is in the
works. It provides many of the usual features: disk concatenation and
striping, along with implementations of the various RAID levels. Among
other things, Vinum was intended to be easy to configure via a relatively
straightforward text file. As Greg noted, however, "pilot errors" remain
possible.
Bdale Garbee gave a wide-ranging talk covering a number of topics.
The core of the discussion, however, had to do with truly large-scale Linux
deployments, such as those which have happened in Extremadura (Spain), and
in Brazil. He notes that Linux has become an obvious first choice for
publicly-sponsored computing initiatives in many parts of the world -
especially the less rich areas. Use of Linux allows greater control,
doesn't require sending large amounts of hard currency to the United
States, and can help in the creation of local information technology
expertise. Bdale also noted, with visible pleasure, that the Debian
distribution (or a derivative thereof) tends to be chosen for this sort of
project. He sees Debian as embodying many of the free software community's
core concepts and being appealing for its essential openness.
Havoc Pennington touched on some similar concepts with his "state of
the Linux desktop" keynote. He repeatedly pointed out that, to achieve
true success on the desktop, the free software community must focus on what
it does best, rather than trying to imitate current proprietary offerings.
For example, since any interested party can add to free software and influence its
development, the very best translation and accessibility
support tend to be found in free systems. Many languages and user
communities are too small to be worth supporting for a proprietary software
company, but the users themselves don't care about that. Then, there are
projects like Dashboard and
GNOME Storage (among many others) which show that anybody can pursue interesting
ideas; if others like the results, those ideas will be enhanced by others
and eventually
incorporated. For this reason, it is important that the Linux desktop
remains 100% free software; as soon as proprietary components start to
appear, the advantages of free software are lost.
His call to go beyond imitation notwithstanding, Havoc is clearly very
focused on where Microsoft is headed, especially with the forthcoming
"Longhorn" release. He says that the delays in Longhorn give Linux a
window of opportunity to step in (especially since moving to Longhorn
looks like it will be no easier than switching to Linux), but we have to be
aware of the sort of features Longhorn will offer and have something which
will be a competitive alternative.
Jeff Waugh gave a high-energy talk on the GNOME project. His focus
was on the decentralized nature of the project, the increasing number of
developers, and the tightly-run six-month release schedule. He talked of
some trends in GNOME development (the new "evolution data server" which
will provide contact and calendar information; embracing of
standards and code coming out of FreeDesktop.org; the commitment to ABI
stability across GNOME 2.x, etc.) but it seems that nobody really
knows what future GNOME releases will bring. The one sure thing, according
to Jeff, is "we will rock you."
Beyond the talks, this conference included a well-developed
"partners program" for the families of attendees, dinner events put on by
IBM and Oracle, and the now-famous dunk tank. The break area lacked
coffee (by American standards, anyway) but made up for it in free ice
cream. The venue was beautiful; Elder Hall with its woodwork and pipe
organ is far superior to the typical conference ballroom. And the whole
event was suffused by an Australian sense of humor and fun.
Also worthy of note
was the "Miniconf" program which ran for two days before the main event
(and which, unfortunately, your editor was unable to attend). The Linux and Open Source in
Government miniconf, in particular, seems to have brought out many
themes which resonated through the rest of the event.
In summary; Linux.Conf.Au was a great success. It was, as intended,
a seriously fun gathering with much talk about the technology and no
marketing. Let it never be said that volunteers cannot bring off a
complex event of this type. Linux.Conf.Au is more volunteer-driven than
most; it is run by a different committee in a different city every year.
Despite the talk of heroic, last-minute, all-nighters put on by the
conference staff, the attendee experience was smooth and seamless.
Linux.Conf.Au came off better than many events run by "professionals."
Great congratulations are due to the dedicated group of people who pulled
this off.
LWN would like to thank HP one last time for making our presence at
Linux.Conf.Au possible.
Comments (4 posted)
You know that spam prevention efforts have reached fever pitch when a spam
conference brings together lawyers, developers, economists, Eric Raymond
and a representative from Microsoft to discuss the problem and ways
to stop it. MIT hosted a conference on this topic on January 16, and we
decided to
check out the webcast to see what kind of work is being done in this area.
The answer is, there's quite a bit of work going on, and the future
looks much more encouraging than you might think.
Lawyers Jon Praed and Matthew Prince both spoke about spam from the legal
perspective. Praed discussed experiences in suing spammers. Interestingly,
Praed wasn't as negative about the recent CAN-SPAM Act as many in the
anti-spam community have been. Praed noted that legal solutions can often
do something that technical solutions alone have failed to do:
significantly drive up the cost of sending spam by requiring spammers to
deal with legal bills. He also said that 2003 was a banner year for legal
efforts against spam, because it brought the first arrests solely for
spamming. According to Praed, the CAN-SPAM Act is effective, in that it
makes it clear that spamming in and of itself is a crime.
Prince was less enthused with CAN-SPAM. Prince pointed out that 37 state
spam laws have been passed prior to CAN-SPAM; now all 37 are
pre-empted by federal law, which is weaker than most of the state
laws. But even the stronger state laws have
been largely ineffectual for stopping spam. He also noted that spam laws
were not based on the volume of spam, which is the problem we now face, but
were written to counter the problem of fraud in spam.
Prince did bring up the McCain amendment to CAN-SPAM for praise, and said
it had received almost no coverage. Essentially, the McCain amendment says
that when prosecutors are going after a spammer, they don't necessarily
have to go after the sender. It allows prosecutors to attach liability to
advertisers, which may be much more effective than having to go after the
spammer.
Prince also said that we would have to remove anonymity of email to solve
the legal problem of spam. Washington has been the most successful because
its law includes a registry of
email addresses that are located in the state of Washington.
He said that it was necessary to
establish a national do-not-spam registry which would establish
jurisdiction to allow spammers to be sued and prosecuted.
Both Prince and Praed agreed that the important thing about legal solutions
is that they impose costs on spammers.
Yahoo's Miles Libbey talked
about trends in spam, as seen passing through Yahoo Mail. Like many other
speakers, Libbey saw a emerging emphasis on spammers trying to hide their
identity, and attempting to make messages more random to avoid filters. On
a scary note, Libbey said that Yahoo! had found that spammers had reacted
to their anti-spam filters within a space of two hours.
Another presentation focused on finding economic means to deal with
spam. Thede Loder, Marshall Van Alstyne, and Rick Wash outlined the
Attention Bond Mechanism (ABM) where senders would have to put up a "bond"
where users could charge the sender a sum of money for unwanted messages or
release the money if the message was wanted.
Assuming a working model could be found and implemented, they say this
would be of benefit to users and marketers. According to Loder, Van Alstyne
and Wash, it could be cheaper than direct mail, while giving the recipient
an incentive not to block the email automatically. Either the message would
be of benefit to the user, or the user could reap a small financial gain by
accepting the message. Most importantly, this model would return the
control of a user's inbox to the user where it belongs and shift the burden
to marketers.
Along the same lines, Eric Johansson of CAMRAM talked about a hybrid system that
would add a money-free sender-pays type of system incrementally to
email. Instead of being a money-based system, the stamp creation would be
time-based. That is to say, that each "stamped" email would contain a
22-bit or 23-bit stamp that costs a given amount of time to
generate. Adding that amount of time to generate each email would be
somewhat prohibitive for spammers, as spammers need to send email in volume
to make money.
Of course, there were also many discussions of technical means to filter
and block spam. William Yerazunis spoke about ways to go beyond the
accuracy of Bayesian and Markovian spam filtering. One interesting note
from Yerazunis' talk is that he noted that some spammers are getting
desperate enough to actually sign up for "well-credentialed" email lists in
an effort to penetrate those lists and send spam to the mailing list
members. He also noted that the "Habeas
Haiku" method of whitelisting mail has actually become an
indicator of spam rather than an indicator that the email is clean,
as spammers have been brazenly using the Haikus in their spam.
Marty Lamb spoke about Martian Software's TarProxy, or "creating
pain for spammers." TarProxy is a method for throttling connections between
the spammer and an SMTP server by slowing the rate at which a spammer can
send spam, and thereby make it more costly. It also would cause headaches
for administrators of open relays, with the eventual goal of forcing them
to fix the configuration of their server.
Jonathan Zdziarski managed to present two topics in the allotted 20 minute
space. Zdziarski spoke about using "chained tokens" to provide more
information when filtering spam, rather than using a single word as a
token. The "chained token" technique basically works on the concept that it
is easier and less risky to identify spam by multiple words or tokens
rather than a single word or token. Tokens can include mail headers, HTML
fragments and other bits of an e-mail. A white paper discussing the
technique can be found on the DSPAM website in
PDF.
Zdziarski is also working with Bill Yerazunis on an RFC for MIME
Encoding for message inoculation, create a message format that allows
different spam filters on different servers to share inoculation
information.
John Graham-Cumming taped his
presentation beforehand. Instead of discussing how to block spam,
Graham-Cumming's presentation focused on how spammers could beat spam
filters by using filters like POPFile to detect "good" words to get through
a spam filter. Graham-Cumming predicts that spammers will continue to react
to adaptive filtering, and said that it would be possible for a spammer to
insert "web bugs" into spam to help train filters to see which messages are
delivered and which are not. Graham-Cumming said that it would be necessary
to choke off feedback to spammers, such as bounces and SMTP error messages,
to prevent adaptive filtering to work against spam filtering.
Eric Raymond was also on hand at the conference, and spoke about several
topics. One topic Raymond discussed is a provision in the CAN-SPAM Act that
requires the Department of Commerce to consult with the IETF on
spam-labeling standards. While the CAN-SPAM Act directs the department to
consult with the IETF on this issue, the IETF does not have any labeling
standards at the moment. Raymond says he is working on a draft RFC that
could "pass constitutional muster" that could be used.
Raymond also discussed Sender Permitted
From (SPF). SPF allows a server to query whether something is a valid
IP address, and to set policies based on that information. To use SPF, you
add information to DNS that informs the world which IP addresses are valid
for sending e-mail from your domain. When spammers attempt to spoof "from"
headers and so on, a server using SPF can check to see whether or not the
IP addresses match the valid IP addresses listed in DNS records.
Raymond admitted that there are compatibility problems with SPF. For
example, SPF breaks forwarding and causes problems for roving users who
need to send mail from different IP addresses. He noted that no one
technology for stopping spam is perfect, but several tactics can work
together as a "drug cocktail" to help end the spam problem.
For those interested in attending an anti-spam conference before MIT's 2005
conference, several speakers plugged the First Conference on Email and Anti-Spam
(CEAS), which is scheduled for July 30 and 31 in Mountain View,
California. For those working on anti-spam technologies or in related
areas, there is a call for papers
with a deadline of April 16.
The full presentations from the MIT conference are available in RealPlayer
format at the Spam
Conference website.
Comments (7 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Linux cryptoloop weakness; New vulnerabilities in kdepim, mc, netpbm, qmail, ...
- Kernel: User-space device drivers; Shrinking the kernel; FUSYNs.
- Distributions: GoboLinux - Fun with File System Hierarchy; Spawn of Debian reviews
- Development: The Bochs x86 PC Emulator,
new versions of ZODB, Sendmail, Gimp-Print, PyKota, Sussen,
Dasher, GNUsound, Visecas, Passepartout, TeXmacs, PyQt, DOSEMU,
Balsa, Gnumeric, Epiphany, Mozilla, Perl, GSview.
- Press: New spam fighting technique, open-source awards, Eclipse splitting from IBM,
Oracle pushes Linux, Linux in entertainment systems.
- Announcements: linuxaudio consortium, Open Ireland, LinuxWorld announcements,
linuxmusician.com.
- Letters: Happy Birthday LWN; What is SCO selling?
Next page:
Security>>