On Microsoft's patent claims
By now, most LWN readers will have seen
this
Fortune article in which a Microsoft representative makes the claim
that Linux distributions violate 235 of its patents. This article has
caused a fair amount of concern in the community, with some people seeing
it as the beginning of some sort of Final Battle between Microsoft and free
software. That might even be the case, but the true nature of the
situation is far from clear. Here's a few thoughts on Microsoft's claims.
To begin, these claims are not exactly new. Consider what the BBC was
reporting in November, 2004:
Reuters said chief executive Steve Ballmer told Asian leaders Linux
violated at least 228 patents. The Linux community disputes these
claims. Mr Ballmer said countries using Linux which entered the
World Trade Organisation would be at risk.
So this is not the first time we have heard this sort of charge from
Microsoft; perhaps the only real difference is that we have somehow managed
to find another seven patents to infringe upon in the last 2-1/2 years.
The possibility exists that we may not hear any more about this "violation"
for another two years or so - but one shouldn't necessarily count on that.
As companies go, Microsoft is relatively uninclined to pursue patent
infringement suits. There was an interesting quote from the Open Source
Think Tank report (covered
here last week):
Sam [Ramji] defended Microsoft from the accusation that its deal with
Novell will lead to Microsoft suing other Linux distributors for
patent infringement. Sam described Microsoft's patent portfolio as
primarily defensive--at any given moment, Microsoft is the
defendant in 25-35 patent lawsuits, and that Microsoft has
offensively sued another party for patent infringement only twice
in its history.
Microsoft has, indeed, spent more time being the victim of patent trolls
than a patent aggressor itself - and it has lost vast amounts of money to
patent judgments in the process. This company has little to gain by
heating up the patent litigation scene even more. That said, one should
see the remainder of the quote above:
Sam emphasized that Microsoft has robust patent licensing programs,
and would much rather license its patents than sue.
Even if we believe that Microsoft will take a relatively enlightened
approach as a result of its time at the defendant's table, we should not
lose track of an important fact: companies whose core business goes away
have a disturbing tendency to turn to their "intellectual property"
portfolios as a way to keep the revenue flowing. Should Microsoft someday
decide that Linux world domination really is inevitable, it could
react in any of a number of unpleasant ways.
The SCO Group's attack on Linux holds a number of lessons which can be
applied to any future Microsoft attack - but those lessons only go so far.
There is no doubt that interesting things will happen if you anger our
community, especially if you attempt to lay claim to our work. There would
be a massive outcry, publicity campaigns, boycotts, and an extended effort
to invalidate as many of the patents as possible. Microsoft clearly fears
the capabilities of the wider community; the Fortune article notes that
Microsoft is not disclosing its specific patents "lest FOSS advocates
start filing challenges to them." But invalidating even a single
patent is hard; invalidating 235 would certainly tax even the capabilities
of our extended community.
On the other hand, Microsoft would have to name specific patents in any
legal action, and, presumably, it would not base a suit on all 235
patents. There is also the unknown effect of the recent U.S. Supreme Court
ruling in KSR International v. Teleflex; this ruling has raised the bar on
the amount of innovation a patent must contain. Some have speculated that
this ruling could lead to the end of software patents altogether. That
seems like wishful thinking, but it should help those who seek to
invalidate many of the software patents currently on the books.
In the SCO case, a weak and incompetent company took on the strongest
target it could find, and that target chose to stand its ground. There are
no guarantees that things would go the same way this time around.
Microsoft is strong financially and has a large, seasoned legal operation.
It may well choose to attack smaller companies which cannot afford to put
up an extended fight. In theory, a patent attack against Linux should
evoke a strong response from the companies working with Linux, many of
which hold considerable patent portfolios of their own. In practice, we
will never know who would jump into that fight until they make their move.
In particular, a defense which challenges the validity of software patents
in general could be seen by a number of potential allies as being against
their interests.
We should, at least, be able to count on the intervention of the Open Invention Network,
which was formed for just this purpose. If OIN's patents are as strong as
some believe, the resulting fireworks should be worth watching - from a
safe distance.
There are a few other interesting things to keep in mind. Software patents
are a U.S. problem, primarily; a successful patent attack against Linux
could have the effect of driving its developers and users out of the
country. Linux is now sufficiently firmly entrenched that attacking its
users or developers could cause extended chaos - it might even upset more
people than threatening to shut down the Blackberry network. That, in
turn, could inspire more thought on the true costs and benefits of the
current patent regime in the U.S. Some people believe that, by selling
Novell's coupons, Microsoft has become a Linux distributor and is now
subject to the terms of the GPL. Any serious attempt by Microsoft to bring
down Linux would bring renewed attention from the world's anti-trust
authorities.
Clearly, there are quite a few unknowns here.
What it all comes down to is that, sooner or later, this may well be a
battle we cannot avoid fighting. Once it hits, there is no telling where
things will go. About the only guarantee is that it is certain to be
interesting.
Comments (25 posted)
The sincerest form of flattery
Sun Microsystems has made a big show of its open source Solaris release and
its attempts to build a working development community around that system.
So a number of members of the OpenSolaris community were rather surprised
when the press started running
articles
stating that Sun had decided to embark upon a project to make Solaris look
more like Linux. This community was of the opinion that, if it was
expected to endorse and participate in "Project Indiana," it might have
been nice to know before Sun employees started talking to the media about
it.
The person behind this effort, of course, is Ian Murdock, formerly of the
Linux community. His position now can be understood from this
interview:
When people say they want Linux, they don't actually mean they want
Linux. What they want is the Linux userland user environment and
the Linux business model. They want choice. They want the Linux
distribution and I'm the Linux distribution guy.
Project Indiana, it seems, is Sun's attempt to win over all of those people
who only think they want Linux, but who really want a version
of Solaris that looks likes Linux.
Many of the goals of this project, as far as they can be determined at this
early stage, would seem to make sense. Better package management, for
example. More device drivers. Easier installation. A more Linux-like
user space with our (relatively) bleeding-edge 1990's shell. And, says Ian, a switch to timed release cycles:
The big feature from my point of view though is the 6 mo. timed
release cycle. Timed release cycles have done wonders to introduce
predictability into other open source projects (e.g., Gnome,
Ubuntu). And 6 mos. is the clear winner in terms of frequency among
Linux community/developer distros--it's just enough time to do
interesting work AND have a reasonably long hardening period so the
thing is stable.
Ubuntu comes up frequently in the discussion; it's clear that some people
at Sun see Ubuntu as a model worth emulating.
For those of us who have been working with free software for a while, there
is a certain irony in this whole plan. A Linux-like Solaris is not a
particularly new concept; for many years, that's how much of the community
experienced free software. Before there was a Linux system in a reasonably
usable state, the best system to have on one's desk usually came from Sun.
As soon as it came in the door, however, it would be loaded up with crucial
packages like the X Window System, gcc, netrek, emacs, and so on. Many
years ago, we all had systems which, in some ways, looked like what Project
Indiana is trying to build now. Those systems did not keep an awful lot of
us from jumping to Linux, though, and their cost was only part of the
reason for switching.
We switched to Linux because it was free, alive, fun, and clearly going
places. There was always something new and interesting happening,
especially in those days when running development kernels on production
systems was a necessary part of making things work. All these years later,
there is still always something new and interesting, and, often, it even
comes nicely packaged on a regular schedule. Not many of us are looking
back to the systems we used to run.
So it is no surprise that the folks at Sun are putting such a big emphasis
on trying to duplicate the things that Linux does right. A similar user
space, timely releases, easy upgrades, and, especially, the creation of a
vibrant community around Solaris. The thinking seems to be that, if they
make a system which looks like Linux but which contains their kernel (which
they feel to be superior - a view which is not universally shared in the
Linux community), the world will flock to their door.
There have been no real (public) decisions on how this project will
proceed; the process for creating an official OpenSolaris project has not
yet begun. There has been some initial discussion where it has been
suggested that the project start by adopting the work of either BeleniX or Nexenta. This idea drew an immediate
complaint from our old friend Jörg
Schilling, creator of SchilliX,
but it appears that the OpenSolaris community listens to Jörg about as
much as the Linux community does. Regardless, it will take some time
before the real shape of Project Indiana emerges.
It will take even more time before we see if this project has any real
impact. Certainly it should make life easier for Solaris users. But "a
better Linux than Linux" is not a particularly compelling sales message.
It might just turn out that people who say they want Linux actually want
Linux, not another system dressed up in similar clothes. Imitation may be
the sincerest form of flattery, but it is usually a poor way to regain
one's past prominence.
Comments (48 posted)
ATI starts to come around?
A fair number of LWN readers have wondered: why hasn't LWN posted anything
about the statements by ATI at the Red Hat Summit to the effect that it
would be changing its relationship with the open source community?
Certainly this is a relationship which could use some reworking; ATI has
been one of the most stubborn vendors in its refusal to release free
drivers or the programming information needed to let us create those
drivers ourselves. As a result, free support for ATI's older hardware has
required reverse engineering efforts - and the current chipsets have no
free support at all. So, one would think, a statement from ATI that it
plans to change its approach would be a welcome change.
As it happens, the developers in charge of making graphics work on Linux
systems are pretty much unanimous in their lack of enthusiasm. This is not
the first time that ATI has made promising sounds, but, so far, the
corresponding actions have not been forthcoming. Graphics hacker Dave
Airlie is particularly unimpressed, noting
that ATI has not yet bothered to communicate its intentions to the
developers:
As for working with the community I'd expect they'd at least try
talking to the ppl who maintain the ATI open source driver if they
intend on doing something with it...
Dave is particularly annoyed because he has been sitting on the code which
implements 2D support for the R500 chipset for many months while waiting
for ATI to give him permission to distribute it. There is no ATI code in
this driver; Dave is asking permission because he signed a non-disclosure
agreement with the company. So far, that permission has not been granted.
Until that changes, it's hard to believe that ATI is interested in free
support for its hardware.
There is one thing which has changed: ATI is now part of AMD.
Historically, AMD has been much more friendly toward the free software
community. It could well be that this approach is now filtering down
through ATI and could result in some real changes. But we should not
celebrate too much until ATI follows its words with some concrete actions.
Comments (7 posted)
Waiting for Emacs 22 (and looking forward to Emacs 23)
The much-delayed Emacs 22 release has been covered here a couple of times
recently. Since the last article, it would appear that the Emacs process
has hit its lowest point, and things should be getting better from here.
In the long term, though, the Emacs developers may have to take a hard look
at their release management process if they want to keep the project
healthy.
The low point was probably sometime around when Richard Stallman got tired of people asking when a release
might happen:
I have been insulted and abused many times here lately. I did not
respond to most of these insults, but I did take offense.
A number of developers responded that they had no intent to insult or
abuse, but that they do have real concerns about how the process works. A
couple of examples:
The current feature freeze has now lasted for more than 3 years,
during which Emacs _development_ has practically been at a
stand-still, so it is no wonder your team of _loyal_ developers is
getting frustrated and starts to question your principles, and may
start looking for other (more productive) projects to work on.
(Kim Storm).
I learned a bit of lisp, applied some basic color scaling theory,
and produced a patch which added great new functionality.... That
was Summer, 2001. Six years later, and the fruits of my early toil
still aren't available in any released version of Emacs. So, while
I continue to maintain a personally relevant programming mode, and
contribute bug fixes where they impact that mode, I have not taken
on any other "feature improvements" to Emacs. To me, the value
equation just doesn't compute.
(JD Smith).
Clearly, the extended Emacs development cycle is proving frustrating for
developers. The situation with the Linux kernel was once similar; changes merged
at the beginning of a development cycle could take years to make it to a
stable release. In that case, distributors responded by backporting
changes into older releases, but that doesn't happen with Emacs.
The good news is that the biggest blocker - some questions about whether
the Python mode code could be distributed by the FSF - appears to have resolved itself in the best
possible way: the code has been cleared. Inevitably, there's another bug
or two in need of squashing before the release can happen, but the
remaining wait should be relatively short. Hopefully.
Some of the Emacs developers are already looking forward to the
Emacs 23 development cycle. One of the first things that may go in is
multi-tty support,
which allows a single emacs instance to drive multiple terminals or X
connections. This code apparently still does not work on all
architectures, though, meaning it needs some work before it is truly ready.
The other big change is a complete rework of character set handling; only
Emacs would come with a news item reading "The Emacs character set is
now a superset of Unicode. (It has about four times the code space, which
should be plenty)." There's a lot of other work waiting to be
merged, but getting the unicode-2 branch and multi-tty working together
looks like it should be enough to keep the developers busy for a little
while. Happily, they are starting to think about this sort of challenge
rather than wondering if their previous work will ever be released.
Comments (16 posted)
The Open Source Business Conference
The
Open
Source Business Conference is happening on May 22 and 23.
For the first time, LWN will be present at this event. Look next week for
coverage on what's happening on the business side of Linux.
Beyond that, your editor somehow got talked into sitting on a
panel dedicated to the question "is the Novell-Microsoft deal good for
open source?". Given recent events, one might expect interest in this
topic to be high. It should be a memorable experience; your editor can
only hope that there is a pub within quick walking distance of the venue
for the post-event recovery process.
Comments (none posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Critical Samba vulnerabilities; New vulnerabilities in bind, samba, and squirrelmail.
- Kernel: 2.6 and the user-space ABI; LogFS; Scatterlist chaining.
- Distributions: No Pidgin for Slackers; new releases BLAG 60001, openSUSE 10.3 Alpha4, OpenVZ live CD, rPath Linux 1.0.6; A Guide to Virtualization on Mandriva Linux 2007 Spring
- Development: Interview with three OpenChange project developers,
KDE 4.0-alpha1, Firefox eBay extension,
new versions of MySQL, Samba, CUPS, Ardour, LASH, Sonic Visualiser, Jitterbit,
PythonCAD, RRDtool, Konch, SQL-Ledger, Wine, Amuc, nova, HylaFAX,
GCC, Parrot, GPL Ghostscript, Bugzilla, SDCC.
- Press: Microsoft patent rumbles, Free advice for the litigious, Red Hat Summit
coverage, KOffice ODF Sprint, Libre Graphics Meeting, Firefox Support Forums,
the demise of Progeny, who leads real-time Linux?, GPLv3 and Apache license
merging, James Gosling interview, the Linutop mini PC.
- Announcements: Two new FSF initiatives, CrossOver 6.1, DMCA requires DRM?, Intel 965GM drivers, TimeSys supports 2.6.21
kernel, IMF 2007 cfp extended, webinar on GPLv3, Maker Faire, Mozilla
Developer Day Paris, Firefox and Thunderbird mailing lists, Polish KDE site,
Mozilla Corporation Weblog.
Next page:
Security>>