A Public Discussion of Open-Source Licensing

by Rick Moen

Having a public discussion of open-source licensing is usually a recipe for trouble. Attempts at serious discussion tend to get derailed by the "General Public Licence is communism" people, the "only BSD is truly free" faction, or sundry personal attacks. LinuxWorld Conference and Expo's panel discussion on open source licensing, fortunately, managed to steer its way around those reefs, for the most part. This is probably in part because the panelists -- consultant Michelle Kraus (former CEO of OpenSales), Mitchell Baker from Mozilla.org, Brian Behlendorf of CollabNet (and the Apache Web server project), Kevin Lenzo of Carnegie-Mellon University, Dave Mandala of Linuxcare, and Eric S. Raymond and Bruce Perens of the Open Source Initiative -- were veterans of last year's Open Source Licensing Workshops, in which I also participated.

Licensing has become something of a minefield as open source software has grown in popularity. Several major problem areas were essentially unanticipated by the authors of current open source licences, and will likely need to be addressed in future licence versions. Moreover, this needs to happen without a change to the overriding aim of such licences, best articulated by Raymond: "We want to make sure that naive users never need to read a licence."

Patent warfare

As open source software becomes more widespread, the risk of accidentally violating someone's patent rights increases. Also, we're starting to see the practice -- pioneered by Microsoft with its Active Streaming Format -- of using patents to quash open source software entirely when proprietary software publishers find its interoperability a threat.

Large software firms tend to hold collections of software patents as bargaining chips, and horse-trade the licence rights with other companies whose patent rights they transgress. The open source software world has nothing to bring to the table in such a game. Some panelists raised Free Software Foundation head Richard Stallman's notion of a free-software patent pool, but admitted that our side's patent portfolios are very unlikely to ever suffice.

Raymond favors a "Chinese finger trap" provision for future licences: Under its terms, if you initiate patent legal action against the copyright holder, you lose your licence rights. This would form a "poison pill" defense against patent claims, and would become increasingly effective as firms came to depend on covered code. Behlendorf mentioned a related proposal: EFF founder John Gilmore has suggested a licence regime in which you are licensed to use software only if you own no patents, or licence all your patents under similar terms, or arrange to pay royalties. However, as Raymond pointed out, the incentive for big companies to cooperate would be small; they would always elect to pay, rather than compromise their own patent rights.

The consensus seemed to be that, absent some company such as IBM deciding for reasons of its own to use its patent portfolio to assist such an effort, patent claims will remain a serious threat to open source software for the foreseeable future.

Performance rights

Most open source licences have provisions that govern what happens when you distribute (or publish) software. For example, the GNU General Public Licence requires that developers make their changes available if they distribute modified binary software based on other people's GPL'd source code. But those licences' authors failed to anticipate technological advances, notably client-server software architecture, which make it possible to fully exploit everything a piece of software can do without ever distributing it. The most obvious example would be software invoked from a Web server via a CGI interface: because the program is not actually distributed, it can be massively developed by the Web site's owners without triggering any legal obligation to contribute back changes. The Web site's owners can thus obey the letter of any GPL provisions involved while evading the GPL's spirit.

This is in no way a theoretical problem, according to Mandala, who had to go eyeball-to-eyeball with his former employer (a large commercial Web site) to convince it to contribute back changes it made to software packages it used via CGI.

However, it's difficult to fix this pitfall by licensing what are called performance rights without creating worse problems as side effects. Perens suggested that future licences might bar linking to GPL'd code across a client-server boundary with non-GPL'd code, but Behlendorf pointed out that this would imply that GPL-like Web browsers could be used in the future only with GPL-like Web servers. Similarly, if you insist that one must furnish source code for merely using a GPL'd program (as opposed to distributing it), that would impose an unrealistic burden on naive users.

A suitable usage licence might be possible in a contract similar to some end-user licence agreements. However, open source licences have traditionally been based in copyright law, as end-user contracts for software are sometimes unenforceable for lack of an arms-length negotiated agreement between the parties. (It's questionable whether licences activated by a "By clicking you agree" message provide the offer and acceptance elements required for valid contracts.) Unfortunately, the concept of performance as it applies to software isn't as well defined and regulated in copyright law as it is for some other types of intellectual property, such as music. Roughly, performance means "usage without distribution" as related to software.

The entire open source community is not agreed that imposing obligations for performance is even necessary. While Mandala and Perens firmly asserted that, as programmers, they expect people who reuse their code to release back the changes without being able to keep them proprietary, Behlendorf sees that attitude as a violation of the principles of free software. Performance, he pointed out, is not in itself a derived work. Why should such usage create an obligation to disclose changes? Further, since the distinction between data and program code is somewhat artificial, would it mean that, for example, any change to the Majordomo list manager's configuration file (which is a Perl script) at a mailing list site must be disclosed in public?

Behlendorf is well known as a user and advocate of FreeBSD, the licence for which contains no provisions requiring disclosure of modifications, so I nursed some brief hope that he would erupt into a rousing BSD-licence rant. And, indeed, Behlendorf praised the BSD licence as the best way to make software available for reuse, and opined that contributed code is of higher quality when contributions are truly voluntary, rather than required by a licence. Somewhat disappointingly, he then returned to the point at hand.

At that point, we returned to the field's many unresolved and troubling questions. In an era of category-blurring inventions such as document macro-procedures, how are licence-covered programs to be distinguished from non-licensed configuration and data files? Is it program code if, as Raymond suggested, interpreting it requires a Turing machine, or is there some other criterion? Do we even want copyright law expanded to address the concept of software performance more explicitly, or, given the balance of commercial legal interests, should we be wary of asking for what we might powerfully dislike?

The rule of force

The GNU General Public Licence and the Mozilla Public Licence are the best known examples of licences with a forcing function (clauses that condition the right to distribute on disclosure of source changes). The BSD and Perl Artistic Licences are two that lack forcing functions. Kraus pointed out that the MPL differs from the GPL in "drawing a line around" protected code: companies can create separate modules and keep them proprietary, but must contribute back changes if they modify other people's MPL'd code.

Kraus, along with everyone else on the panel save Behlendorf, felt that such licence-driven enforcement has become necessary due to corporate involvement, whereas it was not with individual programmers. This point gave rise to an obvious suggestion from the audience: Couldn't licences' forcing provisions apply only to commercial usage? Raymond clarified that such approaches have been contemplated, but won't work because such terms are too ill-defined. For example, would companies that sell compilations of software on CD-ROM be in violation?

Licence compatibility

The Mozilla Project called the free software community's attention to the problem of licence compatibility. As released, the Mozilla code is said to include modules under four different licences, requiring considerable effort to ensure that the entire package doesn't become impossible to distribute due to a conflict among its licences. This may be one reason why the Mozilla Project has embarked on an effort to secure availability for as much of that code as possible under the GNU GPL.

Unfortunately, many popular licences' terms conflict, making code borrowing and composite projects a legal nightmare. For example, Galeon, a fast, lightweight, much-praised version of the Mozilla browser using the GTK+ graphics toolkit, cannot be distributed intact because of licence conflict between its MPL and GPL modules.

Baker clarified that in general a combined work should be treated as licensed under a superset of the several licences' terms (if they can be combined at all). Of course, it's legally safest to have a single firm or individual own all the relevant copyrights, if that can be arranged.

Perens expressed regret that the Open Source Initiative's (OSI) licence-certification program has inadvertently encouraged the proliferation of licences, with consequent compatibility problems, to the point where an open source programmer may need to hire an attorney. As a participant on the OSI's license-discuss mailing list, I can testify to that: people seem to come out of the woodwork with draft licences for reasons that are trivial or nonexistant.

The loss from this situation is already quite tangible, and ongoing: IBM's Transarc subsidiary is in the middle of issuing an open source variant of its AFS distributed network filesystem, including its excellent, proprietary AFS client and server code for Linux. Unfortunately, no Linux distribution will be able to include that software, because the company will use the OSI-certified IBM Public Licence, which is incompatible with the Linux kernel's licence (the GNU GPL).

An audience member objected that the fears about licence compatibility were overstated, and that we needed to let licences proliferate so we can evolve better ones. Perens answered that the interactions among licences are highly problematic, and worsen as their number increases. Baker agreed, saying that companies often pass the open source licence problem to their legal staffs, who tend to draft entirely new licences without considering the needs of the community, or the thorny issue of licence mixtures. Raymond likewise concurred, saying most new licences the OSI sees are gratuitously different and incompatible. All three of them closed by pleading, almost in unison, "No more licences!"

Finally, some ranting

That was very nearly the last word from the panel, and would have made a good closing note, but for an impassioned rant from audience member Danese Cooper, a manager at Sun Microsystems. She pointed out quite correctly that Sun never claimed its much-maligned Sun Community Source Licence was open source: Rather, it was a device for Sun to standardize its relations with business-partner developers who work with Sun's proprietary code. Sun has received intense criticism from open source software advocates who fail to realize those facts. When Sun wanted to create an open source licence for the upcoming release of StarOffice source code, Cooper said it wrote a good one: the Sun Industry Standards Source Licence (SISSL). She explained that the new StarOffice 6.0 release will be dual-licensed under SISSL and the GNU GPL. "So," she went on with some annoyance, "the same people who called us Nazis before will owe us an apology now."

Eric Raymond immediately invoked Godwin's Law (see Resources) and declared that the panel had just been most emphatically brought to an end.

And so it was.

Resources



Rick Moen is a recovering system administrator in the San Francisco Bay Area, who served as primary Bay Area organizer for Windows Refund Day, and has been one of the main troublemakers behind Silicon Valley Linux User Group's Silicon Valley Tea Party, the Great Linux Revolt of '98, and other Bay Area Linux PR events.

Copyright (C) 2000 by Rick Moen, rick@linuxmafia.com.
Article first appeared in LinuxWorld.com.