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
(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
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.
We're making money on the deal, but when you look at it this deal is not
about, "cool we closed a deal," it's a market-tipping deal, setting the
standard... This is a landmark deal. A fairly large region investing in
this space, it brings a lot more credibility to what we're doing...
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
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)
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:
Seller [Novell] agrees that it shall use the Licensed Technology
[Unix] only (1) for internal purposes without restriction, or (2)
for resale in bundled or integrated products sold by Seller which
are not directly competitive with the core products of Buyer [SCO]
and in which the Licensed Technology does not constitute a primary
portion of the value of the actual bundled or integrated product.
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.
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
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:
#error "m68k doesn't do SMP yet"
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:
The central issue here is whether Defendants BSDI and Regents
appropriated parts of Plaintiff's allegedly proprietary program
"UNIX," and then used and distributed these parts without
authorization in violation of Plaintiff's copyrights and trade
"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)
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
- 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
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)
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
- 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
- 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
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
Comments (88 posted)
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>>