A lot of people are curious about SCO's
lawsuit against Novell for
"slander of title." First,
most people have never heard of such a claim
before and don't know what it is. Second, since the dispute surrounds a
question of transfer of copyrights, how exactly are copyrights validly
transfered and did there occur such a transfer between Novell and SCO?
And third, why sue for slander of title instead of bringing a breach of
contract claim or both together?
Taking those questions in order, first, what is "slander of title"?
Normally a claim you find in
matters, it's defined as "false, unjustified statements regarding another
title to property". There are
elements you must prove
A cause of action for slander of title occurs when there is a false
and malicious statement made to disparage a person's title to real
estate. The elements of slander of title are: (1) falsity of the
statement made; and (2) malice.
If you own a house, and I know I don't but I claim to be the owner anyway,
can sue me for slander of title, because I have cast a cloud
over your ownership claim in that house. There is such a thing as
libel not only to your personal reputation but also to the reputation of
property. You can read a bit more on that here if you are
But if it's instead a good-faith conflict, in which each
side thinks it really does own the house, well, that's a different
kettle of fish. It still needs to get worked out in the courts, but it
isn't slander of title, because it's not malicious to assert what you
believe are your legal rights. Otherwise there could never be a
Malice is also a necessary element in a
slander claim. The malicious claim must be intentional
and without reasonable
recover in an action for slander of title, a party must allege and
prove: (i) the utterings and publishing of disparaging
words; (ii) that they were false; (iii) that they were
malicious; (iv) that special damages were sustained thereby; (v)
that the plaintiff possessed an estate or interest in the property
disparaged; and (vi) the loss of a specific sale.
a basis for recovery of actual damages in a slander of title case means
merely that the acts must have been deliberate conduct without
As compared to other 'injurious falsehood' causes of action, slander of
title or property differs in that there is no presumption of damages.
The plaintiff must show that he or she sustains special damage
proximately, naturally and reasonably resulting from the alleged
slander.... The plaintiff
must prove the loss of a specific sale, i.e., that a pending sale was
defeated by the slander.
That has a bearing, obviously, on SCO's case against Novell. And it's why
some are questioning their choice to use that claim. If you read Novell's
letters, do you get the impression that they feel they actually
do own the copyrights? Note particularly the letters dated
May 28, June 6 and 26, August 4, and October 9 to
follow the copyright argument. If Novell honestly believes that it owns
the copyrights, there is no slander of title. The
necessary element of malice would be missing. It's not slander if the party
has a valid claim. Novell claims it did not transfer the copyrights to
SCO. This raises the possibility that Novell could win on that basis
Can SCO succeed is establishing its claims to copyright on Unix code? Some
have expressed doubt. And even if SCO were to succeed in establishing that
Novell has no copyrights, there is a deeper question, namely: what can and
can't you copyright when it comes to software?
Who owns the copyrights here anyway? To delve into it deeply, you would
need to read the contracts involved, and after you do, I'm guessing you
still won't be 100% sure, though you may well find yourself leaning toward
Novell. SCO highlights, in
particular, Amendment 2
to the Asset
Purchase Agreement, but Novell points out that there were other
Amendment 1, the
Schedules, and a Technology License Agreement, although the latter
does not pertain to the copyright issue. Novell isn't saying SCO has no
rights. Novell is saying it retained certain rights, that SCO needed to
assert a need for copyrights and that it never did that, that there were,
in other words, conditions that SCO has not satisfied. Because they did
not satisfy the conditions, the copyrights never transfered.
Why didn't SCO sue for breach of contract, then, if their position is
correct and copyrights were supposed to transfer and Amendment 2 is
the contract that was to make that happen? No one I have talked to can
figure that out. At least one attorney I asked about this thinks that
failure to assert a breach of contract claim will prove fatal to SCO's
chances of prevailing in the slander of title claim. While SCO alleges that
the copyrights were to have transferred under the Asset Purchase Agreement,
clearly it didn't happen, or there would be no dispute heading to court. So
why not sue for breach of contract and ask the judge to enforce the
SCO has been claiming that its rights to Unix were absolute, but all the
while it turns out it was in hot and heavy correspondence with Novell, so
its rights were contested all along. That fact alone, the fact that Novell
firmly asserted what it claims to be its rights, indicates that SCO may
have great difficulty persuading a judge that malice was involved. If you
have read the contract documents, you already know it is far from obvious
that Novell has no legitimate claim.
SCO registered for copyrights, but so did
Novell. SCO would need to show that Novell transfered those rights to
SCO. And it had to have been in writing, because copyright law
transfers to be in writing and "signed by the owner of the rights
conveyed or such owner's duly authorized agent." For example, a friend of
mine, who just registered a copyright in some music he wrote,
got a letter from the US Copyright Office that
included this sentence:
Copyright belongs initially to the author. It may be transferred
to another person or organization by a written agreement or by
operation of law. For registration purposes, the copyright
claimant is either (1) the author or (2) the person or
that has obtained ownership of all rights under the copyright.
Here, that would mean
Novell, who would have to transfer by writing to SCO.
There is no official US Copyright Office form
for a copyright transfer, so
normally they are effectuated by contract.
Here are some examples of copyright transfer forms some have used, to
give you an idea, here and here and here
So is the Asset Purchase Agreement plus amendments and schedules a
contract? Yes. Is a contract enough to transfer a copyright? Yes. Is it
clear on its face that this contract did mean to effectuate such a
transfer? That is not clear to many readers, and obviously Novell doesn't
think so. And intriguingly, if SCO ultimately fails to establish copyright
ownership, after publicly asserting Linux is infringing its copyrights
for nearly a year, and particularly if it sues end users for copyright
infringement, and it turns out their claim to copyright had no reasonable
basis and they knew it, is SCO opening itself up to a possible claim of
slander to title itself?
Comments (7 posted)
Free software is said to be more secure than the proprietary alternatives
for a number of reasons. Near the top of most peoples' lists is the
openness of the code: with all those eyeballs on the code, security
problems are found and fixed quickly. Over the years, however, we have
seen numerous signs that fewer people are actually looking at code than
many of us would like to believe. Too many vulnerabilities remain in our
programs for years for us to have any real confidence that comprehensive
auditing is going on.
There have been attempts to encourage developers to audit code.
Almost exactly two years ago, the announcement went out
for the Sardonix project. Sardonix was started after Crispin Cowan noted
that the Linux Security Audit Project
appeared to have stalled. Since auditing was not happening by itself,
Sardonix sought to provide some motivation in the form of infrastructure
and credit for auditors. With these incentives, it was hoped, some
large-scale code auditing would start to happen.
Thus, with a little help from a DARPA grant, the Sardonix portal was launched. The portal
would track the audit state of various free software programs and would
give credit to those who did the auditing work. Sufficiently skilled and
productive auditors would be able to accumulate a large "audit karma" to
show their friends - and help improve the security of free software at the
Two years later, the only auditing work which has been done on Sardonix was
a small set of projects assigned by a university professor to his
students. The last posting to the Sardonix mailing list was sent in
November, 2003. The DARPA money has run out. Sardonix, it seems, is a
project which has failed.
One can attribute this failure to a number of reasons. Certainly Sardonix
was never promoted very well; almost nothing was heard from the project
after the initial announcement. With an effort to jump-start the process
and a set of vulnerabilities found by Sardonix auditors posted on Bugtraq,
the project might just have achieved critical mass. As it is, Sardonix
vanished into obscurity shortly after its launch, and few people ever heard
of it again.
The sad fact remains, however, that, with or without Sardonix, very little
auditing is getting done. The continuing stream of vulnerability reports,
many for problems which have lurked undetected for years, make this clear.
Auditing code is difficult, tedious, and error-prone work. It also tends
to be thankless; strangely enough, many developers do not welcome news of
vulnerabilities in their work (though most do respond and fix the
problems). New vulnerability information requires careful handling; a
sustained effort may be required to get the developer to take the problem
seriously, but widespread disclosure of the problem must be avoided until
developers and distributors have had a chance to react. To top it off,
those who do seek out vulnerabilities in software are often seen as
promoting their own agendas and making the problem worse.
It is not
surprising that few people are stepping up and taking on this work.
The free software community has a lot of work to do if it wants to live up
to its promise of greater security. This battle must be fought on many
fronts: safer programming techniques, containment strategies, detection and
response, etc. But we also, somehow, have to find a way to get more
critical eyeballs looking at our code. As recent events have shown, the
black hats are already doing this work for their own purposes. If free
software wants to live up to its pretensions of being a more secure
alternative, it needs more developers reviewing the code.
Comments (17 posted)
A lot has been happening on the UserLinux front since Bruce Perens first
the project in
October. The project has moved
through the early discussion and design phases and is now moving into early
install testing with its own package repository. There is also a fairly
for UserLinux with everything from project policies
to the marketing
Provide businesses with freely available, high quality Debian based
GNU/Linux operating systems accompanied by certifications, service, and
support options designed to encourage productivity and security while
reducing overall costs.
Users and developers who are eager to try out UserLinux will find instructions
on creating a UserLinux system by converting a Debian unstable
system using the UserLinux package repository. At the moment, the UserLinux
package repository only has three meta-packages, one for each UserLinux
configuration: Desktop, server and server-gui. By adding the UserLinux
repository to a system's
/etc/apt/sources.list, users can use
apt to retrieve the packages necessary to run under one of the
KDE, however, is not in the package lists. A recent email
from Bruce Perens to the UserLinux discussion list provoked Slashdot and a
few other news sites to declare that UserLinux
would support KDE after all. We touched base with Perens on Tuesday,
and he said that this comment has been misinterpreted:
The project policy remains the same -- the official GUI will remain
GNOME. The option was always there for commercial service providers to
support KDE, or any other add-on software that they would like. That little
one line and they got excited. The fact is that a customer asked me to
support KDE, and I said 'sure, I'll take your money to support any open
In the past, Perens has mentioned that some companies have approached him
about the UserLinux concept. We asked Perens if he was now able to name any
of the companies that had expressed interest in backing UserLinux. Perens
declined to give the name of any companies he'd spoken with, saying that he
was in contract negotiations and he could not give any names at this
time. He also said that he asks people not to speculate on the companies he
may be in talks with, as it might give potential backers cold feet.
We also asked if there was a lot of work needed to make Debian
"enterprise-ready." Perens said that Debian is a "solid base" and that
there are only a few areas where Debian really needs improvement.
It's important to concentrate on Debian's strengths... I can't beat the
quality of Debian. A lot of what I'm doing on the UserLinux project is
making sure that Debian's good points are not compromised and that we take
advantage of all the good decisions that they've made...I want to be able
to take Debian into the enterprise without doing anything to dissuade the
He did acknowledge that there are some areas which need improvement. For
example, Perens noted that some Debian packages are installed in a
non-functional state by default. Perens said that all packages should be
installed in a "working state" even if it's just a demo configuration for
testing. He also noted that UserLinux will need to support batch or cluster
installs, and that the new Debian installer will make Debian much more
For developers who want to contribute to the project, Perens says that he'd
like to see them go through the Debian Developer process and check
any packages into the Debian repository first. "I would not like to see a
large repository of free software that does not live in Debian for some
reason." He said that he expects that UserLinux will begin to draw new
people into the project now that the project has entered the testing and
When can we expect to see an official release of UserLinux? Perens said
that there is no firm date, but that the rough date for a release of
UserLinux will correspond with the Debian Sarge release. He also noted that
UserLinux will be providing pre-releases and CD releases before then.
Comments (18 posted)
Occasionally we get a request from readers to receive copies of responses to their
posted comments via email. We have recently freed up a bit of hacking time and
added that capability as a subscriber-only feature, with a bit of a twist.
That twist is this: response notifications are only available to
subscribers at the "professional hacker" level or above.
When we switched over to the subscription model, we implemented the
"starving hacker" level as a way for people who couldn't afford the full
LWN rate to subscribe anyway. The intended audience was students, people
who were looking for work, and those in parts of the world where $5 was a
lot of money. Over time, we have noticed a few trends:
- $5 is no longer very much money in much of the world.
- People should be having an easier time finding jobs. Our President
says so, so It Must Be True.
- The percentage of our subscriber base taking the "starving hacker"
option has grown significantly.
The conclusion we have come to is that, as LWN (hopefully) grows, we need a
way to motivate people to select the full-rate option that goes beyond
"you'll feel better because you're supporting LWN." Given a cheaper choice
with the same benefits, many people will, rationally, take that route.
So limiting response emails to the higher subscription levels is a bit of
an experiment. Hopefully, it is a small inducement to select a higher
subscription level which does not actually deny anything truly important to
the "starving hacker" subscribers. We may take a similar approach with
other new features in the future, depending on how this one works out.
Getting response notifications is easy: there is a new dialog that shows up
when a comment is published that enables the email feature. There is an
expiration date, and the option to get notifications for responses all the
way down the tree. There are a couple of things worthy of note:
- We need to have your email address to be able to send responses to
you. If you have not given us a working address, the feature won't
work. The My Account page can be used to
set your address if need be. Also, please don't expect us to navigate
through challenge-response systems to send you email.
- If you get tired of seeing notifications, the My Account page will
let you turn them off.
You can also set your default response preferences in the account
customization area. While adding that capability, we also, finally, added
an option for the default setting of the "plain text/HTML" flag for
Comments (38 posted)
Page editor: Jonathan Corbet
Next page: Security>>