The term "open source" has been controversial since its inception. It was
coined initially in response to two problems - the alternative "free
software" is simultaneously too vague and too precise. Too vague in that it
is forever forcing certain members of the community to say "not free as in
beer"; the real value of free software is not that you can get it without
paying. Too precise in that some of those trying to sell free software
into corporate environments would rather not bring along "politics" and the
image of the more intransigent members of the free software foundation. So
"open source" was supposed to capture the benefits of access to the source
code without scaring the managers.
One might well argue that it has been somewhat successful in that goal -
but not after some ups and downs. Richard Stallman almost immediately criticized the term, and
hasn't stopped since. Near the end of 1998 there was a dispute between
Software in the Public Interest and the Open Source Initiative over who
owned the "open source" trademark. This disagreement became moot in June,
1999, when the OSI abandoned its attempt
to register the trademark in the U.S. Plans were announced to create a
separate "OSI Certified" mark, but one would search in vain for a way to
use that mark now; the OSI never completed its attempt to register that
Despite the lack of any sort of certification or enforcement body, the
"open source" term has done nicely over the years. People generally seem
to know what it means, and, certainly, our community has only grown
stronger over that time. Recently, however, certain companies have started
testing to see just how far they can push the term. The use of "badgeware"
licenses was a warning shot (covered here last November);
most of those licenses are not considered to be truly open source. More
recently, Centric CRM has made
it clear that it intends to play by different rules:
We truly believe in our product, team and product strategy. We have
never misled or mis-communicated the license that our software is
based on. Our current license is not OSI-approved, nor have we ever
claimed it is. But it is open source.
This "open source" license
contains these terms:
You may use, copy, modify, and make derivative works from the code
for internal use only. You may not redistribute the code, and you
may not sublicense copies or derivatives of the code, either as
software or as a service.
Clearly, this language does not correspond with the idea most LWN readers
will have of "open source." There is no freedom to fork - or even to share
your improvements. By making this use of the term "open source," Centric
CRM is clearly stating that the Open Source Initiative has no say over what
the term means.
OSI president Michael Tiemann disagrees, and has stated his
intent to start defending the term:
Open Source has grown up. Now it is time for us to stand up. I
believe that when we do, the vendors who ignore our norms will
suddenly recognize that they really do need to make a choice: to
label their software correctly and honestly, or to license it with
an OSI-approved license that matches their open source label.
The sad truth is that Centric CRM may have calculated correctly. OSI holds
no trademarks which can be used to discourage unwanted uses of the "open
source" term. In fact, the OSI has accomplished discouragingly little over
the past several years. Nothing has been done to make the OSI a more
community-oriented operation; the OSI board of directors elects itself and
answers to nobody. About the only visible activities at the OSI are a
multi-year process to try to reduce the number of approved licenses and the
occasional approval of a new license. The OSI has not "gone wrong" - it
has not started approving licenses that the community would disagree with.
But it is widely seen as dormant
and irrelevant to anything of interest that the community is doing.
This is the organization whose president would now like to rally the
community to the defense of the "open source" term. Certainly
Mr. Tiemann's cause would be easier if the OSI had paid more attention to
the community all along. Perhaps defending "open source" is the way by
which the OSI can win back some respect. It is a task which needs to be
done; either abuse of the term needs to be curbed, or, as Don Marti
suggests, it's time for a new one.
It is possible to argue that anybody who is taken in by a phony "open
source" license deserves all that ensues; relying upon any piece of
software without understanding the license is a known recipe for trouble.
But if "open source" becomes associated with non-free licenses, it will no
longer be a term which we will want associated with our software. If "open
source" inherently cannot be defended, either legally or through community
pressure, it is time we found that out and moved on. Aggressively
defending "open source" is the right thing for the OSI to do at this time;
it will be most interesting to see if the OSI is up to the task.
Comments (34 posted)
The Mono project has just caught its breath from a major hacking effort to
produce a demo version of Moonlight, a free software
implementation of Silverlight, which has been called
Microsoft's answer to Adobe's Flash. In a three week blur of 12-16
hour days, the team made far more progress than
they expected and produced a working version of a plug-in for Mozilla-based
browsers. A free software implementation, of a media plug-in for free
browsers, is definitely a step in the right direction, though there could be
problems lurking down the road.
Microsoft calls Silverlight "a cross-browser, cross-platform plug-in
for delivering the next generation of Microsoft .NET-based media
experiences and rich interactive applications for the Web." While it,
surprisingly, is cross-browser, supporting Firefox on both Windows
and MacOSX, the definition of cross-platform leaves something to be
desired, at least for Linux users. That is where Moonlight comes in,
implementing the Silverlight platform for Linux.
Silverlight essentially provides a relatively lightweight subset of the
.NET platform and packages it, along with media player capabilities, as a
browser plug-in. Since the Mono project has already implemented a large
portion of .NET for Linux, it was the obvious place for the Moonlight
project. Though, as Moonlight hacker Chris Toshok points out:
"You don't need mono to use moonlight."
The language used to program Moonlight is Extensible Application Markup Language
(XAML) which is an XML-based language, developed by Microsoft, for
describing user interfaces. It shares the graphics model and some of the
characteristics of the W3C standard, Scalable
Vector Graphics (SVG), but does so in an incompatible fashion
The hackathon came about because Miguel de Icaza, Mono project lead,
was invited to the ReMix conference in Paris, to show the "progress" that
had been made with Moonlight. ReMix is a reprise of the Mix conference,
which was held in Las Vegas in April and was where Microsoft announced
Silverlight. By the time de Icaza had received the invitation, roughly a
month had gone by since the announcement, but there had been little or no
progress made on Moonlight. This caused de Icaza to put out a call for
volunteers, to the
Mono team, in order to put a demo together in the three weeks left
before the show. A huge chunk of development work ensued, detailed in a
post to de Icaza's blog.
The final result was able to render the standard "Silverlight Airlines"
demo (screenshot at right) that Microsoft has been using to show off the
new technology. That level of functionality is a far cry from the goal de
Icaza set out with of "simple XAML file loading and some animations".
There is still a great deal of work to do, but the demo was highly
usable and warmly received.
It seems likely that we will start seeing Silverlight content at
websites in the relatively near future and it is extremely useful to have a
free implementation. Presumably, Moonlight will be able
to be built for 64-bit and/or less popular architectures, which will make
it much more widely available than Flash. The Flash plug-in is closed
source, only distributed for a limited subset of Linux architectures.
On the flip side, we will also, no doubt, see all sorts of "native"
add-ons called from Silverlight content that will lock out Linux users.
Reliance on proprietary, patented, DRM-ridden codecs would seem likely,
which will complicate or severely limit Linux use. XAML is a language or
format that is controlled by Microsoft; they can change it on a whim,
providing little or no notice or documentation. In addition, our old
friend the software patent may rear its ugly head. It is not difficult to
imagine ways that Microsoft might interfere with Moonlight or Mono, if they
perceive them to pose a threat at any point.
In order to remain free, at least in the "rich media" world, the free
and open source software community must take a lead in designing,
implementing and popularizing fully free alternatives to Flash and
Silverlight. Plug-ins for all major browsers and operating systems with
freely available codecs need to be included as part of the project. It's
an incredibly tall order, but it is difficult to see significant strides in
Linux desktop acceptance, at least for home use, without a solution for web
page videos and the like. Relying on proprietary software companies to
take the lead, as we have with Flash and now Silverlight, is not likely to
take us in a direction we want to go.
Comments (10 posted)
Recently, Jeff Jones posted a
comparing the number of vulnerabilities found in the first 90
days of Microsoft Vista deployments against those of a number of other
operating systems. It may not come as a surprise that Mr. Jones, who is a
Microsoft employee, found that Vista was significantly more secure than the
alternatives. There has been no shortage of such surveys over the years,
and it may be tempting to write this one off as another bit of random FUD.
Still, it's good to have an answer to such things.
Mr. Jones found that five Vista vulnerabilities were disclosed in its first
90 days, exactly one of which was fixed by Microsoft. When he looked at
Red Hat Enterprise Linux 4WS, the story was a little different: in the
first 90 days of RHEL4, Red Hat fixed 181 vulnerabilities and left another
85 without patches. 129 of those vulnerabilities had been disclosed prior
to the RHEL4 release.
The result is a nice little bar chart showing that
RHEL4 was two orders of magnitude worse than Windows Vista for security
performance in the first 90 days. Scary stuff.
The numbers posted can be checked, and they are not far out of line. Red
Hat published a
table showing that a default install of RHEL4 WS suffered from 274
vulnerabilities in its first year of existence. That's a lot of security
holes, even after accounting for the fact that a full 52 of them were in
Ethereal (now Wireshark).
One could argue that the first 90 days is exactly the period of time one
would want to look at if one's goal were to produce the most lopsided
result. Before Vista's release, few people had the opportunity to look at
it; there was not much outside probing for security holes going on. Vista
was initially only available in its business edition, reducing both the
scope of the system's functionality and the number of copies distributed.
Every component of RHEL4, instead, had been publicly available for months
before the system's release. There were no real surprises in RHEL4. The
relatively long freeze time involved in the creation of an "enterprise"
distribution makes the problem worse; while the world is busily finding
(and fixing) security problems in free software, the packages for the
upcoming RHEL release are just sitting there waiting to be decreed
sufficiently stable. So of course there will be a big pile of RHEL
vulnerabilities on the first day of release, and of course Vista will not
have the same kind of pile.
Red Hat's response to this situation can be clearly seen on the RHEL4
security updates page. On the day of release, Red Hat put out 27
advisories, many of which fixed more than one vulnerability. For example,
update addresses five different CVE numbers, some of which were clearly
worth fixing. First-day fixes also updated php, krb5, cups, KDE,
thunderbird, Python, Perl, mailman, and more. Many of these were important
fixes, though none of them were deemed "critical" by Red Hat; the first
critical updates happened a few weeks later, when bugs in Firefox,
HelixPlayer, and Mozilla were fixed.
One could well ask: why does Red Hat not fold these updates into the
initial release? If they are good enough to issue on release day, they
should be good enough to go directly into the distribution. There are
certainly logistics issues here; mirrors would have to be updated and so
on. But it's not like the old days when there were thousands of boxed sets
to be manufactured. Red Hat could probably find a way to get the first-day
updates into the distribution itself. The benefits, however, would be
entirely in the area of public relations. The number of deployed RHEL4
systems in the first day (or the first 90 days) will be sufficiently close
to zero that the amount of actual exposure caused by the existence of those
vulnerabilities is negligible.
In his report, Mr. Jones goes to some trouble to try to filter out some
packages which are not available on Windows as a way of heading off
criticism that he is not comparing equal systems. But they are still not
equal, of course, and never can be. Any default RHEL installation will
certainly include Python, for example, and will suffer from Python's
vulnerabilities, even if that installation never actually uses Python in a
way which makes those vulnerabilities exploitable. Many RHEL4 systems will
have installed the vulnerable versions of cvs, xloadimage, mysql, telnet,
mailman, gaim, postfix, alsa-lib, vim, gpdf, enscript, Perl, etc.; these
are all packages which are missing from a Vista install. The
vulnerabilities in these packages are also not exploitable in much
(probably a large majority) of RHEL deployments. How many companies deploy
RHEL for the purpose of running HelixPlayer, busybox, or elinks?
Then, there's the silly ones. It might be embarrassing that the initial
RHEL4 release included a bug with a 1999 CVE number. This vulnerability
was in cpio, which neglected to create archive files with the user's umask taken
into account. As a result, cpio archives created with the -O
option have world read and write permissions granted. This is a bug worth
fixing, but it would be amazing if anybody, anywhere, were to actually be
affected by this bug. Even so, the cpio vulnerability counts in the total.
Perhaps more to the point, how many vulnerabilities like the cpio hole will
ever be disclosed in Vista? No security researcher is likely to bother
disclosing a bug like that. If that sort of problem is fixed at all, it
will be a quiet part of some service pack update with no public
announcement. By so aggressively going after and fixing this kind of
security problem, we are causing the number of disclosed vulnerabilities to
grow in a way that most proprietary software companies would try to avoid.
Finding and fixing these problems remains the right thing to do, though,
regardless of who is counting the resulting advisories.
It is also worth pointing out that some of the disclosed vulnerabilities
are mitigated by Red Hat's use of exec-shield and SELinux. Red Hat still
fixes the bug because it's the right thing to do, but, for some of these
vulnerabilities, exploitation is difficult or impossible even without the
The most important points, though, are these: (1) despite the
seemingly large number of vulnerabilities, the number of systems actually
compromised still seems to be quite low, and (2) this number of
vulnerabilities is still far too high, regardless of what any other
operating system is doing. It is encouraging that the number of remotely
exploitable vulnerabilities is small, but the fact that we are arguably not
getting any better at not putting security holes into our code in the first
place is discouraging. There is still much to be done in the areas of
careful coding, pre-release security auditing, and security-related
development tools. Regardless of what one thinks of the methodology of
this report, the security bugs that were counted are real; every one of
them is a reminder that we can be doing better.
Comments (34 posted)
Page editor: Jonathan Corbet
Next page: Security>>