Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
LWN.net Weekly Edition for December 11, 2003SCO Weekly News It has been a busy week for those of us watching the SCO case. Here's a summary of all that has been going on...The fun started with an even more than usually bizarre open letter from Darl McBride (actually written by his brother Kevin, about whom we will hear more shortly, and a SCO technical writer) on the evils of the General Public License. The letter makes for difficult reading, but the core of its argument is this:
SCO argues that the authority of Congress under the
U.S. Constitution to "promote the Progress of Science and the
useful arts..." inherently includes a profit motive, and that
protection for this profit motive includes a Constitutional
dimension. We believe that the "progress of science" is best
advanced by vigorously protecting the right of authors and
inventors to earn a profit from their work.
By SCO's reasoning, the GPL, being a mechanism by which the owner of a copyrighted work can allow others to distribute that work without paying a license fee, interferes with the profit motive SCO has read into the constitution and, thus, is unconstitutional. Needless to say, this novel line of constitutional reasoning is finding few defenders outside of SCO. See, for example, responses by Lawrence Lessig, Linus Torvalds (who did some interesting research into copyright law himself), and on Groklaw. The real purpose of the open letter appears to have been to distract attention from some other events, the first of which being the hearing on IBM's motions to compel discovery on December 5. As most readers will have seen by now, IBM won a complete victory in that hearing. Both motions to compel were upheld, while SCO's motion was tabled and all further SCO discovery has been suspended until SCO has satisfied IBM's questions. SCO now has 30 days to specify exactly which code it claims IBM has stolen, and it will not be able to go fishing through AIX for its answers. The December 5 hearing was also interesting in that David Boies, SCO's brand-name lawyer, didn't see fit to show up. Instead, SCO was represented by Kevin McBride, Darl's brother. This was Kevin McBride's first public appearance in this case, and he appears to have impressed few people - certainly not the judge presiding over the hearing. He started by sitting at the defendants' table, and had to be told to move to the other side of the court. His arguments were generally described as incoherent and unconvincing; he talked a lot about what a complex case it was. And, of course, he lost. For those seeking further information, there are a few postings on Groklaw: transcripts of the hearing (scroll down to the second version, which is more complete), a list of what SCO must now provide to IBM, and a guest article on where things go from here (mostly downhill). SCO was supposed to announce its fourth quarter earnings on December 8, but that announcement has been delayed until the 22nd. The stated reason is that the company needs more time to finish accounting for the BayStar investment. Others have speculated that the quarter will look so bad that the company hopes that, by delaying the announcement to just before Christmas, it can escape notice. Some of the truth, perhaps, came out in a three-part SEC filing on December 9. This filing provides some interesting insights into how SCO deals with its investors and lawyers. It also, perhaps, gives the real reason for the earnings delay: SCO was still negotiating with BayStar and the Royal Bank of Canada (RBC). It would appear that these investors got a little nervous about SCO's agreement with its lawyers giving those lawyers 20% of any settlement, investment in, or sale of the company. As a result, SCO has filed a statement that it will not take any action which triggers the 20% fee unless 2/3 of the preferred stockholders (BayStar and RBC) agree. The investors, in other words, have established a veto power over the lawyers. The second part of the filing is a letter from Boies, Schiller & Flexner to SCO describing the arrangement between the two companies. This letter is dated February 26, 2003, but is only being released now. The letter states that Boies et al. will be paid on an hourly rate - not the pure contingency deal that SCO has claimed in the past. SCO was also required to put up a $1 million retainer, and to top it up whenever it gets spent down to $250,000. Also stated in this letter is:
It is hereby recognized and acknowledged that Kevin McBride, the
brother of SCO's Chief Executive Officer, Darl McBride, is
an attorney at Angelo, Barry & Boldt who will be working on this
matter. By signing below, Darl McBride acknowledges that full
disclosure of Kevin McBride's involvement in the matter and the
terms and conditions of the fee letter has been made to and
approved by the Board of Directors of Client.
In other words, Boies was not entirely comfortable with Kevin McBride's presence and required assurance that SCO's board of directors understood what was going on. The letter also notes that efforts to sell licenses to Microsoft and Sun were already underway last February. Finally, this letter from SCO to Boies confirms recent payments to the law firm: $2.6 million, plus the 400,000 shares of stock. SCO has until the beginning of March to deliver the stock (SEC formalities must be cleared first). The letter notes that Boies et al. will be taking on, in addition to the IBM suit, defense against the Red Hat suit and IBM's counterclaims. Boies will also be helping in "pursuing our potential claims against third parties arising out of the USL/BSDI settlement." Exactly what that means remains to be seen.
Interview: Dan Ravicher on derived works What is a derivative work when it comes to software? Between SCO's attempts to define it as "anything that ever breathed the same air as Unix" and the recent discussions on linux-kernel about the status of closed-source modules (see this week's Kernel Page), it is only natural to wonder if there is any way, short of going before a judge, to know. Is there a standard rule a programmer can measure his work by and know whether he has produced a derived work or not?Dan Ravicher, Esq., Senior Counsel, Free Software Foundation, and Executive Director, Public Patent Foundation, was kind enough to grant me an interview and explain. Note that he is discussing the situation in the US, because that is where he practices. However, his ultimate advice applies to international copyright issues as well, namely: ask a lawyer who practices where you live for an opinion. Get it in writing. PJ: Is there one definition, The Definition, as it were, of derivative works that applies to everyone?
The definition of derivative work is an issue under copyright law,
which is exclusively a federal question (state courts are forbidden
from addressing the issue). Therefore, there could conceivably be
94 different "derivative work" definitions, as there are 94
different federal district courts (the trial level of the federal
court system). [Note: There could be even more, as there are
several judges within each district, who could each have different
opinions on the law.]
Although district court judges are supposed to give deference to one another's opinions, they often do not. As such, above those 94 district courts, there are 13 circuit courts of appeals, which each attempt to unify the law as between all the district courts within their jurisdiction. Here's a map showing which districts fall into which circuits. Again, like the district court judges, the circuit court judges are supposed to give deference to one another's opinions, but they often do not. So, above the 13 circuits, is the Supreme Court, which is supposed to unify law amongst the circuits. Every case has a right to appeal to the Circuit Court, but appeal to the Supreme Court is only by discretion. As of yet, despite the difference in opinions between the circuits regarding the question of what constitutes a derivative work of software, the Supreme Court has not taken any such case. One can speculate why this is so, including that many of the circuits, including two of the most influential to the conservative Supreme Court, the 7th and the 4th, have yet to take an opinion on the issue. Further, the 9th and 2nd Circuits, routinely the most important for copyright law (because NY and CA are home to media companies and Hollywood), are pretty much in agreement on the issue, and several circuits have followed their lead. If it is circuit by circuit, how does Utah's circuit, where the SCO v. IBM case will be decided, define it?
Utah's District Court is within the 10th Circuit, which has adopted
the Abstraction, Filtration, and Comparison test of the 2nd
Circuit. For a discussion of how that test defines derivative
work, you can read a paper I have written on that subject here [PDF
format].
[Editor's note: the above paper actually covers a few different tests used by the circuit courts to determine whether one program is a derived product of another. It is recommended reading for anyone who would like a better understanding of the different ways of approaching this problem.] Please bear with me. This is a long question, but I want to be sure you cover the complete question, and I know you are a programmer as well as an attorney: The Linux kernel is, of course, licensed under the GPL. There is a continuing controversy over the legal status of closed-source kernel modules. Nobody really likes them, but they have been tolerated so far. There are kernel hackers who have threatened to eventually take a binary module vendor to court for infringing their copyrights, however. Is a kernel module a derived product or not? Some people claim that there are precedents saying that anything which can be unplugged and replaced falls on the other side of the boundary and cannot be considered a derived product. Others point out the substantial amount of inline function code used by Linux modules, along with the deep knowledge of kernel internals required, and say that modules are necessarily derived products. One can point to a continuum of modules to see that the situation is not simple. LSM security modules can hook into almost every part of the kernel and fundamentally change its operation; almost everybody agrees that they are derived products. On the other hand, modules exist which allow the loading of Windows NDIS drivers into a Linux kernel; few people would claim that the Windows driver has become a derived product. Is there any way to figure out where the boundary really is short of asking a judge?
The intuition that there is no bright line answer regarding modules
is correct. The test of derivative work is a very fact-specific
one; meaning that minor differences can substantially impact the
result. In practice, highly factual issues are typically resolved
by both sides in litigation having representative experts testify
that the facts lead to one conclusion or the other.
However, this doesn't mean one needs to necessarily wait for a judge to decide the issue in order to have some guidance. In order to better manage and calculate legal uncertainty, clients often ask their attorneys for a legal opinion regarding a certain situation. In what are called "Opinion Letters", attorneys opine as to the conclusion they think would be reached if a judge addressed at the issue. For instance, a few years back the W3C sought the opinion of its attorneys regarding whether or not one of its standards infringed a patent, which you can read here. Although such letters are not a guarantee that the issue, if ever presented to a court, would be resolved in that way, they do allow the client or other recipient of the letter to rely on the attorney's opinion in making decisions. That reliance, if reasonable and based on a "competent opinion", may go a long way to help the client prove they did not act in bad faith, which is very important under the law because penalties for copyright infringement can be drastically increased if the infringer is found to have acted in bad faith. Coming soon: the second half of this interview, which covers free software and patents, especially Microsoft's claimed FAT filesystem patent.
A Look at the UserLinux Proposal About two months ago we reported that Bruce Perens was considering the formation of a community-driven "enterprise" Linux distribution. Perens has made up his mind, and has produced a manifesto which serves as a rough outline of what UserLinux would be, and a discussion list for those interested in participating. According to Perens, UserLinux would be "a system for both desktop and server use in businesses of all sizes."Why would we need another Linux system? It's not as if there's any lack of distributions. We spoke to Perens to get the details on UserLinux. According to him, there's a need for UserLinux because current Linux vendors are too focused on profits, and the needs of users are being neglected. In the last year or so, he noticed "the rise of proprietary open source. Software that is purportedly open source-licensed, but the user is still made to pay in the long run." This trend is causing problems for Linux. In his white paper, Perens writes:
The very aspects that make Linux desirable, its low cost, Open
Source nature, and the way it gives customers more control over
their software, are under attack by Linux vendors bent on
increasing shareholder value. Businesses are paying more as Linux
distributions demand a per-seat cost and service lock-in for
software that they didn't develop and that others support.
In creating a community-driven solution for business, UserLinux could provide an alternative for businesses that aren't looking to pay per-seat fees to companies like Red Hat. However, a community-driven project will face problems that Red Hat and other vendors have already (at least to some extent) overcome. One major obstacle that UserLinux will face is garnering the support of independent system vendors, such as Oracle. Any distribution aimed at the "enterprise" market will need that support. Theodore Ts'o noted that this can be an expensive undertaking for some of the highly desirable ISVs. Perens acknowledges this in the second draft of the UserLinux paper:
It will probably be necessary for us to arrange to have a porting
lab for the use of ISVs, where they could come to do their work
with the support of an expert in our system, and for them to have
free call-in support on issues related to supporting their products
on our platform. These things would be paid for by the service
provider organization.
The question, of course, is how the organization will pay to support a lab and other endeavors. Perens explained that he would like to see an organization for UserLinux service providers, which could certify providers and serve as a point of contact for the providers and customers. Providers would probably pay some fee for certification "on a sliding scale based on the size of the business" to allow for sole proprietorships. The organization might charge some percentage for business referred to the providers, but he doesn't want the organization to be a mandatory gatekeeper between customers and providers. He also noted that UserLinux could also have uncertified providers, they would simply not be allowed to use the trademark for certification. The service organization also answers another question that businesses are likely to have: "Who is going to support me?" Perens states in his paper that a organization built around UserLinux would actually be able to support more customers than Red Hat:
Red Hat boasts that it employs 300 engineers, but few of those
engineers are in customer-contact positions. Their support
organization is surprisingly small. Our multi-company effort has
the potential to be able to offer more service, even by simple
metrics like head-count, reasonably early in its existence. It can
provide better-localized service because of the potential for
involvement by service companies in many regions. And we can
provide better quality, and lower-cost service, due to the fact
that our service providers will compete with each other for
business.
This organization may work to provide technical support, though it bears a strong resemblance to Red Hat's early "Support Partner" program, which was never very successful. What may prove harder is convincing potential users that other sorts of support - such as security updates - will be available for several years into the future. Another obstacle faced by UserLinux is package support. Specifically, which packages to bundle into the distribution. At this point, Linux has several areas where there are a number of competing packages that perform the same general functions. Perens argues that an enterprise project should make choices between various packages and pick a single package rather than be bogged down trying to support a array of packages. This would not prevent users or vendors from adding packages, but the default system would include only one of a given type of package. This is likely to cause some heated and unpleasant debates as UserLinux moves forward. There are already some strong objections to Perens' preliminary choices on the UserLinux discuss list. Eventually, these choices have to be made, however. Perens proposes that these and other technical choices be made by a meritocracy, similar to projects like the Linux kernel, the Apache project or the Debian project itself. UserLinux is, at this point, only a concept. There is much work to be done, and much of it is in uncharted territory. Whether or not it succeeds depends on a number of factors, some of which are obvious now and others will only become apparent with time. But if the success of Linux has taught us anything thus far, it is that the open source community can succeed where many expect failure.
Page editor: Jonathan Corbet Security Security news Lessons from the Debian compromise It's been said that what doesn't kill you makes you stronger: if so then Debian must be very strong these days. The recent attack on Debian's servers is well known. It has been well documented and explained in detail. What remains to do is to consider the aftermath; have lessons been learned?Recall the sequence of events. In the month of November, an unknown person developed a crack that exploited that now famous kernel flaw and found his way into a Debian developer's machine. Although it's not known if the attack was focused on the developer's machine in particular, it was quickly understood by the attacker that this PC presented a means to accessing the Debian servers. He installed the requisite tools that took over the machine and sniffed out the passwords. The attacker then obtained the password that enabled him to compromise a Debian project server. In quick succession, he penetrated a number of machines which spanned North-America and Europe. It must be understood that up to this point the attack had not been detected. The machines were penetrated and had been successfully subverted. The attacks were executed in such a manner that none of the installed security mechanisms caught the activity. So why didn't the archives get compromised? And how was it that the attack, was even discovered? The hand-crafted kernel exploit was not perfect. According to a group of Debian contributors who were interviewed at a recent Linux User's Group meeting (LUG), the exploit worked on all of the Intel machines but failed against one Sparc system, which is where the archives happen to reside. Another crack imperfection was that it generated strange messages in the log files which led to the attack's discovery. It turns out that one of the system administrators became uneasy as he was looking through the log files of one of his machines. He quickly understood that the messages were not normal and the other machines were checked out in short order. This is how the attack and its point of entry (the developer's compromised machine) were discovered. What are the lessons learned?
Has anything been learned from this event that can help us formulate a more proactive policy? That answer depends on how much we, the open source community, are willing to work to eliminate these violations. These kinds of people can exploit a hundred machines before they stumble over one that can really hurt us. And that's the irony, for every attack that is noticed there are ten more that are unseen. By increasing the diversity of our systems and the alertness of our administration, we improve our chances of detecting and shutting down this sort of attack before it does real damage.
Discontinued SuSE Linux Distributions SuSE has announced an end of life for SuSE Linux 7.3. Vulnerabilities found after December 15, 2003 will not be fixed for SuSE Linux 7.3.
New vulnerabilities cvs: unauthorized file creation
FreeRADIUS: Denial of service vulnerability
rsync - remotely exploitable heap overflow
Updated vulnerabilities 2.4 kernel - several vulnerabilities
apache: buffer overflows in mod_alias, mod_rewrite
apache2: Denial of Service vulnerability
bind: cache poisoning
CUPS: denial of service
ethereal: multiple remote and local vulnerabilities
Filename disclosure vulnerability in fam
fetchmail may crash on specially crafted message
fileutils/wu-ftpd: denial of service
glibc: DNS stub resolvers contain buffer overflow vulnerability
GnuPG: ElGamal signing keys compromised
gtkhtml: malformed messages cause crash
iproute: local denial of service
KDE: Two issues in KDM
kernel: local root exploit in 2.4.22
kernel-utils: setuid vulnerability
libnids: remotely exploitable buffer overflow
libpng, libpng3: buffer overflow
mikmod: buffer overflow
mpg123: heap overflow
mplayer: remotely exploitable buffer overflow vulnerability
Nessus NASL scripting engine security issues
Net-SNMP: security bugs in versions before 5.0.9
nfs-utils xlog() off-by-one bug
openssh: timing attack leads to information disclosure
Pan: denial of service
postfix: denial of service vulnerabilities
proftpd: remote root shell
Multiple-use vulnerability in Safe.pm
sane-backends: several vulnerabilities
screen: privilege escalation
stunnel: file descriptor leak
File overwrite vulnerability in tar and unzip
Multiple vendor telnetd vulnerability
vim - modeline vulnerability
wget: buffer overflow
zebra: denial of service vulnerability
Resources Patchmanagement.org Patchmanagement.org has been launched as a moderated mailing list where interested parties can talk about patch management.
A FAQ on the OpenSSL FIPS 140-2 validation effort The Open Source Software Institute has posted a FAQ describing the current OpenSSL FIPS 140-2 validation effort. This work, which is sponsored by HP and the Defense Medical Logistics Standard Support program of the DoD Military Health System, seeks to have the OpenSSL cryptographic modules certified as complying with the FIPS 140-2 standard. At that point, it would be possible for vendors to create applications which carry the same validation. See the document for lots of details.
Events Black Hat Briefings Amsterdam Call for Papers The 2004 version of the Black Hat Briefings will be held in Amsterdam on May 17 to 20. The call for papers is out now, with a submission deadline of March 25.
Page editor: Jonathan Corbet
Kernel development Release status Kernel release status The current development kernel remains 2.6.0-test11; Linus seems to be waiting for Andrew Morton to return from vacation and pick up the baton. Linus has, however, accepted a few dozen small bugfixes into his BitKeeper repository.The current stable kernel is 2.4.23; Marcelo has started off the 2.4.24 process with 2.4.24-pre1. This prepatch includes the XFS filesystem (see below) along with a fair number of networking and architecture patches.
Kernel development news 2.4, XFS, and DM As reported last week, many users had requested that the XFS filesystem be added to the 2.4 kernel despite Marcelo's stated intent to go into a maintenance-only mode. Those users h | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||