Leading items

Similar in spirit?

The recent discussions on the proposed version 3 of the GNU General Public License have been well documented here and elsewhere. This proposal has clearly exposed some differences of opinion within the development community, with the anti-DRM provisions being at the core of the debate. The addition of these provisions has created a fair amount of ill will against the Free Software Foundation; opposition to them appears to have created similar feelings in the opposite direction.

In theory, this disagreement should not come about. GPLv2 contains the following language:

If the FSF is adhering to its part of this bargain, then anybody who bought into the "spirit" of GPLv2 should not have trouble with this revision. So, clearly, those who oppose the GPLv3 draft - many of whom have released vast amounts of code under GPLv2 - believe that the revisions are not "similar in spirit." Some have gone as far as to accuse the FSF of using its power over the GPL to push its founder's radical agenda onto the code of large numbers of unwilling developers.

That accusation is probably over the top. The FSF is, with GPLv3, attempting to respond to a number of problems as it sees them. Software patents are a clear problem, and the GPLv3 draft tries to mitigate that problem somewhat. International applicability of the license has not yet proved to be a problem in practice, but it is clearly something that reasonable lawyers can worry about. It seems worth fixing the language before some court somewhere on the planet decides that the GPLv2 incantations only work in the US. And so on.

The FSF also, clearly, sees locked-down systems as a problem. It is interesting that this has not always been the case; back in 2000, LWN took issue with an interview with Richard Stallman, where he said:

(This interview has disappeared off the original site, but the Wayback Machine has it).

Most TiVo owners probably see their gadget as being more like a microwave oven than a computer. It is not that TiVo has come along since then (the 2000 LWN article mentions it); what has changed is the FSF's - or, at least, Richard Stallman's - position on it.

There are few people who disagree with the idea that locked-down systems can be a problem. Beyond the fact that such devices will always deny users the full potential of the hardware, they can spy on us, deny fair use rights under copyright law, lock us out of our own data, prevent us from fixing serious problems, and so on. Locked-down systems are designed to implement the goals of somebody other than the ultimate owner of the device. Such systems are undesirable at best, and outright evil at their worst.

The disagreement is over how this problem should be addressed. The two sides, insofar as there are two clear sides, would appear to be these:

• The anti-DRM provisions are a licensing-based response to a legal and market problem. They prohibit legitimate uses of the technology (examples could be ensuring that certified software runs on voting machines or systems - like X-ray machines - which could hurt people if the wrong software is run) while failing to solve the real problem. These provisions are trivially circumvented by putting the software in ROM, do nothing about the DRM being incorporated into all aspects of computing systems, and would primarily result in Linux being replaced with proprietary software in the embedded market. These provisions are a new restriction on how the software can be used, and, thus, are not "similar in spirit" to GPLv2.

• The new provisions are needed to preserve the user's freedom to modify, rebuild, and replace the original software on devices that this user owns. Failure to provide encryption keys when the hardware requires them is a fundamental failure to live up to the moral requirements of using free software and, according to some, is already a violation of GPLv2. DRM is an evil which threatens to take away many of the freedoms we have worked so hard to assure for ourselves; it must be fought whenever possible and it certainly should not be supported by free software. The anti-DRM provisions simply reaffirm the freedoms we had thought the GPL already guaranteed to us, and, thus, they are very much "similar in spirit" to GPLv2.

This logjam looks hard to break. Your editor, in his infinite humility, would like to offer a couple of suggestions, however:

• Reasonable people who believe in free software, and who have put much of their lives into the creation of that software, can support either of the two viewpoints above (or other viewpoints entirely). They are not (necessarily) free software fundamentalist radicals, corporate stooges, people on power trips, or any of those other mean and nasty things they have been called in recent times. We can discuss this issue without doubting each others' motives and without the need for personal attacks.

• The FSF clearly has some strong feelings about what it wants to achieve with this license revision, and there are issues it does not want to back down on. There have also been signs, however, that the FSF is listening more than it has in the creation of any other license. This process is not done yet, there is no GPLv3 at this time. Continued, polite participation in the process would seem to be called for.

Finally, while your editor is standing on this nice soapbox... The anti-DRM language was very appealing when it first came out. Your editor does not much appreciate the idea of some vendor locking up his software and selling it back to him in a non-modifiable and potentially hostile form. It is a violation of the social contract (if not the legal license) under which the software was contributed.

But the attempt to address this problem in GPLv3 carries a high risk of splitting the development community while doing very little to solve the real problem. Dropping that language could help to bring the community back together behind the new license, leaving us united to fight DRM (and numerous other attacks on our freedom) in more effective ways. The FSF may want to consider whether, in the long run, its goals would be better served by a license which lacks this language. Such a license might be closer to the spirit which brought this community together in the first place.

Comments (157 posted)

Busy busy busybox

BusyBox is a set of command-line utilities developed with the goal of keeping its size as small as possible. To that end, all unnecessary options and code are ruthlessly cut out, and the entire command set is implemented by a single, multipurpose executable. BusyBox is found in a number of embedded environments; chances are it is running on your wireless router, for example. The command set has reached a level of capability that the new BusyBox maintainer believes that it is almost ready for use on desktop systems.

Yes, BusyBox has a new maintainer, as the result of another disagreement over the draft revision of the GNU General Public License (GPLv3). This episode is worth looking at, as it may be an omen of disagreements that could come up in other projects as the GPLv3 process moves forward.

Some projects reach 1.0 more quickly than others. BusyBox is one of the others. It was started by Bruce Perens in 1995, and became part of the Debian boot process. Bruce moved on to other interests shortly afterward, leaving BusyBox in an idle state, where it remained for a few years. Under the maintainership of Erik Andersen, BusyBox came back to life, and the much-delayed 1.0 release happened almost exactly two years ago - in October, 2004. Version numbers can be deceiving, however, as BusyBox had been in production use for many years prior to 1.0.

In recent years, the BusyBox maintainer has been Rob Landley, an energetic individual (at least, when sufficient caffeine is at hand) who has done a lot to push the project forward. So the task of thinking about how BusyBox and GPLv3 relate fell to him. Since BusyBox can be found in so many embedded systems, it finds itself at the core of the GPLv3 anti-DRM debate. A GPLv3-licensed BusyBox would create obvious difficulties for any vendor wishing to incorporate it into a locked-down product.

BusyBox is not a GNU project, so the Free Software Foundation does not hold its copyrights; instead, those copyrights are retained by the original authors. As Rob looked over the code, he found many contributions with the usual "or any later version" language which would allow a change to GPLv3. Others, however, had the explicit "version 2 only" language. Some, contributed by one Linus Torvalds, state that they "may be redistributed as per the Linux copyright." Some other contributions carry a BSD license - originally with the GPL-incompatible advertising clause. It was quite the mixture of licenses.

Rob was especially concerned about the version-2-only licensing, since that would obviously get in the way of any switch to GPLv3. And, in any case, he was ambivalent at best about GPLv3; it seems that the BusyBox project had developed a plan to dual-license its code under both GPL versions, allowing it to continue to be used under either license. So his question with regard to the v2-only code was:

That led to the beginning of a long and unpleasant discussion about whether BusyBox should move to GPLv3 or not - and it quickly became clear that Rob had no interest in such a move. His reasoning is worth a read, as it includes a couple of new concerns - including the fact that a dual-licensed GPLv2/GPLv3 code base would be unable to accept contributions licensed under a single version (either version) of the license.

Enter Bruce Perens, last seen in in BusyBox circles about ten years ago. Bruce clearly feels that he still has some rights over the code:

What followed was a long discussion on whether DRM differs from simply putting the code into ROM, whether the FSF is more worthy of trust than IBM, whether a move to a GPLv2-only license was possible, how much of Bruce's original contribution remains, and so on. Interested parties are encouraged to go into the BusyBox list archives and spend considerable time plowing through the postings; they do not always show the free software community at its best. The real outcomes, however, are this:

• BusyBox will be GPLv2 only starting with the next release. It is generally accepted that stripping out the "or any later version" is legally defensible, and that the merging of other GPLv2-only code will force that issue in any case.

• Bruce Perens wants his contributions to keep the "any later version" language, and has requested ("and required") that the copyright notices reflect this wish. Accommodating a contributor's wishes in this regard is normally done, but Rob Landley has refused to go along; his reason, in the end, boils down to "I'm mad at Bruce and don't want to."

To show that he meant it, Rob launched a project to find and excise any remaining contributions to BusyBox from Bruce. In response, Bruce has announced that he will be creating a fork of BusyBox which will be more responsive to his wishes. All of that may be moot, now that Rob has resigned from the project and handed the maintainership over to Denis Vlasenko - who plans to pursue moving Busybox onto the desktop.

All of this could be dismissed as yet another silly community soap opera - and there is truth to that view. But this is a soap opera which is likely to be rerun a number of times over the coming months. Any project which (1) uses the GPL, and (2) allows contributors to retain their copyrights is likely to have a discussion like this one. Avoiding such discussions is, perhaps, why the FSF is so insistent on obtaining copyrights for the projects it manages.

Version 2 of the GPL has brought together vast numbers of developers into a single agreement on the terms under which their code could be distributed. It may never have been possible to update the GPL without fracturing that agreement; it seems increasingly clear that the GPLv3 draft has, so far, failed in that regard. There are enough developers who see it as not being "similar in spirit" to GPLv2 to ensure that the new license, in its current form, will not be a simple drop-in replacement for its predecessor. Regardless of how one feels about the new terms in the GPLv3 draft, it is hard to see the potential for this sort of discord in the community as a good thing.

(Thanks to the several LWN readers who brought this to our attention).

Comments (279 posted)

Open source systems management software

A previous LWN feature examined the rise of the open source enterprise stack - a modular collection of applications that together provide the entire spectrum of enterprise computing functions.  One component of that stack is systems management.  This area encompasses areas such as provisioning and patching of servers; configuration and management of applications running on those servers; and monitoring all elements of the computing system - hardware, software, networks and their security.

Systems management is dominated by the "Big Four": BMC's Performance Manager, CA's Unicenter, HP's OpenView and IBM's Tivoli.  Like many proprietary systems, these are monolithic in design, and attempt to provide every kind of systems management features within a single, highly-complex program.

Free software is by its very nature modular, so open source systems management programs tend to be focused on particular tasks.  This has led to a richness of the free software tools addressing this area, often with multiple solutions for a given problem.  The downside is a confusing array of possibilities, a wide range of rival approaches and some unnecessary duplication of effort.

In an attempt to bring some harmony to this coding cacophony, the Open Management Consortium (OMC) was founded in May 2006 with the following objectives:

• Create awareness of open source management tools in the market
• Provide education and resources to help end users make informed decisions regarding open source
• Establish conventions and standards that enable integration and interoperability
• Enable collaboration and coordination on common development projects
• Promote collaborative open source systems management solutions

The founding members of the consortium are Ayamon, Emu Software, Qlusters, Symbiot, Webmin, and Zenoss.  The oldest of these is Jamie Cameron's Webmin, established in 1997, which provides an easy Web-based user interface for Unix system administration.  The project is sponsored by OpenCountry, which joined the OMC in September 2006.  The other founding members of the OMC also support free software projects, in a variety of ways.  For example, Ayamon was founded by Ethan Galstad, who is the creator and lead developer of Nagios, an open source host and service monitor that uses a plug-in architecture to provide a rich range of options.

The case of Symbiot, which provides software for network security event and risk management, is more complex.  The company was founded back in 2001, but initially sold only proprietary products.  Then, as Symbiot's founder and CEO Mike Erwin explains: "We introduced an open toolkit and visualization platform called OpenSIMS in 2005, upon which a great degree of the Symbiot software is based. OpenSIMS is an independent package, maintained by Symbiot and programmed with hooks for other common open source packages."  He says the benefits of this move flow both ways: "Open source code bases provide a method for end-users to do intelligent customization while providing the original code creators with [a] 'lighthouse' pointing them towards where the commercial space should go."

Emu Software took a similar path to openness.  It started life back in 2003 selling NetDirector as a closed source Web-based system administration platform.  "Although we always felt that we would contribute at least part of the product to the open source community," says co-founder Greg Wallace, "we concluded in late 2005 that systems management would be the next big computing market to see significant open source adoption, and we wanted to be out in front."  He believes that certain sectors lend themselves to the open source approach: those where there are "lots of users; a horizontal nature - that is, cross-industry adoption; a high incidence of user desire to customize; an initial market dominated by large incumbent vendors with integrated, and some might say over-engineered, products."

Wallace explains how the OMC is trying to bring some order to the wealth of open source systems management solutions:

And Erwin notes one practical benefit Symbiot has already derived since joining the consortium:

Looking forward, Wallace hopes that the OMC will become "more structured, with some defined working groups and a more defined mission and by-laws.  Eventually, I'd like it to function, and be organized, like Eclipse."  Erwin believes its influence could be considerable: "In the long term, I see the OMC as being a central clearinghouse and repository for system management tools with not only the Big Four's participation, but likely guidance."

That may be some way off, but already the membership of OMC is swelling fast: just four months after its foundation, the original five members had grown to 29.  Among them is Hyperic, another major player in this space, and with an interesting history.  It was originally part of Covalent, which provides commercial support for Apache, before splitting off in March 2004.  Like Symbiot and Emu Software, it too began selling closed source products before opening up its flagship software Hyperic HQ, a suite of inventory auto-discovery, monitoring, alerting and portal tools, in July 2006.

John Mark Walker, head of community development at Hyperic, explains the move: "From Hyperic's founding, it was always our intent to open source HQ - once we felt that it had reached a level of maturity to be useful for a number people, and once we had the in-house resources to properly support our community and foster its growth."  And he points out: "The problem that existing management software strives to address - integrating with every existing and future technology in order to manage it - is only solvable through open source communities. It is impossible for a single company to keep up with all of the newly emerging software and other technologies in the data center. The problem requires the interactive, two-way communication inherent in the open source process.

Not everyone sees the OMC as the way to do this.  For example, another leading company in this area, GroundWork, prefers to do its own integration of open source systems management tools to create its GroundWork Monitor product line, which includes both closed and proprietary elements.  Although the company says it doesn't "see a particular need in being a part of the OMC at this time," it has created its own Open Source Council in August 2006, with the aim of ensuring that GroundWork "will always be comprised of the very best open source projects comprehensively integrated into a platform."  Whether within or outside the context of the OMC, integration remains the key challenge for open source management tools.

Glyn Moody writes about open source at opendotdotdot.

Comments (5 posted)

Page editor: Jonathan Corbet
Next page: Security>>