"The creation and management of boundary objects is key in developing and maintaining coherence across intersecting social worlds."
The objective of this article is to examine how software licenses in build and shape political and technological boundaries.
Licenses specify the permissions granted by the copyright owner to users. According to Lanzara and Morner in "Artifacts Rule! How Organizing Happens in Open Software Projects", these permissions are inherent in a set of practices which are strongly inscribed in the license. But according to Lin, that can mean different things to different community participants. The free/open character of F/LOSS is, therefore, the result of an intricate web of negotiations around the meanings of material artefacts.
We examine the cases of the Geographic Resources Analysis Support System(GRASS) geographical information system and the OpenSolaris operating system. The first project is GPL licensed software developed by a worldwide community of voluntary programmers; the second project is sponsored by a company and released under the Common Development and Distribution License (CDDL) license.
Licenses and Boundary Objects
We will conceptualize licenses as boundary objects comprised of textual artifacts. A boundary object inhabits "several intersecting social worlds and satisf(ies) the informal requirements of each of them. Boundary objects are objects which are both plastic enough to adapt to local needs and the constraints of the several parties employing them, yet robust enough to maintain a common identity across sites".
By considering licenses as textual artifacts, it is possible to analyze what practices and political visions are inscribed in a license (robustness) before describing what happens when a license enters a specific community (plasticity). We observe that licenses not only determine the boundaries of the permissions granted by the copyright owner to the users, but they also set the boundaries around the possible human and non-human participants to a project.
In their plasticity, licenses allow communications among different political, technical and organizational positions, shaping the meanings of participation, alliances and coordination. Nonetheless, licenses acquire their form in the interrelation between human and non-human entities in development projects. The robustness of a license takes a plastic and contingent form when the license itself is shared among different social worlds.
GNU GPL v. 2.0
In 1983, MIT programmer Richard M. Stallman launched a project for developing an entire UNIX-compatible operating system known as GNU (GNU's Not Unix). According to Stallman's plans, with the GNU General Public License (GPL) "users will no longer be at the mercy of one programmer or company which owns the sources and is in sole position to make changes". Stallman wanted, in fact, to redefine users, sources, programmers and companies.
In order to impose his own version of reality on others, Stallman needed a powerful intermediary: "we needed to use distribution terms that would prevent GNU software from being turned into proprietary software. The method we use is called "copyleft"." The GNU GPL was born as the intermediary or "the method" for ensuring the project goals. The second section of the GPL, known as the Preamble, indicates the most important problem that this license wants to address: "The licenses for most software are designed to take away your freedom to share and change it."
The problem is that the majority of software licenses act against Stallman's plans. They allow programmers and companies to "own the sources". Stallman conceived copyleft which uses copyright law against its usual interpretation. With copyleft, authors allow everyone to run, copy, and modify their program and to distribute modifications. Simultaneously, copyleft imposes some restrictions on the use of the software. The intent of the GPL is to prevent GNU software from ever being turned into proprietary software.
The CDDL, was created by Sun to foster the construction of a common environment for developers and distributors of OpenSolaris. According to the CDDL FAQ, the need for the CDDL license emerges from the convergence of two different phenomena: the need to use file-based licenses and license proliferation.
The CDDL license specifies the actors whom the license tries to interest and mobilize: developers and distributors. The CDDL is a file-based license; it only protects the individual files belonging to OpenSolaris, not the program as a whole. One of the aims of this license is to enable the "creation of larger works for commercial purposes". This defines an important difference in intent between the CDDL and GPL and shapes the interests of potential participants.
The CDDL boundary also excludes two groups. The presence of the copyleft clause (see 3.1. "Availability of Source Code", and 3.2. "Modifications" in the CDDL), chosen in order to provide "the protections and freedoms necessary for true open source", excludes the possibility of combining CDDL-covered software with code covered by the GPL. The second excluded group is those who want to distribute their modifications of the covered files in proprietary form.
The second issue to influence the shape of the license is license proliferation: the increasing number of file-based F/LOSS licenses. The last aspect we want to highlight is the control enacted by the license by means of the license steward. The license steward is an entity (Sun, in this case) that has the right to change the license. Through this right the license steward enacts a form of partial control on the future of the project.
GRASS and GPL
GRASS was started at the beginning of the 1980s as a small development project of the United States Army Corp of Engineering Research Laboratory (USACerl) and was distributed as public domain software. In 1996, USACerl stopped GRASS development and asked users to migrate towards proprietary GIS. In 1998, a new GRASS development team (GDT) was formed to re-launch a voluntary GRASS development community. The passage from USACerl GRASS Public Domain (version 4.1) to the new GDT GRASS (versions 4.2, 4.2.1, 5.0) marked a phase of uncertainty for the software copyright ownership. In 1999, after some negotiations, the GDT adopted the GPL v. 2.0 as the copyright license for GRASS software. The GRASS community agreed to use a well-known F/LOSS license.
The GPL copyleft represents a form of controversy and a source of discussions within GRASS mailing lists. Controversies around the GDT agreement on the GPL emerged many times as its copyleft clause excludes the participation of developers using incompatible licenses.
"Why GPL" as a discussion thread occurred within the GRASS developers mailing list in March 2001. Some aspects of releasing GRASS under GPL were questioned by a list newcomer. We summarize his two main points and his attempt to impose a new license on the GRASS framework:
- It is possible for the authors of the original code to re-release their code under the LGPL (lesser GPL) or another license.
- People who write plugins for the GRASS framework may want to use their own license.
The LGPL is a license of the GNU project of the Free Software Foundation (FSF) to cover specific GNU libraries.Unlike the GPL, it allows integration with proprietary software. The proposed re-release of GRASS under the LGPL would change the participants' positions in the GRASS community. The LGPL would place the copyleft method on the program itself but would not apply any restrictions to other software linking with GRASS. LGPL would only require the modifications applied to GRASS to be released under the LGPL license.
In this community discussion, the identities, roles and desires of the enlisted entities are redefined in a new network of heterogeneous associations. This redefinition can be achieved through the choice of the LGPL by the authors of the original code. With the LGPL, the identity and roles of entities are once more stabilized as: i) GRASS could be integrated with plugins written for specific applications; ii) participants in GRASS could then use their own licenses: and iii) programmer's rights would still be protected by the LGPL.
At this point, the new associations must be tested. Will the newcomer be able to make the LGPL, rather than the GPL, the new license for the GRASS community? He is forced to defend his own associations against the GDT's previous agreement. In a mailing list discussion dated 22nd March, 2001, he states: "The only difference between the GPL and LGPL is software linked to the GRASS library would not have to be GPL. It offers the same protection of the software, but doesn't scare away people who do not want to release GPL software. And that's a big difference. If people are scared off because they can't make money using the freely given contributions of other, so be it."
And the response on March 26, 2001: "If end users get accustomed to the proprietary enhancements, the owner of the proprietary rights (gets) power over the GRASS development. The GPL is the license which protects against this and thus most firmly ensures the long term freedom of the software." Here emerges a protection of the GDT agreement on the GPL. For these GDT members, there is no reason to doubt the previous license choice. These members assume that, through a different license (even another F/LOSS license such as the LGPL), owners of the proprietary rights over a proprietary extension of GRASS can exercise some power on the overall system development.
In this way, a newcomer to the development list is asked to not contribute to the GRASS community if he does not agree with the GPL choice. The GPL copyleft boundary is clear: owners of applications released under a license incompatible with GPL are kept separated from GRASS development and its community.
CDDL and GPL Incompatibility
The mailing list thread discussed in this section started when a non-developer in the OpenSolaris community asked how it is possible to include software covered by the GPL license which is considered incompatible with the CDDL by the FSF. This thread includes several debates which took place between July and September 2005. The first started with the above question and reached a conclusion within two days, with the resolution (mainly by Sun's employees) that the GPL'ed software included in the project is composed of separated programs, not linked modules, so that each license is applied to the respective programs. Participation boundaries are shaped by technical ways to connect different software: the license issue acts as a boundary object between developers and non-developers in the definition of a technical concern. The second round, which lasted more than one month, was started by a non-Sun member, who stressed aggressively the political differences enacted by the CDDL: "So stop with the pathetic FUD and start reading your licenses before flaming about them. Sun could have included an exception for the GPL (as did the MPL 1.1, from which the CDDL is derived) but they clearly chose not to for political reasons."
The post involved both part of the license text and the use of conflictual expressions like (FUD, fear, uncertainty and doubt). Four answers followed this post, the last of which contained a link to CDDL Reflections that presented Sun's position on the subject. In this case, the political boundaries between different licenses and Sun's positioning in the F/LOSS panorama were defined through the action of a recognized spokesman.
The third round was debated even more vigorously, lasted one month, and involved a much larger number of posts. It began with a post by a non-Sun member sent both to the mailing list and to Richard Stallman. Here are the beginning and conclusion of the message: "Alright, I wonder about this myself as well. [...] Sun should be nurturing a cooperative and mutually beneficial relationship with the FSF. If they have not been doing this from the beginning, Sun should be extending an olive branch."
The long post included three passages aimed at supporting the author's argument: i) the need to ask directly the FSF's opinion; ii) the need for the license compatibility in order to make the project flourish; and iii) the author's withdrawal from the project in relation to the perceived hostility towards the GPL. The author's participation and the alliance between the project and the free software movement are connected by the licenses. The argument continues and raises other issues: i) requests for modifying the CDDL and the GPL in order to improve their compatibility; ii) the GPL perception as a constitutive element of the open source movement; and iii) the definition of the OpenSolaris community and its participants/users. Consider these messages: "the bottom line is that opensource developers and users want their software to be GPL. (I)f it is not then these people will be turned off by opensolaris." And: "No, *some* users and developers want their software to be GPL. And just as those users will be turned off by OpenSolaris because it is not, there will be many that will be turned off if it becomes GPL. [...] The majority of users don't care what license a program is under. They just like good software."
This debate involves and shapes the meanings of different entities: i) open source developers and users; ii) a group of GPL zealots; iii) the majority of users; and iv) the participants in OpenSolaris. Many messages involved the CDDL's political positioning, mainly in relation to the distinction between the free and the open software movements.
In these discussions, the license is enacting relationships among the individuals participating in the project. Some participants do not accept being aligned with the discussion and they criticize the intermediary organization itself. The coordination of the entire project is questioned and the license becomes a boundary object that separates allies from enemies.
We have discussed how software licenses participate in the community life of two F/LOSS projects. Instead of examining many examples, we have performed an in-depth investigation of two large F/LOSS projects. We have focused on both the process of license choice and on discussions about an existing license.
The licensing controversies which emerged in our cases allow us to argue against a homogeneous view of communities. While the majority of the sociological debate has taken the character of F/LOSS projects as universal, we argue instead that this character is negotiated in everyday practices. Our analysis has elucidated the existence of conflicts about the free/open character of communities, artifacts, and software code.
We further suggest that the complex role of licenses needs to be understood not only from the point of view of the participants' rhetoric but also from the perspective of F/LOSS participants' practices. This shift would allow the social researcher a better understanding of the political, technical, and organizational boundaries around and among the communities.
This paper is a short version of " Free and Open Source Licenses in Community Life: Two Empirical Cases" by Stefano De Paoli, Maurizio Teli, and Vincenzo D'Andrea, First Monday, Volume 13 Number 10 - 6 October 2008.