Leading items

Sun's Linux rising in China

The biggest news for Linux this week, surprisingly, comes from Sun Microsystems. Sun has reached an agreement with the China Standard Software Company (CSSC) that is aimed at putting Sun's Linux solution, the Java Desktop System (JDS), on up to 200 million desktops throughout China. The agreement is set to begin towards the end of this year, with an initial goal of 500,000 to one million seats per year. There is no specific timeline for the ultimate goal of 200 million desktops, and CSSC will need to improve adoption rates significantly beyond 500,000 per year to achieve that figure in a meaningful time frame.

CSSC is made up of a group of Chinese high-tech companies, with the backing of the Chinese government and a mandate to create a standard Linux desktop system for the Chinese market. We spoke to Peder Ulander, Director of Marketing for Sun Microsystems Desktop Solutions, about the deal with CSSC and Sun's JDS in general. He tells us that CSSC's final product will be based on JDS, but customized for the Chinese market. Ulander didn't specify how CSSC's version might differ, but noted that it will be running on x86-based computers. At the moment, specific information on CSSC's deployment of a desktop Linux system is fairly sketchy. Ulander said that CSSC will be issuing announcements of its own in the near future.

Why not Solaris for x86? Sun has been touting its x86 Solaris offering pretty heavily lately, and it hasn't exactly shown enthusiasm for Linux despite the fact that the company has a number of Linux offerings. Ulander said that Sun made the decision based on time to market. Though Ulander did not say so, another way to read that would be that Solaris for x86 isn't ready for deployment on existing x86 desktop hardware, while Linux is.

Indeed, JDS has relatively minimal hardware requirements. According to Sun, a recommended minimum configuration for JDS is a Pentium II 266MHz or better, 128 MB of RAM and a 4GB hard disk. While some Linux distributions still run on 386s with 8MB of RAM (or less), the target for JDS seems to be computers originally outfitted with Windows 95 or 98. Ulander noted that Microsoft will be discontinuing support for Windows 95 and Office 95 this year, with Windows NT 4 and OS/2 also losing support in the near future. Companies looking for supported solutions now need to look to newer versions of Windows that will likely require newer hardware as well -- or a migration path to a supported Linux distribution.

Sun's distribution uses the GNOME desktop, Mozilla, StarOffice, Evolution and (not surprisingly) includes a Java Runtime Environment (JRE) for Linux. Ulander said that Sun settled on GNOME rather than KDE because of GNOME's focus on accessibility. From what Sun has revealed about JDS so far, there is little to distinguish their Linux desktop solution from other vendors' solutions. Ulander confirmed that JDS consists of the same components that make up most distributions, but said that Sun's "integration" of the software will set it apart from other distributions.

Of course, Sun's offering is different from other vendors in that it isn't branded "Linux." Ulander said that the name "Java Desktop System" was not meant to obscure the Linux underpinnings of the system, but rather to fit in with the rest of Sun's rebranded product line. According to Ulander, Sun has consolidated 248 individual products into six product lines, including the Java Enterprise System, Java Desktop System and so on.

Sun's published prices are $100 per desktop user, or $50 per employee for existing customers of Sun's Java Enterprise System, but CSSC will be paying less to license JDS. Ulander declined to specify how much less CSSC would be paying, but said that Sun was giving CSSC a deal similar to a typical OEM agreement where the company would pay less than list.

In fact, the deal brings a lot of credibility to Linux in general. But it does give bragging rights to Sun as the company to score the largest Linux desktop deal, at least to date, and may give the company leverage to sell other (more profitable) solutions to companies that make the switch. Ulander called JDS "a door-opener," but said that organizations deploying JDS were in no way dependent on Sun solutions on the server side.

Sun's JDS will be generally available in December of this year. Though Sun has secured a significant spot in the Chinese market with JDS, it will be interesting to see how well Sun fares with the rest of the Linux market.

Meanwhile, it's hard to see how adoption of Linux on such a wide scale anywhere in the world could be a bad thing for the community. Sun was not the only company having talks with CSSC, indicating that CSSC had already settled on Linux, but hadn't decided on a vendor. While Sun may tout this as a success for their business, and it is, it really emphasizes the maturity of Linux as a desktop solution.

Comments (6 posted)

SCO update

It has been a busy week or so in the SCO case. Time to catch up with all that has been happening.

The company has filed a new Form S-3 as part of the BayStar deal. That deal allows for a conversion of BayStar's preferred stock to the regular variety, so SCO had to go through the motions to register another 3.85 million shares for sale. As usual, these filings give a rare window into what is happening inside a company.

In this filing, SCO revealed (though not in so many words) that its fourth quarter results are going to be horrible. The company did (as was disclosed previously) get another $8 million from Microsoft for a "broader" Unix license. But the company will have to record a charge of $8.7 million related to the BayStar deal. The company also will take a $9 million hit to account for the $1 million in cash and 400,000 shares of stock that it has given to its lawyers. As a result, the company's income will be $17 million lower than it would otherwise have been. It does not look like a profitable quarter for The SCO Group.

SCO's law firm (Boies, Schiller & Flexner LLP) will be taking on the company's defense in the Red Hat case, and in IBM's countersuit as well. There was a great effort to put a positive spin on things at SCO's November 18 conference call (transcript available here); it is claimed that SCO will be setting Boies et al. on Linux end users within "the next 90 days." These, it is claimed, will be direct copyright suits, based on a whole new pile of "directly copied" code that has been found lurking somewhere in the Linux kernel. Of course, they can't tell us where that code would be.

The conference call hinted that, if SCO does really decide that it needs more legal battles, it is likely to go after HP customers. There was much satisfied talk of HP's indemnification offer, and speculation as to whether HP would pay license claims directly or choose, instead, to defend a lawsuit. As had been predicted months ago, HP's indemnification offer may well have just served to turn that company - and its customers - into low-hanging fruit for an SCO legal offensive.

SCO has finally spoken out on Novell's acquisition of SUSE. That deal, says SCO, would violate Novell's non-compete agreement with SCO. If the acquisition goes forward, SCO claims it plans to take action against Novell. Happily for us, the agreement in question is available on the net; the relevant text (section 1.6) reads:

If you buy SCO's argument that Linux is Unix with the serial numbers filed off, then SCO might actually have a leg to stand on here. If, instead, you believe that Linux is Linux and SCO has no right to steal it, SCO's non-compete argument makes no sense. The non-compete agreement only applies to what Novell does with Unix.

In the Red Hat case, SCO continues to try to get the suit thrown out, or, at least, to delay things. Given the "90 days" discussion in the teleconference, SCO's position that it has not threatened to sue anybody appears to be even shakier than before. This case is now waiting for a ruling from the judge on the various motions.

In the IBM case, the November 21 conference before the judge looms. If it still appears that SCO is failing to respond to IBM's discovery requests, oral arguments will happen on December 5. Sometime thereafter, SCO could find itself compelled by the judge to put forward its evidence or shut up. SCO may try to draw its own motion to compel discovery into the discussion as well.

SCO's supplemental responses to IBM's requests included some amusement in the form of a list of files that, according to SCO, contain its property. The file list looks like:

	arch.i386.kernel.i8259.c
	arch.i386.kernel.timers.timer_tsc.c
	arch.i386.mach-default.topology.c
	arch.i386.mach-pc9800.topology.c
	arch.i386.mm.discontig.c

And so on. Many people wondered why the files were listed in this sort of "flattened" form until it was pointed out that SCO's Unix offerings lack a version of "grep" which can do recursive searches. They had to have some poor intern rename all of the files into a single directory so that they could search through them.

Their searches were simplistic, to say the least. One of the files listed was (in standard Linux naming format) include/asm-m68k/spinlock.h, the entire contents of which are:

    #ifndef __M68K_SPINLOCK_H
    #define __M68K_SPINLOCK_H

    #error "m68k doesn't do SMP yet"

    #endif

One does, indeed, wonder how Linux was able to compete before IBM stole all that nice SCO technology. Seriously, though, it appears that SCO did a simple grep for "SMP" and listed every file that popped up with no regard to what was contained therein. Thus we see the quality of SCO's evidence.

Recent rhetoric from SCO has brought with it an interesting change: the company is now, repeatedly, talking about the old USL v. BSDI settlement. For those who have not yet seen it, taking some time to read the ruling which led to that settlement may be worthwhile. The introduction in the "statement of facts" is eerily familiar:

"Allegedly proprietary" is the judge's wording. This judge concluded that USL had failed to show that any copyrights or trade secrets in Unix could be enforced. The subsequent settlement freed the BSD code base for distribution. SCO is the successor to USL; why it wants to reopen this case at this time is currently a mystery. There have been occasional hints from SCO that it plans to go after BSD in the future; perhaps they are trying to tell us that this attack is getting closer. One publication quoted Darl McBride as saying that suits against BSD could happen in the first half of next year.

Where things will go from here is anybody's guess. The motions to compel in Utah and Red Hat's suit in Delaware could bring things to a head relatively quickly. Counting on the U.S. justice system to bring this situation to a quick conclusion is risky, however. We may be fighting this battle for some time yet.

Comments (14 posted)

Governmental open source directives in Italy

At the end of October, the Italian Dipartimento per l'Innovazione e le Technologie ("Department of Innovation and Technology") issued a press release (in Italian) regarding a new set of directives for the use of open source software in the public sector. The actual directives are not yet available - they will not be released until officially published by the government - but the press release gives an overview of what will be there. Italy, it seems, is trying to put itself at the forefront of governments adopting free software.

The following are the key points, painfully translated by your editor:

Comparative analysis of solutions: The "Stanca Open Source Directive" [Lucio Stanca is the minister responsible for all this] requires that public administrations must acquire software based on comparative technical and economic evaluation of the various solutions available in the market, taking into account the administration's needs, but also taking into account the possibility of developing specific programs in-house (or under contract) and the reuse of special-purpose programs developed in other agencies.

The evaluation must consider also the total cost of ownership and the cost of exit from each solution, but it must also consider the possible interests of other agencies in reusing the chosen solution. In cases where proprietary software is to be licensed, the administration must obtain a contractual guarantee that, if the vendor becomes unable to support the software, the source code and relevant documentation will be made available.

Technical criteria: public agencies, when acquiring software, must favor solutions which:

• Assure interoperability and cooperation between the various computing systems of the public administration, with the exception of situations requiring particular security or secrecy.
• Render information systems independent of a single vendor or a single proprietary technology.
• Guarantee the availability of source code for inspection and traceability by the public administration.
• Export data and documents in multiple formats, of which at least one is an open format.

Ownership of software: In the case of programs developed for a specific purpose, the commissioning agency will acquire the ownership of the software given that it has contributed out of its own resources to the identification of the requirements, the functional analysis, the control, and testing of the software implemented by the vendor.

Transferability of software licenses: Public administrations will obtain contractual assurance of their ability to transfer software licenses in case that agency replaces the program with another performing the same function.

Reuse: In order to encourage reuse of software owned by the administration, the project goals and specifications must allow for portability to other platforms. Contracts for software developed at public expense must include clauses that commit the vendor to making available services to enable the reuse of the software.

Interestingly, this "open source directive" says almost nothing about open source licensing; it is more focused on specific goals: software reuse, ability to inspect the code, ability to switch to a different solution. This is a good thing, of course; wiring specific licenses into the law is probably not the right way to go. The directive also says nothing about open source licensing for software developed for the government; as long as the software can be reused within the government, the rules will be satisfied.

There is little consensus on how strongly governmental bodies should be encouraged - or forced - to use free software. But it is hard to argue against criteria that call for interoperability, software reuse, and the ability to avoid being bound to a single vendor. It will be interesting to see what sort of software mix the Italian government ends up with after these rules have been in force for a few years.

Comments (3 posted)

On comment abuse

We resisted the idea of allowing reader comments on the site for years out of concern that some people would post things which detracted from the quality of LWN. A year and a half ago, we decided that we could trust our readers to do the right thing, and our experience since then has largely verified that decision. More recently, however, we have begun to have problems with comment spammers and trolls. The problem is small, for now, and a bit of carefully targeted firewalling appears to have slowed the latest troll down considerably. We have been on the net for long enough to know, however, that problems of this sort rarely get better by themselves. Instead, they tend to get steadily worse until the signal is drowned out by the noise. We do not intend to let that happen to LWN.

So we are going to have to do something; it's just a matter of figuring out what. There are a few options under consideration; we would appreciate feedback from our readers on which idea seems best.

• One option is manual moderation of comments by the LWN editors, perhaps augmented by a small number of trusted readers. The problem with this approach is that we really do not want to get into the business of censoring comments. It is an unpleasant occupation, and active control of comments might open us up to interesting liability issues.

• We could implement a reader moderation mechanism which would allow the trolls and spam to sift to the bottom of the pile. In the long term, this might be the best solution. It will require some significant site hacking to implement, however, and it will put strains on the database that will force a server upgrade (which is increasingly necessary anyway).

• Comment posting privileges could be restricted to subscribers. This one is trivial to implement. It would have the effect of silencing non-subscribers, however. Currently about 1/3 of the comments on the site are posted by non-subscribers, and almost none of those are abusive. Closing out non-subscribers would deprive us of a lot of good comments to get rid of a small number of bad ones.

• A preference flag could be added to allow readers to filter out comments by non-subscribers. This would be less draconian than silencing non-subscribers outright, but it still punishes a large community of readers for the behavior of a very small number of people.

The decision we make here will affect the feel of LWN.net into the future; we want to do the right thing. If you have any thoughts on the matter, we encourage you to post them as a comment to this article (no trolls or spam please).

Comments (88 posted)

Come back early next week

Next week's LWN.net Weekly Edition will be published on Wednesday, November 26 (one day earlier than usual) so that we can enjoy the Thanksgiving holiday. LWN is important, but pumpkin pie wins every time.

Comments (2 posted)

Page editor: Jonathan Corbet
Next page: Security>>