Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
LWN.net Weekly Edition for February 5, 2004Of 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:
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, 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:
To
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.
Malice as
a basis for recovery of actual damages in a slander of title case means
merely that the acts must have been deliberate conduct without
reasonable cause....
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 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:
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
organization
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 (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?
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.
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:
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 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
source software.'
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
Debian developers.
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.
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:
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:
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.
Page editor: Jonathan Corbet Security Security news Fixing spam with postage Bill Gates has recently come up with an idea for the spam problem: charge postage for email. This idea is far from new, of course, but, when Bill says it, more people listen. On its face, the idea has a certain amount of appeal. Spammers exist because the economics of the email system favor them: large amounts of mail can be sent for no money, meaning that even very small response rates can be profitable. Adding even a small per-message cost would change the situation considerably. Some variations of the scheme have email recipients pocketing the postage themselves, perhaps only if they decide the associated message was unwanted. Others have ISPs collecting that money; for some strange reason, most ISPs tend to be more interested in the latter approach.There are, of course, a few practical problems with this idea. Large mailing lists, for example. If people sending to a list have to pay postage for every recipient, list traffic is likely to drop considerably. If, instead, a message to a list is paid as a single message, large lists will remain attractive targets for at least some spammers. The real problem, however, is that the postage approach, in most implementations, takes a classic end-to-end Internet service and turns it into something centralized. Certainly, one can envision a nice system based on micro-payments where individual users have mail clients which deal with postage issues directly and no central authority is involved. Envisioning MSN or Yahoo choosing such a system is rather harder, however. They will, instead, create a central "post office" which enforces the postage policy and which collects some or all of the money involved. The result is unlikely to resemble the email system we have known for the past couple decades or so. A central post office will require enforcement mechanisms, or people will quickly learn to bypass it. It is hard to imagine unstamped email being easier to stop than, say, music downloads. A postage-for-email scheme looks like a sure way to set off another Internet arms race. Things would be worse if the imposition of a central post office were actually made to work. The temptation to start filtering mail, initially for viruses or some such, would likely prove irresistible. Beyond doubt, the types of mail requiring filtering would grow over time. A central post office would also be an ideal place for governments to apply taxes to electronic mail as their contribution to ending the spam problem. There are also obvious privacy issues to worry about in this scenario. The "postage stamp" approach to spam thus looks problematic on many fronts. Before assuming that these problems would block the acceptance of a central post office, however, one should keep this in mind: the spam problem is getting worse quickly. A great many users will be willing to give up a fair amount of their freedom to somebody who can come up with something that looks like a working solution. This is a scary idea, but it is also a great opportunity. If the free software community can come up with a solution to the bulk of the spam problem while preserving our decentralized net and our freedom, World Domination will be that much closer.
Security posters from Microsoft ![[Worm crossing!]](/images/ns/worm-crossing.png)
Microsoft has had some high-profile security problems recently. A big
company like that knows what to do in this sort of situation, however:
release a
set of motivational posters for the work place. The three posters are
downloadable in PDF format; surely our community has no end of gimp artists
who can improve on them. Remember: "Protect your stuff: use up-to-date
antivirus software."
New vulnerabilities crawl: buffer overflow
perl information leak
util-linux: information leak in the login program
Updated vulnerabilities apache: buffer overflows in mod_alias, mod_rewrite
apache2: Denial of Service vulnerability
bind: cache poisoning
CUPS: denial of service
cvs: possible root compromise
ethereal: protocol dissector and other vulnerabilities
Filename disclosure vulnerability in fam
fetchmail may crash on specially crafted message
fileutils/wu-ftpd: denial of service
gaim: remote overflows
glibc: DNS stub resolvers contain buffer overflow vulnerability
GnuPG: ElGamal signing keys compromised
gtkhtml: malformed messages cause crash
iproute: local denial of service
kdepim: VCF file information reader vulnerability
kernel: privilege vulnerability on AMD64
kernel: local root exploit in 2.4.22
kernel-utils: setuid vulnerability
lftp buffer overflows
libpng, libpng3: buffer overflow
mc: arbitrary code execution
mikmod: buffer overflow
mod_python: denial of service vulnerability
mpg123: heap overflow
mpg321: format string vulnerability
mplayer: remotely exploitable buffer overflow vulnerability
Nessus NASL scripting engine security issues
netpbm: insecure temporary files
Net-SNMP: security bugs in versions before 5.0.9
nfs-utils xlog() off-by-one bug
openssh: timing attack leads to information disclosure
postfix: denial of service vulnerabilities
rsync - remotely exploitable heap overflow
Multiple-use vulnerability in Safe.pm
sane-backends: several vulnerabilities
screen: privilege escalation
slocate: buffer overflow
File overwrite vulnerability in tar and unzip
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||