Leading items

Novell acquires Ximian

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

Every time there's a trade show, there's also a flurry of predictable press releases. New products, product upgrades, new partnerships and so on. But sometimes, a company manages to sneak in a surprise. Novell managed to throw the community a curve during the first day of LinuxWorld Expo by announcing that it had acquired Ximian. Novell executives have also hinted that the company may stop developing NetWare to focus on Linux in the future.

Earlier this year, Novell announced that it would be expanding its Linux offerings, but the announcement was met with some skepticism and concern that Novell's committment to Linux was half-hearted, particularly after an early flub where Novell CEO Jack Messman called Linux "immature." Messman soon apologized, and it would appear that Novell is quite earnest in its committment to Linux.

On Tuesday, I spoke to Miguel de Icaza of Ximian about the acquisition and plans going forward. De Icaza said that Ximian and Novell had already been working together as partners on some projects before Novell made the offer to buy Ximian.

For the time being, expect Ximian to pretty much stay the same course as it was on before the acquisition was announced. De Icaza says that Ximian will operate as an independent subsidiary of Novell and continue with its existing schedule, and deliver the products that were in the pipeline before the acquisition. Evolution, Ximian Connector, Red Carpet, Mono and Ximian Desktop will continue to be developed. Long term, he indicated that there would be tighter integration between Novell's offerings and Ximian's.

Though it wasn't mentioned in Novell's press release, de Icaza says that Novell will also be developing its own Linux distribution in addition to making its products available for other Linux distributions. Few details are available about this new Linux distribution, and de Icaza said that they had not yet established a timeline for the first release. Obviously, users can expect to see the Ximian desktop and tight integration with Ximian's Red Carpet, but details about the remainder of the distribution are sketchy at the moment.

According to de Icaza, one advantage of a Novell Linux distribution is that it would give Ximian the opportunity to delve deeper into the operating system. He noted that Ximian has been somewhat limited in the features they could implement, since Ximian Desktop and other Ximian products had to integrate with other distributions whose development wasn't under Ximian's control. Making modifications to the kernel, for example, wasn't really an option.

Novell will also give Ximian's product line a shot with customers that the company found it difficult to reach before teaming with Novell. The enterprise channel is tough to break into, and de Icaza indicated that Ximian had previously found that larger companies to be nervous about deploying Ximian solutions. As part of Novell, Ximian's products are now considered less risky because customers know Novell.

Overall, the merger looks to be a good deal for Ximian, Novell and the Linux community as a whole. While Novell's influence has been waning, the company still maintains a respectable presence in the enterprise market. The addition of Novell services to Linux's bag of tricks will definitely help spur Linux adoption on both the desktop and the server in larger companies. On the other side, the acquisition of Ximian may help give Novell a little more credibility with the existing Linux community and help them to get up to speed with Linux more quickly.

Comments (7 posted)

Red Hat strikes back

Last week, we wrote that SCO's anti-Linux campaign was not just IBM's problem, and that others needed to get into the fight. Red Hat, clearly, was thinking along the same lines; on August 4 the company announced the filing of a lawsuit against SCO in U.S. District Court in Delaware. Also announced was the creation of a fund (with a $1 million contribution from Red Hat) to defend Linux developers against infringement suits. Red Hat, seeing a threat to its business, decided to act. SCO, indeed, is not just IBM's problem.

The lawsuit alleges unfair competition, trade libel, deceptive trade practices, false advertising, and interference with business opportunities. It asks for a declaratory judgement that Red Hat has not violated SCO's copyright or trade secrets, and asks for an unspecified amount of damages. LWN has published a look at Red Hat's complaint; for those wanting to go to the source, the complaint itself is available in small, easily-read text format or huge, hard-to-read PDF format.

There is one interesting omission from the complaint. SCO continues to distribute a 2.4 kernel. This action is a clear violation of the GPL (SCO claims that kernel cannot be redistributed, or even run without a special license - see below), and thus an infringement of the kernel developers' copyrights. Red Hat (along with its employees) holds copyrights to a substantial amount of kernel code, but no allegations of infringement appear in Red Hat's complaint. Red Hat told us it was "unable to comment" about this omission. The GPL and SCO's continued distribution of the disputed code (whatever it is) under a GPL license will almost certainly play a role in this whole affair before it is done, but the time has apparently not yet come.

SCO's response to Red Hat's suit was unyielding, to say the least.

The response includes a letter sent back to Red Hat; quoting from there:

Remember, as you read the above, that SCO "has not been trying to spread fear, uncertainty, and doubt."

If things go well, Red Hat's suit has the potential to force SCO to put its cards on the table and point out the code that, it claims, infringes upon its copyrights. At that point, it would be possible to actually evaluate those claims and determine the true origins of the disputed code. If SCO has no real claim to that code, the issue can be put to rest. If SCO's copyrights have truly been violated, the parties responsible can be identified and the stolen code excised. Of course, SCO has no interest in either of those scenerios, and will continue to fight any sort of public disclosure. It would not be possible, after all, for SCO to try to collect a tax on a system known to be free of its copyrights. But that's the subject for the next article...

Comments (4 posted)

The SCO tax

SCO did not content itself with threatening the "long-term survivability of Linux" after Red Hat filed suit. The following day, the company announced its latest product: an "intellectual property license for Linux" (license text here). Why, one might ask? From the SCO License FAQ:

It is encouraging that SCO is such a concerned, customer-oriented company. In fact, the company is even kind enough to offer a special "promotional" pricing arrangement for those who buy their licenses before October. Prices vary; a "desktop" license is $199, for a single-CPU server it's $699; for eight processors it goes up to $4999. Embedded devices get a special $32 price - but that's still enough to hurt when added to your wireless access point or video recorder.

After the promotional period ends, prices will double.

Of course, certain questions come to mind. Questions like "why the hell should I pay off a company to use my nicely GPL-licensed software when that company refuses to show me any proof that it has any claim on said software?" Strangely enough, this question does not appear in the SCO licensing FAQ.

For what it's worth, even the Gartner Group has been quoted as recommending that potential licensees not bother until the Red Hat suit plays out.

SCO, perhaps, thinks it is sitting on some sort of gold mine. All it has to do is make a tax on every Linux installation stick, and enough gold will flow to Utah to fill Canyonlands. There's only one little problem: if it were ever to become clear that Linux users actually had to pay this tax, all distribution of Linux would have to immediately stop. Distribution of a non-free Linux kernel would be a clear GPL violation, and there is little doubt that some holders of Linux copyrights would sue, if necessary, to prevent their code from being distributed as part of a proprietary product. Even SCO acknowledges this fact in its FAQ:

So, if SCO somehow makes its license stick, it kills the whole game. Linux distribution would cease, and companies, seeing no future in Linux, would switch to something else rather than pay exorbitant fees for a dead-end system. Given that scenario, it is hard to come up with reasons why SCO would attempt this licensing program in the first place. With the application of sufficient imagination, however, a few possibilities can be found:

• The purpose of the licensing program may just be to attract attention and, with luck, a bit of short-term cash. Perhaps it is not expected to last very long.

• Perhaps SCO thinks that the momentum and installed base of Linux are big enough that a way around the GPL problems would have to be found.

• Or, perhaps, the death of Linux is the real goal.

In the short term, however, it's a fairly safe prediction that this licensing program will not go very far. Most users are far from convinced by SCO's claims, to say the least. And SCO has very limited resources to direct toward new legal battles; the company is, after all, fighting two high-profile cases already. Of course, if you are concerned about the issue, you should get your advice from a lawyer, not from web publications like LWN.

Comments (10 posted)

The indemnification issue

SCO has, in recent days, made a big issue out of the fact that IBM and Red Hat do not indemnify their customers against any sort of intellectual property infringement committed by use of Linux. This refusal is, it is said, is a clear indication that these companies know they are on thin legal ice. Indemnification is a distraction from the main issue (being that SCO claims its code was stolen and put into Linux), but it deserves a closer look anyway.

A number of articles in the press have portrayed the refusal to indemnify as a strange thing, out of line with usual software industry practice. The authors of those articles clearly have not read the license agreements for the software they used to do their writing. It is a rare product indeed that comes with an indemnity agreement. Consider Sun, for example. This company has made indemnity an issue, but if you go read the Solaris binary code license agreement, you find this text:

(Emphasis added). Sun clearly is not interested in exposing itself to infringement claims. Microsoft's licenses are just as explicit, as are just about everybody else's. In fact, SCO's intellectual property compliance license for Linux contains the following language:

SCO, it seems, is even more explicit than Sun in this regard. When SCO criticises another company for refusing to indemnify its customers, its behavior can only be described as cynical and hypocritical.

So why the big push on indemnification? The issue is clearly a useful distraction from the main issue: SCO's refusal to provide evidence for its claims. There is also a darker possibility, however. Imagine, for a moment (and the following is pure speculation), that SCO's pressure convinces one or more deep-pocketed companies to offer indemnity for its increasingly nervous customers. If SCO were then to put those customers at the top of its lawyers' "to hassle" list, said customers would go immediately to their vendor, asking for relief under the promised indemnity. SCO could then, perhaps, collect a hefty sum from the company involved; said company, under pressure from its customers, may well capitulate in that situation.

In SCO's teleconference this week, CEO Darl McBride said "IBM and Red Hat have painted a Linux liability target on the backs of their customers." (Do remember, hard though it may be, that SCO is not trying to spread fear, uncertainty, and doubt). A real possibility exists that the customers who are targeted first will be those whose vendor has been pushed into offering some sort of indemnity. Linux users may well be better off with the standard "no warranty" language.

Comments (1 posted)

UCITA runs out of steam

LWN first reported on UCC-2B, a proposal for a uniform law on software licensing (and other intellectual property issues), over five years ago. UCC-2B proposed to legitimize "shrink-wrap" licenses - even if the license is hidden within the box and unavailable to the customer until after the product is purchased. Some of the worst abuses of software licensing, such as prohibitions on the publication of benchmark results or "unauthorized" product reviews and bans on reverse engineering, would have, in theory, been legalized by UCC-2B.

Things got more interesting in 1999, when UCC-2B evolved into UCITA. At this point, the drafting committee added nice features like the (legal) ability to disable software remotely, non-transferability of licenses, and more. UCITA was eventually passed (in modified form) in two U.S. states, but appeared to stall otherwise. It was, after all, not a very good law.

In 2002, the UCITA folks tried again with a series of amendments to the law. Remote shutdowns were taken out, and the provisions allowing the prohibition of public criticism of the software were watered down slightly. But the new version also changed the terms on warranties, to the point that it would be impossible for a free software product to ship with a warranty disclaimer. UCITA remained a bad law.

Things took a turn for the worse (from the point of view of those backing UCITA) in early 2003, when the American Bar Association (the professional association for lawyers in the U.S.) refused to endorse UCITA. Versions of the law were introduced into several state legislatures, but made no real progress. UCITA, it seemed, wasn't going anywhere.

This week, it would appear that UCITA has hit the end of the road: the National Conference of Commissioners on Uniform State Laws has voted to shut down the UCITA committee. UCITA has ceased to be an active effort in the U.S.

There is a worthwhile lesson in this development: it is possible to defeat bad laws, at least some of the time. We should not forget another, hard-learned lesson, however: this sort of proposal tends to come back, over and over again. Consider the words of the NCCUSL president:

The clearest thing here is that the people behind UCITA have learned little from its defeat; UCITA is "the right thing at the right time." UCITA is gone for now, but it shall certainly be back.

Comments (3 posted)

Page editor: Jonathan Corbet
Next page: Security>>