Leading items

Defending "open source"

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 term either.

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:

This "open source" license contains these terms:

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:

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)

Major Mono hackathon produces Moonlight

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)

Counting vulnerabilities

Recently, Jeff Jones posted a survey 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, the postgreSQL 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 fix.

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)