LinuxCon: The tragedy of the commons gatekeepers

During the 2012 LinuxCon North America conference, Richard Fontana, legal counsel at Red Hat, began a rather philosophical talk with what seemed to be a rather philosophical question: how do we decide what is free and open source software (FOSS), or rather, how do the organizations that have taken on this task make these decisions? However, he immediately pointed out that this is in fact a rather practical problem, since if we can't define FOSS, then it becomes rather difficult to reason and make decisions about it.

Many users and organizations need to make practical decisions based on the definition of FOSS. Individual users may have an ideological preference for FOSS. Software projects may need to know the status of software as FOSS for legal or policy reasons. Some of those projects may want to exclude non-free software; some Linux distributions may want to confine non-free software to a separate repository. Many governments nowadays have software procurement policies that are based on free software. Acknowledging the presence of Bradley Kuhn, executive director of the Software Freedom Conservancy (SFC) in the audience, Richard noted that the SFC requires the projects that it supports to be under a free software license. Some project-hosting web sites likewise have hosting policies predicated on a definition of FOSS. (Examples of such policies include those of SourceForge and Oregon State University's Open Source Lab.) Finally, some corporations have policies governing the use of open source software. All of these organizations care in a quite practical way about the definition of FOSS.

Deferring to authority

Richard didn't explicitly explain the origin of his talk title, but with a little reflection it became clear. The "commons" is of course the body of software that the community considers to be free. "Gatekeeping" is the process of admitting software to the category "free". What then is the "tragedy"? For Richard, it is the extent to which a freedom-loving community has surrendered the decision about what constitutes FOSS; instead, we commonly defer to authorities who make the decision for us. When people do consider the question of what is free software, they often say "the OSI [Open Source Initiative] has this figured out". Or they take the same approach with the FSF (Free Software Foundation).

Sometimes, people or organizations do consider this question more deeply, but they ultimately arrive at a justification to defer to an authority. Richard mentioned the example of the UK-based OSS Watch. OSS Watch recognizes that there are many definitions of open source, but for the purposes of their mission to advocate open source software in higher education, they've made the decision to accept the set of OSI-certified licenses as their definition. OSS Watch's justification for deferring to the OSI is that it is a quick way to accept that the code is open and "accepted by a large community, and if you've ever seen the OSI license list, you'll realize that is ridiculous." On the other hand, Fedora rejects the OSI as an authority for the definition of free software, and instead adopts the FSF's definition, on the basis that the FSF has the competence to make this definition. (Richard somewhat humorously expressed the Fedora approach as "What would RMS [Richard Stallman] do?")

Three organizations have tried to define FOSS: the FSF, the OSI, and the Debian project. These organizations have taken both a legislative and a judicial role, and Richard observed that this raises a separation-of-powers issue. He quoted Bradley's statement that "the best outcome for the community is for the logical conjunction of the OSI's list and the FSF's list to be considered the accepted list of licenses". The point here is that even though Bradley often disagrees with the OSI, he clearly sees that it's in the best interests of the community that no single group acts as legislator and judge when it comes to defining FOSS. Richard then turned to examining each of these three authorities, looking at their history and processes, and offering some criticism.

The Free Software Foundation (FSF)

The FSF has had a definition of software freedom as far back as 1986. By 1999 that definition had evolved into the well-known statement of the four software freedoms:

• The freedom to run the program, for any purpose.

• The freedom to study how the program works, and change it so it does your computing as you wish.

• The freedom to redistribute copies so you can help your neighbor.

• The freedom to distribute copies of your modified versions to others.

Richard pointed out that this a very compact definition of software freedom that covers many bases. It includes a legal definition (explaining at a very high level what permissions the software gives the user), technical criteria (source code must be available), policy justifications (freedom is important because it's important to be able to share), and "autonomousness" (it's important to control your own computing).

Since 1999, the FSF has maintained a list of free and non-free software licenses, with (often brief) rationales for the categorization of the licenses. Richard noted that the license list is accompanied by an evolving explanatory text that is rather useful. The FSF even gives a rule of construction which clarifies that they apply their criteria expansively when deciding if a license is free:

Richard then outlined some criticisms of the FSF, but emphasized that they were all mild. There seems to be a lot of inconsistency in the FSF's decisions about what is or is not a free software license. He likened the issue to Anglo-Saxon judicial systems, where the rationale for reaching a decision derives not just from the law but also from past legal decisions; an analogous process seems to happen in the FSF's categorization of software licenses. Furthermore, sometimes the rationale for decisions about particular licenses is too limited to be useful. Here, he mentioned the Perl Artistic License, version 1, which the FSF categorizes as non-free with the following humorous, but not very helpful explanation:

Another criticism that Richard raised is that the FSF is sometimes too formalist in its analysis of licenses, ignoring factors that are external to the license. Here, he mentioned the example of the Pine license. The Pine email client, developed at the University of Washington, had a BSD-style license for many years. But, at a certain point, and contrary to widespread understanding of such licenses, they claimed that the license did not give permission to redistribute modified versions. The FSF saw this as a textual problem, hinging on how particular words should be interpreted. But, the real problem was that "the University of Washington was being a [legal] bully and was giving an unreasonable interpretation of license."

Richard's final criticism of the FSF was that there was an appearance of bias. The FSF has multiple roles—steward of the GPL, maintainer of the free software definition, sponsor of the GNU project, and adjudicator on licenses—that can potentially conflict. "Could you imagine the FSF ever saying that a version of GPL is a non-free license?" Here, he gave an example relating to the GPLv2. Section 8 of that license allows the licensor to impose geographic restrictions on distribution for patent reasons. (The GPLv3 does not have such a clause.) In Richard's opinion, invoking that clause today would make the GPLv2 non-free (here, the implication was, non-free according to the FSF's own definition) "but I can't conceive of the FSF reaching that view".

Debian

Richard spent some time talking about Debian, beginning with some details of the Debian Social Contract (DSC). The DSC was written in 1997 by Bruce Perens. The Debian Free Software Guidelines (DFSG) form part of the DSC. The DFSG divides the software that Debian distributes into free and non-free parts, and this distinction has taken on a somewhat ideological dimension in the Debian community today. However, originally, the main focus was on being a high-quality noncommercial distribution fashioned on the Linux kernel project. One of the intentions was to be the upstream for successful commercial redistributors, and the reason for dividing software packages into "free" and "non-free" was to signal to their downstreams that there might be a problem with some software; in other words, the DFSG is a packaging policy. In later times, the Debian perspective became more ideological, as Bruce Perens increasingly stressed the free software ideal. And by now, the DFSG has taken on a life of its own, becoming something of a constitutional document for the Debian project.

Richard talked a bit about the process of how software comes to be defined as free in Debian. Essentially, this is a packaging decision made by a group of elite packagers—the FTP Masters—who, guided by the DFSG, determine whether software packages end up in "main" or "non-free". He criticized a few aspects of this process. The FTP Masters typically don't provide rationales for their licensing decisions (the rationale for the AGPLv3 was an exception that he noted approvingly). And though there is a process for review of their decisions, the FTP Masters have something approaching absolute power in these matters (but he emphasized that this was not much different from the situation with the FSF).

The Open Source Initiative (OSI)

The OSI's Open Source Definition (OSD) was crafted in 1998 by Eric Raymond working with Bruce Perens, using the DFSG as a basis. Richard characterized this as a somewhat strange approach, because the DFSG is very specific to the problems that a 1990s noncommercial distribution would face if it wanted to classify package software licenses in order to assist downstream commercial redistributors. By contrast, the OSD was intended to be a general definition of open source. Some parts of the reuse work, but some do not. For example, there is a clause in the OSD that refers to "distribution on [a] medium" that makes sense in the context of Debian packaging, but is out of place in what is supposed to be a general definition of open source. These problems probably spring from the fact that the authors wanted to quickly draft the OSD, and there was something near at hand in the form of the DFSG. Notwithstanding some oddities inherited from the DFSG, the OSD did improve some things, such as the definition of "source code".

Richard described OSI's license-certification process positively, noting first of all that it has a greater degree of transparency than the FSF and Debian processes. There is discussion on a public mailing list, and though the OSI board makes the final certification decision, there is evidence that they do take serious account of the mailing list discussions when making their decisions. He did however express doubts that the board pays much attention to the OSD, because "as I've, said it's a very strange document".

The OSI has faced a number of problems in its history, Richard said. Early on, it was accused of worsening the problem of license proliferation (which was ironic, as OSI had been one of the first groups to call attention to the problem). This was a consequence of the OSI's attempts to encourage businesses to use open source. There was indeed a lot enthusiasm from some businesses to do so, but several of them wanted to do what Netscape had already done: write their own license. Several of these licenses were approved by the OSI, and the decisions in some cases seem to have been hasty.

In 2007, the OSI faced a strong challenge to their authority in the form of what Richard called the "badgeware crisis". A number of companies were using a modified version of the Mozilla Public License that added a badgeware clause. This clause allowed licensors to require licensees to prominently display logos on program start-up. Although the licenses were unapproved by OSI, these companies posed a challenge to the OSI by calling their licenses "open source." (In the end, the OSI even approved a badgeware license.) "As dastardly as these companies were, I sort of admire them for challenging the idea that they should just defer to OSI as being authoritative."

Richard sees two problems that remain with the OSI to this day. One of these is OSI's categorization of certain licenses as "popular and widely used or with strong communities". In part, the goal of this categorization is to address the proliferation issue, by recommending a subset of the OSI-approved licenses. The membership of this category is somewhat arbitrary, and the fact that the licenses of several OSI board members are on the list has led to suggestions of cronyism and the criticism that the list rewards entrenched interests. A further problem with the idea that people should use "popular" licenses is that it discourages experimentation with new licenses, and "eventually we will need new licenses."

The second problem that Richard noted was inconsistency in the way that license approvals are considered. He cited two contrasting examples. In 2009, Carlo Piana submitted the MXM license on behalf of a client. The license included a rather limited patent grant, and because of that, it met strong opposition in the resulting mailing list discussions. Later, Creative Commons submitted the CC0 license. That license included a clause saying no patent rights were granted. Despite this, it initially received a positive response in mailing list discussions. It was only when Richard started raising some questions about the inconsistency that the tide started to turn against the CC0 license. Why did the two licenses receive such different initial responses? Carlo Piana suggested that it was the identity of the entity submitting the license that made the difference: Creative Commons was viewed positively, but the organization behind MXM was at best viewed neutrally.

Are software licenses enough to define FOSS?

Going off on a related tangent, Richard considered the rise of an idea that he termed "license insufficiency"—the idea that licenses alone are not sufficient to define open source. This idea is often posed as a suggestion that the definition of open source should be expanded to include normative statements about a project's community and development model. In other words, it's not enough to have a FOSS license and availability of source code. One must also consider other questions as well. Is there a public code repository? Is the development process transparent? Is it possible to submit a patch? Is the project diverse? Does it use a license whereby commercial entities are contributing patent licenses? In this context he mentioned Andy Oliver's "patch test" for defining open source. (Simon Phipps, who is now president of the OSI, has also written about some of these ideas, using the label "open-by-rule".) Richard said, "I don't agree with all of that, but I think its an interesting idea"

Conclusions

Richard concluded his talk with a few observations and recommendations. The first of these is that the historical tendency in the community to defer to institutions for the definition of FOSS is a problem, because those institutions have issues of accountability, bias, and transparency. People should be ready to question the authority of these institutions.

He observed that the FSF could learn from OSI's participatory approach to the license approval process. Conversely, the OSI should drop the Open Source Definition in favor of something more like FSF's Free Software Definition, which is far more appropriate than a definition based on the Debian Free Software Guidelines.

The FSF does the best job of providing rationale for its licensing decisions, but all three of the institutions that he talked about could do better at this.

Richard thought that the idea of defining FOSS based on open development criteria ("license insufficiency" above) is based on correct intuitions. We need to expand beyond the idea of licenses in terms of how we define software freedom.

Finally, Richard said that software projects can work together in developing and policing definitions of FOSS. He has seen distributors working together to share opinions on how they view licenses. Distributors are also in a unique role for policing software freedom, since they can sometimes pressure upstream projects to change their licenses. There is potential for this sort of collaborative approach to be generalized to the task of defining and policing the definition of FOSS.

[Michael would like to thank the Linux Foundation for supporting his travel to San Diego for LinuxCon.]

[2013-01-09 update: a recording of Richard's talk can be found on the Free as in Freedom web site.]