Since its inception, Mono has always been controversial, largely because
Microsoft—creator of the .NET framework that Mono implements—is
not trusted by a large segment of the free software community. The concern
is that, at some point, Microsoft will start asserting patent claims
against Mono or applications that use it.
Richard Stallman recently stirred the pot with a brief warning
that reliance on Mono, or applications that are written in C#, is a
"serious danger". That, in turn, has led to a number of
discussions about how real that danger actually is, and what, if anything,
distributions should do about it.
Certainly, the patent non-assertion agreement
that Microsoft and Novell signed in 2006 gives the appearance
that Mono users—those who are not Novell customers
anyway—could be subject to patent
harassment—or worse—from Microsoft. So far, nothing like that
has materialized, but it is difficult for anyone with even the tiniest bit
of cynicism (along with a historical perspective) to be completely
unconcerned about the problem As is typical, Stallman is particularly
blunt, or alarmist, depending on one's perspective:
The problem is not unique to Mono; any free implementation of C# would
raise the same issue. The danger is that Microsoft is probably planning to
force all free C# implementations underground some day using software
patents. (See http://swpat.org
.) This is a serious
danger, and only fools would ignore it until the day it actually
happens. We need to take precautions now to protect ourselves from this
It would seem that Debian's recent addition of the Mono-based Tomboy
note-taking application to one of its GNOME meta-packages—though only for
the Squeeze (testing) release so far—is what prompted Stallman's
warning. Some are advocating
shipping the Gnote re-implementation of
Tomboy in C++, instead of Tomboy, which might be a solution for
note-taking. As Debian developer Josselin Mouette points out, though,
there are no replacements for other Mono-based applications, such as F-Spot
and GNOME Do, so Mono may well be required by other default applications
down the road.
Some distributions, such as Fedora for the upcoming Fedora 12, have removed
Tomboy in favor of Gnote for default installations. This effectively
removes Mono from the default, though the reasons
are not necessarily related to any potential patent issues—Gnote has
a much smaller footprint. But, there is the recent patent suit against
TomTom—and efforts to work around the patent—to
remind folks that the patent threat is real, and that Microsoft, which had
largely stayed away from pressing patent claims, can and will pursue free
software implementations of its patented technologies.
Any patent action against Mono may subject the plaintiff to a countersuit
from the Open Invention
Network (OIN), which is a patent pool to defend free software. By
adding Mono to its list of protected applications, OIN allowed various
distributions, Fedora for
example, to become comfortable enough to start shipping Mono at all.
There are still risks, of course, not least from patent trolls who don't
implement anything that could be subject to a countersuit, but the OIN
coverage provides enough of a threat to potential patent attackers that
Mono is available for nearly all
Unlike many earlier complaints about Mono and C#, Stallman is not arguing
against the existence of Mono, his view is more nuanced than that:
This is not to say that implementing C# is a bad thing. Free C#
implementations permit users to run their C# programs on free platforms,
which is good. (The GNU Project has an implementation of C# also, called
.) Ideally we want to provide free implementations for
all languages that programmers have used.
The problem is not in the C# implementations, but rather in Tomboy and
other applications written in C#. If we lose the use of C#, we will lose
them too. That doesn't make them unethical, but it means that writing them
and using them is taking a gratuitous risk.
The mention of DotGNU Portable.NET is confusing to some: how can Stallman
be warning against C# in the same message where he touts a GNU
implementation of the language? But Stallman evidently doesn't see it that
way; providing the tool is not the same as encouraging its use.
His solution is to discourage new development in C#, find alternative
applications written without Mono, and to not include Mono in the default
installations of Linux distributions. As more C# applications come along,
particularly those without a "Mono-free" alternative, that could pose some
The most in-depth defense of Mono, in general, as well as arguments for its
Debian, Ubuntu, and other distributions comes from Jo Shields. In a lengthy blog post,
which was a response to a challenge
on Linux Today, he also notes that it is the applications that
are driving the adoption of Mono, not the technology in and of itself. He
has a well-thought-out list of reasons that users should not be worried
about the patent threat. He is clearly exasperated—or
worse—with the shrill
However, the vast majority of the anti-Mono crowd are not developers or
packagers — they are back-seat drivers. They make proclamations about how
other developers (who are surrendering their time to developer Free
Software) should instead use the framework of THEIR choice, not the
This issue has been simmering for a long time, but it has really flared
up over the last two or three weeks, prompting the Ubuntu Technical Board
to issue a position statement saying that
it "sees no reason to exclude Mono or applications based upon it from
the archive, or from the default installation set". While some
distributions may remove Mono from their default installs and Live
CDs—for space reasons if nothing else—there are few, if any,
mainstream distributions that will completely remove Mono from their
repositories, as there are clearly useful applications that depend on
it. An interesting exception to that, however, is Red Hat
(RHEL), which doesn't package Mono at all.
C# is an international standard, as both Ecma International and ISO have
adopted C# specifications. Those bodies require patents that are held by
their members, and that cover an adopted standard, be licensed under
"reasonable and non-discriminatory" (RAND) terms. Depending on what those
terms actually are, they may not be "non-discriminatory" towards
free software implementations, particularly if they require royalties.
But, it may well be that patent enforcement actions by Microsoft against
DotGNU for that matter) are unlikely. Microsoft might also be leery of
the various regulatory bodies that
tend to keep an eye on its anti-competitive behavior. All of those things
may make the probability of a patent suit vanishingly small, but it doesn't
reduce it zero—and that is what Stallman and others are worried about.
Of course, Microsoft could make its intentions clear, and remove the
doubt. That it chooses not to, and lets the free software community twist
in the wind, speaks volumes about its tactics—whether it truly thinks
it might ever use the patent weapon or not. Rather than any active
enforcement, a more likely scenario is that Microsoft hopes it can shake
down more companies in deals like it made with Novell. From that
standpoint, the internal free software community bickering about Mono
serves its purposes as well as any "fear, uncertainty, and doubt" campaign
it might be able to conjure up.
There are perfectly legitimate reasons to be concerned about Mono: it is
resource-hungry, is always playing catch-up with whatever new features
Microsoft chooses to add, and could increase the danger from patent suits.
At the moment, though, those kinds of arguments are being drowned out by
a loud group that doesn't want to see Mono exist at all.
This rabid anti-Microsoft segment of the free software community has not
done the rest of the community any favors with its behavior regarding this
issue. There are certainly reasons to be wary of Microsoft, but there is
no reason to believe that the Mono developers and proponents are interested
in anything other than the technology itself. The C# language and .NET
libraries have benefits
that they see, and wish to use. Disagreeing with that, on a
technical—or political—level is all well and good, but calling
for people to be fired or somehow expelled from the community for their
opinions, as Shields describes, is absurd. Freedom cuts both ways.
The root problem is, of course, software patents, and the uncertainty they
bring. This is clearly a growing problem within our community, and one
that is not going to go away soon. While a patent attack from Microsoft
over Mono may be unlikely, there are certainly other patent trolls out
there trying to figure out how to leverage their "valuable intellectual
property" against Linux and free software. Where the next attack comes
from is unclear, but we can be sure that it's coming.
Comments (70 posted)
Skip-free audio and video playback is a fundamental expectation for many -
if not most - Linux users. Given the importance of this feature and the
increase in hardware performance over the years, one would think
that the audio latency problem would have been solved some time ago. The
recent posting of (and mixed reception for) the "RealtimeKit" mechanism
shows that this issue remains open, though, and that we are still short of
a consensus on how it should be solved.
Audio skipping can have a number of causes. If the stream is traveling
over the net, those causes may be entirely external to the system
involved. The rest of the time, resource contention is usually the problem.
And, often, the limiting resource is the CPU. The response time requirements
for audio are not especially tight, but, if the processor gets busy with
something else for too long, it's still possible that the system will fail
to get audio data to the hardware before the stream runs dry. If the sound
card runs out of sound to play, it will go silent, thus introducing a skip
into the audio stream. Even if the skip improves the material being played
(one of the current flood of Michael Jackson retrospectives, say), users
still tend to get unhappy.
Efforts to improve audio latency have taken several forms. One is the
ongoing effort to identify and fix latency problems throughout the kernel.
New scheduling algorithms (the completely fair scheduler, for
example) have also helped. But, even after all that work has been done,
there seems to be little alternative to running core audio processing code
with realtime scheduling priority. And that is where the trouble starts.
More than four years ago, the audio community came forward with its
proposed solution to the problem: the realtime security module.
This module used the Linux security module (LSM) API to allow the system
administrator to grant realtime scheduling privileges to specific users and
groups. This solution slightly reduced the security of the system (opening
it up to denial of service attacks by the privileged users), but it also
solved the latency issues in ways which made audio developers happy.
Kernel developers didn't like this approach, though. The seeming misuse of
the LSM API - which is supposed to only limit privileges, never enhance
them - was part of the problem. But the realtime module just looked like
an ad hoc solution that would not stand the test of time. It was never
merged; the kernel developers, instead, opted for an approach based on
resource limits. As of 2.6.12, any process is allowed to set a realtime
priority up to the value of its RLIMIT_RTPRIO limit. By default,
this limit does not allow any realtime scheduling at all, but the system
administrator can change the default for specific users or groups by
editing the limits.conf file read by the PAM subsystem.
This feature would seem to solve the problem, and, indeed, the
media-focused distributions make good use of it. The major distributions
tend not to use RLIMIT_RTPRIO, though, because it makes it so easy
for a process (malicious or just buggy) to completely freeze the machine. Once
a process with realtime priority goes into a tight loop, there is little
that the user or administrator can do to stop it short of hitting the reset
button. That sort of behavior creates unhappy users and inflammatory bug
tracker entries - both things that distributors hate. So those
distributors have mostly avoided enabling this feature.
More recent kernels have seen the addition of features which could mitigate
this problem somewhat. A new limit (RLIMIT_RTTIME) sets an upper
bound on the amount of time a realtime process can monopolize the CPU;
after that time, it must make a blocking system call or, eventually, be
killed by the kernel. This limit solves the rogue process problem, but it
does little against deliberate denial-of-service attacks, which can get
around the limit by continually forking new processes. As a result,
RLIMIT_RTTIME doesn't make nervous distributors feel much better.
The other feature of note is realtime group scheduling, which allows a
group of processes to be given a "realtime bandwidth" value limiting the
amount of available CPU time the group can use at realtime priority.
That, in turn, limits ability of the group as a whole
to completely take over the system. The group scheduling feature looks
like it should be a complete solution to the problem; it allows groups of
processes to be given access to the realtime scheduler while limiting their
ability to affect the overall operation of the system.
When Lennart Poettering set out to solve the
audio skipping problem, though, he didn't use any of the above
solutions. The security issues associated with resource limits were more
than he was willing to deal with, and he describes the group scheduling
feature this way:
Why not use cgroups for this? Because it's simply a horrible API,
and using this for media applications has non-obvious consequences
on using cgroups for their originally intended purpose -- which are
It is true that a process cannot simultaneously be in a container-related
control group and an audio-related control group if both groups want to
control scheduling-related parameters.
Lennart's proposal is a new daemon called "RealtimeKit"; it has already
found its way into the Fedora Rawhide distribution. The RealtimeKit daemon
has a relatively simple job: it grants realtime scheduling priority to
processes in response to requests sent via D-Bus. There are, of course,
- Any process requesting realtime priority must have the
RLIMIT_RTTIME limit set to ensure that it cannot completely
take over the system.
- There are administrator-set limits on the number of processes which can
be running with realtime priority at any given time.
- The requesting process must have the SCHED_RESET_ON_FORK
policy flag set in the kernel.
The SCHED_RESET_ON_FORK flag is implemented by a kernel patch written by
Lennart and accepted into Ingo Molnar's "tip" tree; this patch has not, as
of this writing, been merged for 2.6.31. This flag, when set, prevents any
child processes from inheriting any enhanced scheduling priorities from the
parent. It thus is effective against fork bombs and other multi-process
attacks; it allows RealtimeKit to give realtime priority to a single
process in the knowledge that this priority will not be passed on to any
As a solution, RealtimeKit looks like it should work, but its reception in
the audio development community was chilly at best. As Paul Davis put it:
This appears to be a baroque mechanism designed to solve a problem
susceptible to vastly simpler solutions. Alternatively, one could
see it as a baroque mechanism designed to solve a problem
that really needs a much more sophisticated solution (i.e. better
scheduling policies). Either way, it seems like something that
makes things more complex on every level, not less.
There are a number of reasons for the objections to RealtimeKit. It adds a
dependency on D-Bus regardless of whether audio developers want it. It's
far from a POSIX interface. RealtimeKit takes certain decisions (such as
whether to use the round-robin or FIFO scheduling classes) out of the
developers' hands. It's not sufficient for the needs of pro audio users.
And so on. But the real complaints would appear to be these:
- The audio community feels a little burned. They were told four years
ago that they needed to drop their preferred solution (the realtime
security module) in favor of the rlimit-based solution, which is now,
in turn, being pushed aside for RealtimeKit. How long will it be,
they wonder, until yet another solution is put forward as the real
- Nobody asked the audio developers how they would like a solution to
look; instead, RealtimeKit was simply presented to them as the new way
Lennart's response suggests that he's not
likely to go asking the Linux audio development ("lad") community for input
in the future:
It was clearly a bad idea to post about rtkit on lad. It is a big
waste of time fighting this through against all those
desktop-haters, fdo-haters, dbus-haters, who apparently believe I
am out to take away their freedom to run their systems the way [they]
More seriously, he points out that RealtimeKit does not break the existing
rlimit-based system. Instead, it just adds an option for distributors who
want to make realtime scheduling available to specific processes in a safe
way. So nothing which works now will stop working under RealtimeKit. That
is little comfort, though, to developers and users who feel that they will
be forced to run RealtimeKit to use their audio applications in the future.
The Linux audio community contains no end of highly talented and highly
motivated developers. But audio support under Linux still falls short of
what it should really be. Audio development has suffered from a lack of
consensus on solutions, a lack of communications between different
development communities, and a lack of a maintainer with a view of the full
problem. So it is not surprising that our audio applications don't always
play well together and don't always work as well as we would like.
Lennart has dedicated a good part of his life toward improving this
situation. A certain amount of controversy and pain has accompanied this
work; one need not look very far to find no end of PulseAudio horror
stories. But PulseAudio seems to be getting better, and Linux may well be
getting closer to having basic (non-professional) audio "just work" out of
the box. The goals of this work are hard to criticize, and criticism of
the results might just be on the wane.
Perhaps RealtimeKit is the missing link which will enable distributors to
improve audio responsiveness; Fedora looks to be the laboratory in which
this particular experiment will be conducted. If RealtimeKit works as
advertised, the audio community will eventually move to make use of it -
regardless of whether they were asked ahead of time or not. For better or
for worse, that's often how our community works: problems are solved not by
talk, but by a determined developer who creates code that works.
README file for more information on RealtimeKit).
Comments (67 posted)
Back in May, the proposed "no
long file names" patch
got a hostile reception on the linux-kernel
mailing list. This patch, presumably aimed at working around Microsoft's
VFAT patents, made the kernel unable to create long file names on VFAT
filesystems. It was seen by many as a reduction in functionality without
any sort of well-explained justification, and it was not merged. Now there
is a new patch which takes a different approach on both the technical and
political fronts. Its fate remains to be seen, but it demonstrates a
method for dealing with patents which is worthy of wider consideration.
The VFAT format is undeniably a hack. It allows the FAT filesystem to be
extended beyond its traditional 8.3 upper-case file name limit by creating
additional file entries - which look invalid to older filesystem
implementations - containing a longer name. Depending on the length of the
name, several of these additional entries may need to be placed in the
directory ahead of an entry holding a traditional short file name. The
first patch simply disabled the ability to create these long name entries;
since the relevant patents all make claims about the creation of long file
names, a system which does not create them cannot infringe. A Linux kernel
with this patch in place (and enabled at configuration time) would be able
to read filesystems with long names, but it would be unable to add any more
long names to it.
The new patch takes an
entirely different approach based on a close reading of the patent. In
truth, it's not the creation of long file names which is covered; instead,
the patent claims the technique of creating both long and short
names. So the current patch takes away that ability; it can create a long
name or a short one, but never both for the same file. The result is
almost complete interoperability with other systems using long names; the
one exception is archaic systems which only have short name capability.
Such systems are relatively rare, though.
There is an interesting trick required to make all this work. The FAT
format requires that the short-name directory entry be present, so Linux
cannot simply leave it out. Instead, that entry is created with a name
which is clearly invalid. The "short name" starts with a space and a NUL
byte, continues with some random characters, and finishes with an extension
containing a slash. The end result cannot be listed as part of the
directory, cannot be used to open the file, and may not even be unique
within the directory. It is, thus, not a name for the file.
Assuming that reasoning holds up in court, this patch creates a kernel
which cannot be said to infringe upon the VFAT patents. Given that the
patch has clearly seen some legal review (see the associated FAQ), and given that
it comes from a source (IBM) with extensive experience and expertise in
patent law, its chances are probably best described as "better than
There are still those who will question this whole approach, though.
Changing the kernel in a way which reduces interoperability looks like an
acknowledgment of the validity of the patents; wouldn't it be better, some
ask, to put those resources into fighting the patents instead? For those
who do not wish to play this game at all, putting hackish-looking workarounds
into the kernel seems like the wrong way to go.
The problem is that invalidating a patent is a long, expensive, and
uncertain undertaking. "Long" means years, "expensive" means potentially
millions of dollars, and "uncertain" means exactly that. The US patent
system (which is of the most relevance in situations like this) is
unwilling to invalidate patents in general; even when it does, the patent
is merely put back into the review process from which it can arise,
zombie-like, to terrorize again. In the mean time, companies subject to
attacks under that patent are suffering under extreme legal costs and
potential injunctions which keep them from selling their products. For
most companies, that's a death sentence. It is unsurprising that most
companies lacking a massive patent portfolio of their own quickly settle
when subjected to patent attacks.
If we choose not to make
use of patent workarounds, we will clearly increase our chances of losing
the larger fight.
Workarounds are a worthwhile alternative to settling and long battles of
attrition. A proper workaround effectively invalidates a patent without
all of the associated costs. This is especially true if the workaround so
clearly avoids the target patent that any attacks can be disposed of
quickly via summary judgment. In any long fight, one must choose battles
carefully; workarounds can allow us to avoid numerous costly battles and
focus our energies on truly disruptive patents. If we choose not to make
use of patent workarounds, we will clearly increase our chances of losing
the larger fight.
The FAQ makes an important point related to workarounds that the community
should hear: publicly questioning the effectiveness of a workaround can
have fatal results. The goal of a good workaround is to avoid a patent
infringement trial altogether. If a patent holder can point to email from
prominent community members suggesting that a given workaround might, in
fact, not avoid the patent, said holder may create enough doubt in a
judge's mind to defeat a summary judgment motion and force a case to go to
trial. Most defendants cannot afford that, and will thus be forced to
capitulate. The right way to express concerns of this nature is via
We have been hearing warnings about software patents for many years, but,
for most of those years, the threat seemed distant. During that time, it
is said, numerous companies have been quietly shaken down for patent
money. The TomTom suit brought that process out into the open, making it
clear that powerful companies are willing and able to press patent
infringement claims against companies using Linux. The sad fact is that we
cannot opt out of playing this game, so we're simply going to have to get
good at it. This patch is part of the process of figuring out how this
game - so much of which is played via secret maneuvers - can be handled in
an open community. It also represents a serious attempt by a large player
in the patent game to help the community avoid a couple of threatening
patents. Perhaps it's not the patch we want to merge in the end,
but it (and its goals) deserve serious consideration.
Comments (47 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Mozilla's Content Security Policy; New vulnerabilities in git, kdelibs, moodle, pam_krb5, ...
- Kernel: Soft updates, hard problems; Perfcounters; The fanotify API.
- Distributions: Ubuntu archive reorganization; openSUSE 11.2 Milestone 3 and YDL v6.2 released
- Development: VA API slowly -- but surely -- making progress, gcc-in-cxx phase 1, new versions of MySQL, PostgreSQL, Nagare, SuperCollider, Firefox, PHP, Python, Pycairo, bzr.
- Press: NetworkManager and ConnMan, How Linux News gets buried, talk by Jim Zemlin, Nvidia chooses Windows CE, Berlin art colleges choose Linux, reviews of Ksplice, KTechLab, Shuttle XS29f, Sugar on a Stick, AndroidFox speculation.
- Announcements: GNOME election results, Open Database License, LCA cfp, PostgreSQL conf cfp, LinuxCon program, Ohio Linux Fest, pyArkansas, SciPy student sponsorships.