LWN.net Weekly Edition for December 11, 2003

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

Comments (6 posted)

Interview: Dan Ravicher on derived works

December 10, 2003

By Pamela Jones, Editor of Groklaw

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.

Comments (7 posted)

A Look at the UserLinux Proposal

December 10, 2003

This article was contributed by Joe 'Zonker' Brockmeier.

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.

Comments (3 posted)

Page editor: Jonathan Corbet

Inside this week's LWN.net Weekly Edition

Security: Lessons from the Debian compromise; New vulnerabilities in cvs, FreeRADIUS and rsync.
Kernel: 2.4, XFS, and DM; Dynamic devices in 2.6; Binary-only kernel modules.
Distributions: Around the World in 80 Lines; Red Hat Enterprise Linux 3 gains LSB certification; ASLinux Desktop; Buffalo Linux
Development: The Anjuta 1.2.0 IDE for C/C++, new versions of JACK, Speex, MySQL, PostgreSQL, Ecasound, GNOME System Tools, XFree86, Mozilla Thunderbird, Gnumeric, Epiphany, Kodos.
Press: Linus on Copyright Law, SCO ordered to show code, SMBs turn to the Penguin, Yopy 3700 review.
Announcements: Progeny offers Red Hat updates, New OSDL members, The SCOX Loss Pool, Penguincon 2.0, Cluster Conferences.
Letters: Saying thanks; Proprietary science.

Next page: Security>>