Back in January, Red Hat reversed a longstanding policy and allowed the
Mono .NET implementation into the Fedora distribution. A set of Mono
applications (Tomboy, Banshee, F-spot) also went in at that time. The move
was generally welcomed, but a number of observers wondered what had changed
to make the addition of Mono possible. The sticking point had been a set
of patents on .NET held by Microsoft; presumably those patents were no
longer seen as a threat. But no information on why that might be was
released at that time.
We missed it at the time, but Fedora hacker Greg DeKoenigsberg posted an explanation in late
March. The answer, as it turns out, may offer some clues of how the
software patent battle might play out.
Back in November, the Open Invention Network (OIN) announced its
existence. OIN is a corporation which has been set up for one express
purpose: to acquire patents and use them to promote and defend free
software. The OIN patent policy is this:
Patents owned by Open Invention Network will be available on a
royalty-free basis to any company, institution or individual that
agrees not to assert its patents against the Linux operating system
or certain Linux-related applications.
The list of "certain Linux-related applications" is said to exist, though
it has not, yet, been posted publicly. But Mono is apparently on that
list. So anybody who files patent infringement suits against Mono users,
and who is, in turn, making use of technology covered by OIN's patents is setting
himself up for a countersuit. Depending on the value of the patents held
by OIN, that threat could raise the risk of attacking Mono considerably.
That last sentence is important: a potential OIN countersuit will only have
a deterring effect if OIN's patents cover an important technology and look
like they would stand up in court. As it happens, OIN holds a set of
patents covering a number of fundamental aspects of XML-based web
services. These patents (originally assigned to a failing company called
Commerce One) created a fair amount of concern when they went up
for auction at the end of 2004; many companies feared that they could be
used to shake down companies all over the e-commerce field. What actually
happened is rather different: they were bought by Novell for
$15.5 million and eventually contributed to the OIN pool. These
patents, it seems, are considered strong enough to keep Mono safe.
Novell did the community (and perhaps the technology industry as a whole) a
big favor by buying those patents; in the process, it beat out bids from a
couple of "intellectual property" firms associated with Nathan Myhrvold.
Donating them to OIN multiplied the favor by putting these patents directly
into the service of free software. We may all be a little safer as a
result of this action.
Some observers in the community have criticized the patent pool idea in the
past. Playing the software patent game in any way is a little distasteful,
and it is not clear to everybody that the owner of the pool would have the
standing or interest to defend the target of a patent attack. The true
success of OIN can only be judged in the long term, and, in the best case
scenario (no software patent suits are ever brought against free software
users), its contribution will never be entirely clear. What is clear,
however, is that OIN has already brought some peace of mind to some of the
people who were most worried about the software patent threat. That seems
like a step in the right direction.
Comments (14 posted)
There can be no doubt that the folks at Kaspersky Lab are persistent. Back
in 1999, Kaspersky released
anti-virus product for Linux; the company also claimed to be preparing "the
world's first Linux-based rescue disk." In 2000, the company claimed
that "new viruses for Linux
appear every day," though it backed down when that claim was questioned.
Now Kaspersky claims
encountered a "cross-platform virus," which is capable of infecting both
Linux and Windows systems. Time to be worried:
The virus doesn't have any practical application - it's classic
Proof of Concept code, written to show that it is possible to
create a cross platform virus. However, our experience shows that
once proof of concept code is released, virus writers are usually
quick to take the code, and adapt it for their own use.
There is hope, however: worried system administrators need only purchase
Kaspersky's anti-virus service, and they will be protected from the threat
of this new cross-platform virus.
Strangely enough, Linux administrators have somehow managed to avoid going
into a panic over this announcement. In fact, few Linux users feel any
more threatened than they did before.
This new "virus" is a program which is able to inject its code into
executable files found in the current working directory. It can't be the
first code with this capability - that particular problem is not especially
hard to solve. Given write access to an executable file, a program can
write to that file. If it is coded to write something unpleasant, that is
what will happen.
What this "virus" appears to lack is any sort of propagation mechanism. If
somebody runs it, their executable files will be corrupted, but it has no
way of traveling further. Any attempt to add propagation to this code will
run into some well-known problems: (1) getting Linux users to run
random malware is still challenging, and (2) most Linux users lack the
access to modify most of the executables they run, most of the time. The
normal protection mechanisms designed to keep users from accidentally (or
maliciously) damaging their systems will also serve to impede any attempt
to infect those systems.
One should not say that writing a rapidly-propagating, Linux-based virus or
worm is not possible. Sooner or later, somebody will probably pull it
off. But any such malware will have to exploit an open security
vulnerability in the target systems, and any vulnerability which is
exploited in this manner will be closed in a hurry. Commercial anti-virus
products work by trying to keep threatening malware away from the system
altogether. The Linux way of doing things, instead, is to make the system
resistant to the attack vector used by the malware in the first place.
Security updates may propagate a little more slowly than virus
descriptions, but the end result will tend to be far longer-lasting.
So it is not clear that there will ever be a real market niche for
anti-virus products on Linux systems. Linux administrators prefer to fix
the root problem, and most distributors have well-tuned mechanisms in place
for making those fixes quick and easy. Anti-virus products add complexity
to a system, can create problems
of their own, and may well not be any more effective against any sort of
"zero-day" attack. If, in the future, we find ourselves truly needing
anti-virus software, our development process will have failed badly.
Chances are that we will not fail in that way, but the flow of scary press
releases from anti-virus companies will certainly continue regardless.
Comments (14 posted)
Back when Red Hat Linux was a product delivered by Red Hat Inc. in its final
form, the user community had little visibility into the decisions that affected
the distribution. One of the early promises that came with the Fedora
Project was that the important discussions would happen in a public forum.
Things have not always happened that way, and a number of things still seem
to happen by anonymous decree. It is true, however, that the public
discussion has grown more vibrant as the wider Fedora community insists on
having its say.
One recurring discussion has to do with one of those decisions by decree:
Fedora Core 5 lacks the "install everything" option which has
characterized Red Hat releases for many years. The reasons behind this
change make some sense: it is increasingly hard to support as the
distribution grows, and as the distribution is split between "core" and
"extras." Some packages conflict with others, making a true "everything"
install impossible in any case. Installing everything is an invitation to
unnecessary security problems. And the Anaconda installer has been
reworked around a yum-based backend which is not so well equipped to do
"everything" installs in any case. Administrators who do a lot of
"everything" installs can use kickstart to obtain something close to the
So removing this option was not an unreasonable thing to do. But the
community was not involved in the decision, and quite a few Fedora users
unhappy with the change. Since there was no discussion - not even an
announcement of the change - these unhappy users continue to fill the
Fedora lists with complaints; it is beginning to look like one of those
threads which never really goes away. But, "install everything" has
gone away, and appears highly unlikely to return.
A more relevant discussion, perhaps, is this one: what is to happen with
evolution in Fedora Core? The state of the FC5 evolution package is
evidently so poor that some Red Hat developers are suggesting that it should be shoved out to Fedora
Extras, or dropped altogether:
Evolution in extras is a bad idea. Evolution in core is a worse
idea. What other as good as unmaintained large buggy package
exposed to external attack and with known unfixed DoS bugs (and
probably worse yet to be found) do we ship.
Evolution belongs in the bitbucket.
The state of evolution is a bit of a problem. It has been pushed for some
time as the mail user agent for Red Hat and Fedora systems; it is
also the only mail client with its particular combination of email and
calendar features. Quite a few Fedora (and RHEL) users depend on it
heavily. So the chances are that evolution is not truly destined
for the bit bucket.
There appear to be two issues here. One is that the core evolution project
has been on hold for some time. There is a new set of developers working
on evolution, and there are signs that the process is beginning to move
again - though some observers are not yet convinced. The other issue is
that the evolution package within Fedora is unmaintained, and has been for
some time. This is a different sort of problem: Red Hat is actively trying
to hire somebody to maintain the evolution package, but has not yet found
anybody. Until that position can be filled, the evolution package in
Fedora is likely to continue to languish.
An interesting side note on this discussion is that some participants have
complained about Red Hat engineers
suggesting the removal of Evolution. It seems that Red Hat folks have a
duty to not scare the users that way. But the truth of the matter is that
we cannot have it both ways: if we want to have a vibrant and open Fedora
development community, the engineers involved must be able to speak their
Meanwhile, the Ubuntu community has run into a different sort of issue.
The original Ubuntu distribution was very much GNOME-based, with a
KDE-based version ("Kubuntu") being somewhat of a second-class citizen.
Last November, however, Mark Shuttleworth announced
that Kubuntu would become "a first class distribution within the Ubuntu
community." From the outside, it would appear that things have happened
that way; Kubuntu releases happen at about the same time as "plain" Ubuntu
releases, and Kubuntu has a large and (seemingly) happy user community.
As of this writing, however, visitors to the Kubuntu.de site are greeted with a protest message rather than the normal
resources found there. It seems that some of the developers working on
Kubuntu are not particularly happy with their relationship with Canonical.
They do not feel that Kubuntu is, yet, a "first-class distribution."
The protest appears to be lead by Andreas Mueller, a co-founder of the
Kubuntu project and the maintainer of Kubuntu.de. Mr. Mueller is a
volunteer Kubuntu developer, not currently on the Canonical payroll. There
are a number of complaints being voiced, and it is not entirely clear what
the real problem is. Discussion on the lists suggests that a
misunderstanding over administrative accounts is part of it. The core,
however, may well be this:
Kubuntu needs more paid developers. Even though Canonical says that
there is one paid developer for GNOME and one KDE
(seb128/jriddell), the rest of the paid developers rather tend to
support GNOME. It would be reasonable to pay at least 2-3 more
developers to balance, because only providing KDE-packages is not
A cynical observer might be tempted to conclude that Mr. Mueller is trying
to shame Canonical into hiring him.
It is hard to say whether Canonical is putting sufficient resources into
Kubuntu or not. It is true that there has been no great outpouring of
support for this protest on the Kubuntu mailing lists. Kubuntu users seem
generally content with their lot. Hopefully this disagreement can be
resolved without changing that situation.
Comments (31 posted)
Page editor: Jonathan Corbet
Next page: Security>>