Leading items

Of Copyright Transfers, Slander of Title, and SCO

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 real estate matters, it's defined as "false, unjustified statements regarding another person's title to property". There are elements you must prove to win:

If you own a house, and I know I don't but I claim to be the owner anyway, you 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 interested.

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 contract dispute.

Malice is also a necessary element in a slander claim. The malicious claim must be intentional and without reasonable cause:

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 alone.

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 what 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 documents, including 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 contract?

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 requires copyright 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:

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 (PDF format) and here (also PDF).

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)

Needed: code auditors

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 same time.

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)

UserLinux Moves Forward

A lot has been happening on the UserLinux front since Bruce Perens first publicly announced 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 comprehensive Wiki for UserLinux with everything from project policies and package framework to the marketing concept and mission statement:

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 UserLinux profiles.

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:

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.

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 business-friendly.

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 development phase.

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)

New site feature: comment response notifications

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.

Comments (38 posted)

Page editor: Jonathan Corbet
Next page: Security>>