LWN.net Weekly Edition for September 11, 2003

The state of the SCO case

The whole SCO affair started as a breach-of-contract suit against IBM. That suit is based on the language of the Unix contracts signed with ATT almost two decades ago, which reads:

The core of SCO's claim is that anything that IBM has ever allowed to be a part of a Unix system has become a "derived product" of Unix and must be treated as if it were Unix itself. SCO cannot make any ownership claims over this code - a side letter to the contract makes that explicit - but it does claim the right to keep IBM from disclosing its own code.

Through its public statements, SCO has since made claims of massive direct copying of SYSV Unix code into Linux. There is still no court case where SCO has made such claims, however. The company's experience at SCO Forum and subsequent public statements suggest that the evidence for direct copying of code - actual copyright violations - is weak at best. SCO might have a small case against SGI, depending on how a judge might choose to interpret the copyright status of 32V Unix and the true source of the ate_malloc() code. But that is between those two companies; the code in question has already been removed from current Linux kernels.

Increasingly, it seems that SCO is left with its original breach of contract case. The recently issued open letter from Darl McBride does nothing to change that impression; it mentions the ate_malloc() case but does not allege any other direct copying. Instead, the company's claims are expressed as follows:

In SCO's view, "Unix System V protected code" is a rather wider set than "SCO-owned code." In fact, at SCO Forum, the company put up a slide discussing the "more than one million lines" that it claims. Here's where they come from:

Subsystem	Files	Lines
Read-copy-update	46	109,688
NUMA	101	56,587
JFS	44	32,224
XFS	173	119,130
Symmetric multiprocessing	1,185	829,393
TOTAL	1,549	1,147,022

(SCO has posted the slides to its presentations on this page. You'll have to click past the cheery warning that things are optimized for Internet Explorer to view them, though.)

These claims are interesting in a number of ways. Let's look at the RCU claim for a moment. In a modern Linux kernel (RCU does not appear in 2.4), the RCU implementation is contained in two files (include/linux/rcupdate.h and kernel/rcupdate.c), which add up to an amazing 402 lines. That leaves us 44 files and 109,286 lines short of the claim made by SCO. Clearly, SCO must also be making claims on any code that uses RCU in any way. If you look for files that make any use of the RCU subsystem, the results are:

File	Lines
arch/i386/oprofile/nmi_timer_int.c	57
drivers/char/ipmi/ipmi_kcs_intf.c	1275
fs/dcache.c	1641
include/asm-x86_64/kdebug.h	44
include/linux/rcupdate.h	135
include/linux/dcache.h	316
include/linux/list.h	565
include/net/dst.h	254
init/main.c	604
ipc/util.c	612
kernel/rcupdate.c	267
kernel/module.c	1949
kernel/sched.c	2594
net/802/psnap.c	160
net/bridge/br_device.c	147
net/bridge/br_forward.c	157
net/bridge/br_if.c	289
net/bridge/br_ioctl.c	309
net/bridge/br_input.c	159
net/core/netfilter.c	761
net/core/dev.c	3092
net/ipv4/af_inet.c	1250
net/ipv4/icmp.c	1120
net/ipv4/ip_input.c	433
net/ipv4/route.c	2797
net/ipv6/af_inet6.c	895
net/ipv6/icmp.c	787
net/ipv6/ip6_input.c	260
net/decnet/dn_route.c	1843
TOTAL 29 files	24,772

So, even with such an expansive interpretion of SCO's claim, there are 17 files missing. They must be big files as well, since they must account for the remaining 84,916 lines. The "contamination" caused by RCU is evidently a very broad thing. We asked SCO where the missing files were, but were told only "[T]his level of detail is something that we will save for our court case in 2005." So we're going to have to remain in suspense for a while. But one thing is clear: SCO claims that the old AT&T licenses give it amazing powers over code that has ever breathed the same air as SYSV Unix. Anybody who claims that the GPL is overly "viral" or that it threatens intellectual property should take a good look at the powers that SCO claims its license gives it. The GPL can't compete in that league.

SCO's legal argument is interesting; the company claims that Linux hackers have, while having never actually seen the SYSV Unix source, nontheless created a derived product of SYSV Unix. They are accused of copying something they never had access to. This argument seems destined to fail; how can something which contains no SYSV code be a derived product of SYSV? But that is the core of SCO's argument.

An interesting question comes out of this: what if SCO wins its case? SCO will have then convinced a court that IBM released IBM's code in violation of an agreement it had with SCO. The fact that IBM released IBM's code, however, would not change. SCO does not own that code, how can it claim a right to payments from Linux users? If SCO wins, it may get a chunk of money from IBM. But it should still have nothing which entitles it to license payment from Linux users.

Returning to Darl McBride's open letter, we note that there are no demands that Linux users buy SCO "licenses," and no threats of suits against users. Mr. McBride, instead, has taken a bit of a different approach:

One might point out that the free software world does, indeed, have an "intellectual property foundation." It is based on copyright law, and free licenses, including the GPL, which SCO has said it wants to break. One might also point out that the community is not in much of a mood for "working with" SCO at this point. But one's time might be better spent pondering what SCO was thinking when it published those words.

SCO clearly wants to be able to put a tax on Linux systems. SCO also clearly sees the GPL as an obstacle; there is no way to make a tax stick to Linux as long as it remains freely redistributable. Could SCO be casting around for a scheme to buy off free software developers should its challenges to the GPL fail? A nice tax for SCO and a few bones tossed to developers willing to relicense their code? It is hard to see how such a scheme could possibly succeed, but it is also hard to find another way to interpret the words quoted above.

In summary, the SCO case remains interesting. SCO has changed its tune several times, but, for the moment, is back where it began: a breach of contract suit against IBM. The company has yet to produce any evidence that Linux users owe it money. It is also now interested in "working with the open source community." But SCO remains unpredictable. We have not yet seen the last strange twist in this case.

Comments (13 posted)

An opening for OpenOffice.org

[This article was contributed by Joe 'Zonker' Brockmeier]

For years now, Linux users have had to struggle with the omnipresent Microsoft Office formats. Developers working on OpenOffice.org, Abiword, KOffice, Gnumeric and other applications have had their hands full trying to decipher the proprietary and obfuscated MS Office formats so that users could read and exchange documents with their MS Office-using colleagues. With Microsoft Office 2003, Redmond is taking obfuscation to new levels that may mean legal problems for developers who try to provide compatibility with Office, and huge fees for companies that try to adopt it.

In addition to the usual slew of new features, Office 2003 Professional comes with Information Rights Management (IRM) tools. (Users of Office 2003 Standard can not create IRM documents.) Basically, IRM is just another name for Digital Rights Management (DRM), a term that Microsoft is avoiding because of the negative connotations that DRM has already picked up. IRM allows users to restrict what others can do with a document. Without the proper permissions, recipients of IRM-restricted documents will be unable to read or print them. Recipients of IRM-restricted e-mails will be unable to forward them as well. And users can set documents to expire.

Naturally, these documents will be incompatible with previous versions of Microsoft Office, to say nothing of competing tools like OpenOffice.org, Gnumeric or Ximian's Evolution. In addition to the usual format obfuscation, however, Microsoft also has the Digital Millenium Copyright Act (DMCA) to protect it from competition. Since the format includes encryption, Microsoft will be able to threaten developers with the DMCA if they attempt to include support for IRM-restricted documents.

Microsoft's IRM also depends on its server-based Rights Management Services (RMS). This means that any company wanting to adopt IRM is also forced to adopt Microsoft at the server. It doesn't preclude companies using a mixture of Microsoft and Linux servers, but it does mean that organizations that have only adopted Microsoft at the desktop would be forced to make additional investments in Microsoft software.

Not only is the technology extremely restrictive, the price should be enough to give any CFO or business owner pause. To deploy RMS within an organization requires that you run Windows Server 2003. That brings some hefty licensing fees on its own, but there's more. Every user who connects to that server has to have a Windows Server 2003 Client Access License (CAL) and a RMS User CAL, not to mention the licensing fees for that user's copy of Windows XP and Office 2003 Professional. The RMS CAL alone runs $37 for a single user, or $185 for a pack of five CALs. No doubt, large organizations could get the CALs even cheaper, but it still becomes very expensive. Note that this isn't just for users who create IRM documents, but also for any user who views an IRM-restricted document.

That's to use Microsoft's RMS within an organization. Companies that want to share files with users outside the organization, will need yet another license from Microsoft. According to Microsoft's pricing and licensing overview page, this license alone will run an organization $18,066 for the Windows RMS External Connector License. This fee may not be a major obstacle for large organizations, but it would certainly represent a major burden on small companies that need to share documents with clients.

Believe it or not, Microsoft's new Office suite is potentially good news for the open souce community. It creates yet another opening for Linux vendors and proponents to make the case for free and open software in business. Microsoft has laid out its vision for the future of software, and it's filled with licensing fees stacked upon licensing fees -- and technologies that suck the user deeper and deeper into Microsoft's "stack" of solutions. Many organizations have been content to adopt Windows on the desktop, and other technologies at the server level. Redmond's all-or-nothing approach, attempting to force their customers to adopt their toolchain entirely, may end up driving them away completely.

To use IRM/RMS, an organization would have to adopt Microsoft across the board -- and likely will require them to persuade their business partners to do the same. Few organizations can get by without sharing documents externally. Expect major levels of frustration when a company adopts Office 2003 with IRM, and tries to share documents with others using older versions of Office. Even if a company is gung-ho about IRM, their business partners may not be.

If the Office 2003 strategy works, and organizations start jumping on the IRM bandwagon, it's the ultimate lock-in for Microsoft. Game over for Linux users (and vendors) trying to maintain compatibility with Windows users. This would have the potential of breaking compatibility even for reading e-mail, if you work with Outlook users who enable IRM.

But it also has the potential to cause some significant backlash against Redmond when companies start tallying up the costs of switching and being fully compatible with Microsoft's document DRM. Let's not forget that most organizations are being much more stingy with their tech purchases these days. Many companies are still smarting over Microsoft's "new and improved" licensing programs and the recent security snafus. If SoBig.F wasn't enough to send companies over to Linux, Office 2003 might be the straw that broke the camel's back.

Comments (40 posted)

On giving back

On September 8, LynuxWorks announced the availability of a beta release of BlueCat Linux 5.0. BlueCat is the company's embedded Linux distribution; 5.0, interestingly, is based on the (still unreleased) 2.6 kernel. LynuxWorks claims to have applied a lengthy series of "ISO 9001:2000" reliability tests to this kernel. The PR also cites some of the features of this kernel which are of interest to the embedded community, including kernel preemption, the O(1) scheduler, and the improved threading support. LynuxWorks, they say, is the first embedded systems company to make these features available in a Linux-based system.

The interesting thing, of course, is that all of those features were developed at other companies. Kernel preemption, in particular, was done by Nigel Gamble and Robert Love at MontaVista - a direct LynuxWorks competitor. The extensive testing done by LynuxWorks must certainly have turned up bugs; the 2.6 kernel is still an unreleased product, beta quality at best. Yet no fixes appear to have been sent back to the community. Over the last year, only one posting appeared on linux-kernel from either lynuxworks.com or lnxw.com - a request for help with a compilation problem. The 2.6 BitKeeper repository, containing all patches merged since February 2002, shows one set of patches from LynuxWorks.com: a USB Pegasus driver by Petko Manolov. The last patch was merged in May, 2002. We asked LynuxWorks if it had a list of recent contributions (which could, after all, have been sent in from a different email address), but got no response.

LynuxWorks, in other words, is taking full advantage of the work of others - including its competitors - to claim to be "first to market" with a set of new features. And it has done so without contributing much of anything back to the community from which it draws the software it is selling. LynuxWorks is far from alone in this behavior, of course. LynuxWorks is also acting entirely within its rights. As long as they abide by the GPL, nobody can complain if they use the software in this way. That is what free software is all about.

It is also true, however, that being within your rights and being right are not always the same thing. A company that is making money selling Linux should feel some obligation to contribute back to Linux. Especially when that company is in the operating systems business and clearly has the technical resources to make that sort of contribution.

Contributing back is not just the right thing to do; it is also good business. Customers feel better when they see that their suppliers have a good relationship with the development community upon which they depend. Customers also like the feeling that a supplier understands the software well enough to make changes and get them accepted; it improves that chances that bugs can be fixed and requested changes implemented. They feel better about the software as a whole if the vendor cares enough to make it better. Software with active support from those selling it has a better chance of being around and still maintained a few years from now.

Many free software companies understand this well; they point to their free software contributions as a source of pride. As users of free software become more sophisticated, they will ask for that information. Customers need to know that their suppliers can provide them with the support they need, and that said suppliers are committed to the future of the software they work with. A history of contributing back to the software in question is one of the best ways to show customers what they want to see. It also has the incidental benefits of making the software better and being the right thing to do.

Comments (13 posted)

The Chamberlain v. Skylink DMCA ruling

One of the many DMCA cases circulating in the U.S. court system is Chamberlain v. Skylink. Chamberlain manufactures garage door openers and, of course, the remote units which are used to open and close the garage door. Recent Chamberlain models use a "rolling code" system which is intended to protect homeowners against playback attacks; the code transmitted by the remote is different every time, so a thief with a recorder would capture nothing useful. This system also has the incidental result of preventing other companies from selling remotes that work with Chamberlain openers.

Except that Skylink figured out a way to get around the code, and marketed a working remote. Chamberlain then took Skylink to court, claiming that, among other things, the Skylink remote violates the Digital Millennium Copyright Act. The problem, it seems, is that the Skylink remote circumvents the "technical measures" employed by Chamberlain to restrict access to the copyrighted software in its openers. Chamberlain was sufficiently confident of its position that it asked for a summary judgement on the DMCA argument. At the end of August, the court denied that request; the full text of the ruling is available in PDF format.

One might hope that this case would have been an opportunity for the court to take a serious look at the DMCA. The DMCA, used in this way, is an effective tool to prevent the creation of interoperable products in a wide range of industries. All that's needed is a bit of internal code and a simple "technical measure" to prevent interoperation; the DMCA does the rest. Unfortunately, the ruling in this case does little to help those who would like to see the power of the DMCA reduced.

The court denied the judgement for two reasons. The first is that, in the court's opinion, Chamberlain did not establish that the software inside its garage door opener was actually protected by copyright - a crucial precondition for DMCA applicability. This is a true technicality here; it is difficult to believe that Chamberlain will not have a copyright interest in the software it created.

The second reason is, essentially, that Chamberlain did not tell its customers that they couldn't use competing remotes.

This second point may be enough to sink Chamberlain's DMCA argument, but it leaves the DMCA itself untouched. A simple statement on the box that only Chamberlain remotes may be used with the opener will close the hole in the future. This ruling is a defeat for a company attempting to wield the DMCA for its commercial benefit, but it will do nothing to stop this use of the DMCA in the future.

Comments (5 posted)