Free and open source licenses in community life: Two empirical cases
First Monday

Free and open source licenses in community life: Two empirical cases by Stefano De Paoli, Maurizio Teli, and Vincenzo D'Andrea

How do licenses participate in the life of Free and Open Source Software (FLOSS) communities? This paper aims at answering this question.

Despite the dynamic character of FLOSS development, the sociological debate has taken for granted a static perspective of communities, as organized around a restricted range of social values and rules. Criticizing the main sociological approaches to FLOSS communities, we observed in our two cases that, on the contrary, the free/open character of FLOSS should not be assumed as an a priori explanation of the coordination efforts in these communities.

Focusing on the role of software licenses, considered as boundary objects in the daily activities of FLOSS communities, we observe that controversies and conflicts around licenses are fundamental parts of communities’ lives. Basing our research on two different projects, the Geographical Information System GRASS and the OpenSolarisTM operating system, we show how the construction of the free/open character of FLOSS takes place within the debate about licenses.


1. Introduction
2. The debate about FLOSS communities
3. Licenses, boundary objects and translations
4. Software licenses and cases
5. Conclusions



1. Introduction

How do licenses participate in the life of Free and Open Source Software (FLOSS) communities? This paper aims to answer this question. We want readers to understand the role of licenses in the wider construction process of large FLOSS projects. We will show the power of the artefacts called software licenses in building and shaping political and technological boundaries inside FLOSS communities.

Communities [1] of users and developers in large software development projects can be extremely heterogeneous, composed of people with different views on the meaning of FLOSS. Despite the complex character of FLOSS, the sociological debate has taken for granted a static perspective of communities organized around a restricted range of social values and rules. For example, in Himanen’s work (2001) the practices of FLOSS are directly dependent on a Weberian notion of ethics (in Weber’s analysis, ethics is the key factor to explain structural changes, like the development of capitalism; Weber, 1904); and in Kelty’s work (2001) the institutions of FLOSS are built upon Mertonian notion of Cudos (this acronym was coined by Merton to refer to the institutional norms of science: Communism, Universalism, Disinterestedness, and Organized Skepticism; Merton, 1973) [2].

Criticizing the main sociological approaches to the study of FLOSS communities, we observe through two case studies that, on the contrary, the free/open character of FLOSS should not be assumed as an a priori explanation of the coordination efforts in these communities. We observe that controversies and conflicts around licenses, participate in stabilizing the community.

Stabilization is temporarily achieved through the mediation of artefacts, considered not as stable objects but as material elements which are mobilized in practices and co–shape the practices themselves. Within this perspective, a practice is conceivable as “a mode, relatively stable in time and socially recognized, of ordering heterogeneous items into a coherent set.” [3] In addition to being the object and the result of practices, licenses, that is the artefacts we focus on, are also affording the construction and reproduction of these practices.

Yuwei Lin (2005) called for the static sociological view on FLOSS communities to be left behind, to pay attention instead to the heterogeneity and contingency of FLOSS development. As artefacts play a central role in affording certain practices, while discouraging others, thus shaping the FLOSS socio–technical web. Hence, by focusing on artefacts, we are better able to grasp the complexity of communities. We work through Lin’s suggestion by discussing conflictual situations and controversies around software licenses.

Licenses specify the boundaries of the permissions granted by the copyright owner to the user(s). These permissions inhere in a set of practices, which are strongly inscribed in licenses (Lanzara and Morner, 2005), but that can mean different things to different community participants (Lin, 2004). FLOSS’s free/open character is therefore the result of an intricate web of negotiations around the meanings of material artefacts.

Basing our researches on two different projects, we show how the construction of boundaries takes place within debates about licenses. Communities, artefacts, alliances are all co–shaped within these controversies. We examine the cases of the Geographical Information System GRASS and of the OpenSolarisTM [4] operating system. The first project is a GNU GPLed software developed by a worldwide community of voluntary programmers; the second project is a non–GPLed software one, sponsored by a company and released under the CDDL license. Although these two cases are not enough in order to draw generalizations, they allow us to consider different stages in projects evolution, as well as different contexts and licenses.

The paper is organized as follows: a criticism of the prevalent sociological views of FLOSS communities; an introduction of the concepts of translation, boundary object and socio–technical interaction networks; a discussion about two empirical cases of licenses seen as boundary objects; and, a conclusive description of the ecologies around licenses and the relevance of these for both research and industry.



2. The debate about FLOSS communities

The academic understanding of Free and Open Source Software communities has been highly influenced by ideas expressed by Eric S. Raymond. In his most famous essay (1999), the American hacker tried to give a description of Open Source software that has been interpreted by academic researchers through a romantic concept of community as composed of ideally cooperative people (Bezroukov, 1999). Many scholars have adopted Raymond’s simplistic perspective on these subjects. Some sociologist in particular has adopted a perspective on FLOSS communities where no conflict takes place and people share the same way of thinking and doing (i.e., Kelty, 2001; Himanen, 2001), considering the free/open character of FLOSS communities as something given. By taking into account only a limited set of social elements as explaining FLOSS, we lose the complexity of the development process. The sociological research appears reductive, especially in two assumptions: a restricted range of values or rules explains FLOSS development; and the real innovation of FLOSS is merely social, while technology and artefacts are completely left out of the analysis.

We agree with Lin (2005) in thinking that such approaches not only ignore the diversity of the population and its different articulations, interpretation, and performances towards FLOSS development; it also neglects the different environments where FLOSS is employed, developed, and implemented. To look at FLOSS development as a complex constellation of practices — shared among the participants in different social worlds — it helps to take into account the role of public institutions, private companies, programmers, users, and so on (Lin, 2004).

However, this complexity does not lead to chaotic situations. We think FLOSS development is successful not because of uniform values, but because different actors in different contexts make use of objects that facilitate the development of a shared understanding and agreement among those who participate in its construction, as in science and technology generally (Lin, 2004).

An important similar perspective was proposed by Lanzara and Morner (2004; 2005). Sharing with Lin a complex view of FLOSS, they consider this as a dense environment populated by various artefacts, practices and human agents. Noting this complexity, the authors ask several questions about FLOSS development which pose a theoretical challenge to conventional ways of conceptualizing knowledge processes within and across organizations. In their view, complexity is better dealt with by focusing on artefacts such as licenses, mailing lists and the source code, rather than by considering only the social organization of FLOSS (Weber, 2004).

Similarly, Walt Scacchi (2005) proposed the concept of socio–technical interaction networks (STINs). STINs draw one’s “attention to the web of relationships that interlink what people do in the course of their system development work to the resources they engage and to the products they create, manipulate, and sustain.” [5] Starting from a comparative ethnographic study, the author suggests that at least four set of practices are involved in the formation and activity of STINs in FLOSS projects:

  • participating, joining, and contributing to projects;
  • forming alliances and building communities of practices through linked artefacts;
  • coordinating, cooperating, and controlling projects; and,
  • co–evolving social and technical systems.

We use these practices in order to orient our research and the analysis of the huge amount of data collected in ethnographic studies of FLOSS. We will describe the ecologies of software development as involved in the above–mentioned four practices.

In summary, we underline how the most of the sociological literature on FLOSS adopts a reductionist view, while other critical perspectives take into consideration the central role of artefacts in FLOSS practices; artefacts also participate in community life through their involvement in the STINs mobilized and formed during software development. Now we introduce the concept of boundary object and our interpretation of it, in order to define better our analysis of the ways in which the ecologies involved in FLOSS projects take shape around licenses.



3. Licenses, boundary objects and translations

Together with Lin and Scacchi, we assert that FLOSS communities should be analyzed in their complexity; and together with Lanzara and Morner we affirm that we cannot account for the coordination efforts of FLOSS communities without focusing on material artefacts. Our focus is on the role of software licenses, a group of fundamental artefacts in FLOSS development and community life. These artefacts are the legal documents that regulate the copyright relationships between software developers (copyright holders) and software users.

We will treat licenses as boundary objects:

“scientific objects which both inhabit several intersecting social worlds and satisfy 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.” [6]

We draw heavily on Actor–Network Theory (ANT), to specify the concept of boundary object. ANT proposes that a network is achieved and stabilized by assembling various social and non–social entities so that they work together. In other words, ANT affirms that we need to treat humans and non–humans symmetrically, in order to understand how they construct each other and produce action.

At the core of ANT, is the concept of of translation. To translate means to speak on behalf of the others, to redefine roles and decide what may be exchanged among the occupants of these roles. ANT sees the translation processes as composed of four moments (not necessarily separated in time and space):

  • problematization, when an initial whole of actors (spokesmen — who are speaking on behalf of the others) defines a problem to be solved and finds a solution. The goal is to make the solution an Obligatory Point of Passage for the actor–network;
  • interessement, the act of interposing (inter–esse) a device which can create a separation among entities, separating the group of those acting against the spokesmen’s problem solution from a group constituted of those whom do not;
  • enrolment, the multilateral negotiations and attempts that could bring to the interessement success or failure, with the purpose of anticipating what other human and non–human entities can do in opposition to the spokesmen (anti–programs); and,
  • mobilization of allies, the ability to definitely stabilize the heterogeneous associations and make the maximum number of allies act as a whole (Callon, 1986; Latour, 1987).

This approach is based on the consideration that the construction of a stabilized network of alliances can be achieved through the use of intermediaries, namely objects performed by actors that will impose their own version of reality on others. An intermediary is more than an inert object, because it has an ability to interest, enroll and mobilize human and non–human entities (Gherardi and Nicolini, 2005).

To adopt an ANT perspective on FLOSS means that social stability is not taken as self–evident, but it is considered as the result of the construction and enactment of stabilized alliances among both human and non–human entities. Those alliances appear ex post to be solid and unified, but they are actually exposed in medias res to anti–programs and trials of strength.

Some academics have criticized classical ANT because it takes on the point of view of the dominant actors in the network. Several authors have thus introduced an ecological modification, where multiple translations participate in the construction of the Actor–Network (Star and Griesemer, 1989; Gherardi and Nicolini, 2005). Star and Griesemer introduced the ecological view, stressing an understanding of the construction of science and technology as a collective action of the involved participants and their social worlds. Their view of interessement is a “n–way nature of translation” [7] which requires an ecological analysis: the coherence among different points of view occurs thanks to the presence of objects that inhabit the different ecological worlds, maintaining the coherence and allowing different points of view and translations. These object are the boundary objects: therefore, using this concept, we will adopt an ecological ANT perspective in our consideration of license robustness and plasticity.

Licenses are material artefacts of particular interest: by considering them as textual artefacts, it is possible to analyze what practices and political visions are inscribed [8] in a license (robustness), before describing what happens when a license enters a specific community (plasticity).

The robustness of licenses is due to the fact that textual artefacts are heterogeneous actor–networks and powerful intermediaries in the sense described above (Law, 1986; Latour, 1987). 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 [9]. The license’s authors must then construct the text as a whole of heterogeneous and marshaled forces which can prevent anti–programs.

In their plasticity, licenses allow communications among different political, technical and organizational positions, shaping the meanings of participation, alliances and coordination, as we show in regard to the cases we analyze below. Nonetheless, the licenses acquire their form in the interrelation between human and non–human entities in development projects. A license’s robustness takes a plastic and contingent form when the license itself is shared among different social worlds. In our opinion, it is therefore fundamental to adopt an ecological view, in order to understand the construction of science and technology as a set of collective actions of all the participants and worlds involved. Hence, this allows us to account for the need to describe the debates around the licenses. By giving this double meaning to the concept of boundary object, we agree with Chrisman and Harvey (1998) in claiming that boundary objects “are scientific and technological integrators and separators at the same time. They include some groups and artefacts and exclude others.” [10]



4. Software licenses and cases

Thus far, we presented a our theoretical framework that highlights the importance of considering the relations and connections between human and non–human entities involved in FLOSS development. One further question arises: how to follow these connections and relations, joining them with the community life? We will deal with this by referring to cyberethnography (Hakken, 1999; Teli, et al., 2007), which we consider as an assemblage of methods, “practices that can cope with an hinterland of pre–existing social and material realities [...] they detect, resonate with, and amplify particular patterns of relations in the excessive and overwhelming fluxes of real.” [11]

Our focus on the relation among licenses and the community life, brings us to analyze the presentation of the licenses in project websites and in debates that take place in mailing lists. In both cases, data have been collected during two years of field research: in the GRASS case, more than 57,000 messages were considered, 84 of which belonging to the specific discussions presented in this paper; in the OpenSolarisTM case, we draw upon 214 messages out of the about 20,000 that were taken into account. The collection of data was followed by a grounded theory approach (Glaser and Strauss, 1968), a qualitative analysis technique based on an inductive and recursive relationship between data and theory. In our perspective licenses act as boundary objects because they allow the interrelation among the processes considered by Scacchi (2005), namely: participating in the community itself; building alliances and communities of practice both among developers and among different projects; controlling and coordinating everyday practices; the co–evolution of the technical, political and organizational positions.

The presentation of our findings will follow the theoretical framework described above: we start by taking into account the views of the world inscribed in the licenses, and we end up considering the debates among the participants and their communities.

4.1 GNU GPL v. 2.0

In this paragraph we will analyze the GNU General Public License (Free Software Foundation, 1991, Version 2.0). We will follow the statements by Stallman and the Free Software Foundation (FSF), interpreting them as the construction of an Actor–Network and a translation process.

Our analysis of the GNU GPL (simply GPL in the following) has to start from the title, which is an important section of any textual artefact because it sets the wider context to what will follow (Law, 1986):


According to its title, this license is intended to be the GNU license. In order to understand the importance of this statement, we briefly describe the launch and development of the GNU project.

In 1983, MIT programmer Richard M. Stallman (RMS) launched a project for developing an entire UNIX–compatible operating system, known as GNU (GNU’s Not Unix). According to Stallman’s plans, with GNU “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, 1985). Stallman wanted, in fact, to redefine users, sources, programmers and companies. GNU should then be seen as a translation process transforming the pre–existing definitions of computer and programming entities (entities). This re–definition was grounded on the construction of a network of non–human and human entities: an operating system where “complete system sources will be available to everyone” (Stallman, 1985) and the sharing–community of programmers and companies based on the system itself.

As the interest in using GNU grew, other people got involved both in the core development activities and in a tax–exempt charity, the Free Software Foundation, founded in 1985 (Stallman, 1999a). The FSF aims at promoting the use and development of GNU, and plays an important role in the GPL text because it appears, just after the title, as the license author.

In order to impose their own version of reality on others, Stallman and the FSF 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’.” (Stallman, 1999b). The GNU General Public License was born as the intermediary (“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 the FSF plans, by allowing programmers and companies to “own the sources”. For this reason, the FSF goal is to interest the entities listed above and defend them from these licenses. Hence a need to anticipate anti–programs, to negotiate with dissenters, and finally to make the GNU project as an Obligatory Point of Passage (Callon, 1986). According to Stallman (1986):

“I do this by copyrighting the programs and putting on a notice giving people explicit permission to copy the programs and change them but only on the condition that they distribute under the same terms that I used, if at all.”

At this point, Stallman conceived the “hack” called Copyleft, using copyright laws against their usual interpretation. With Copyleft, authors give everyone permission to run, copy, modify their programs and to distribute modifications. On the other hand Copyleft imposes some restrictions on the use of GNU and software in general: GPL will prevent GNU software from being turned into proprietary software. In other words, in order to enroll the entities, GPL prevents the use of “the licenses for most software”, which take away the freedom “to share and change the software”.

The license terms, numbered from 0. to 12., follow the Preamble and compose the third section of the GPL. Among them, the term 2b has a fundamental role in anticipating anti–programs, because it is the inscription of the Copyleft method in the license text:

“b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.”

From the FSF’s point of view this term anticipates a specific anti–program: the use and application of licenses designed to turn software into proprietary programs. The term 2b imposes to distribute the modifications using the same terms of the GPL, even if the modification is a program in a separate file. In this way “the licenses for most software” are separated from the GNU translation process. GPL excludes the possibility of applying a “dangerous” license to the software, meaning by that a license which could turn the software into a proprietary one, making users unable to change and share the software. By means of term 2b, the FSF ultimately anticipate the dangers coming from “the licenses for most software”.

Finally, the last section of the GPL deals with “How to apply this terms to your new programs”: a guide for the application of the GPL to a software. If the GPL is applied to a program, then the enrolled entities (users and software) are mobilized and the GNU translation process is successful.

4.2 CDDL

In this section we will draw a preliminary sketch of the boundaries defined by the Common Development and Distribution License — CDDL (Sun Microsystems, 2005a), offering a description of the different views of the world that are inscribed by Sun in this license.

As specified by the license’s title, Sun aims to foster the construction of a common environment for developers and distributors of OpenSolarisTM. In addition, according to the CDDL FAQ (Sun Microsystems, 2005b), the need for a new license emerges from the convergence of two different phenomena: the need to use a file–based licenses [12] and the so called license proliferation. Therefore, Sun decided to create “a license that was clear, consistent, not burdensome for contributors, and as reusable and general as possible” (Sun Microsystems, 2005b). In order to understand this as a translation process, we need to consider the two above mentioned phenomena which SUN dealt with in the creation of this license. The first refers to the fact that : “the licenses from the various geological eras of software history” (Phipps, 2005) that protect the code included in the Solaris Operating System, are partly regulated by agreements between Sun and other software producers, making it impossible to release the entire system under a program–based license (like for example the GPL), or under a license that allows only dynamic links (like the GNU Lesser GPL, LGPL), leading only the file–based license a possible choice. The second phenomenon, license proliferation [13], is the allegedly excessive increase in the number of file–based licenses, such as the case of the MPL–style licenses, all derived with minor variations from the Mozilla Public License (MPL [14]). We are now going to analyze the license text, trying to understand how these problems have had, ex post, an active role in the construction of the text itself, setting boundaries for the future involvement of participants in the OpenSolarisTM project.

The license begins with the title, “Common Development and Distribution License”, followed by the version number. In the title we have a specification of the actors whom the license tries to interest and mobilize: developers and distributors. The first section of the license is called “Definitions” (Section 1), unlike the GPL, it does not include a Preamble. Therefore we will start our discussion from the “Definitions” which appear, in our analysis, to be the most relevant in order to understand the role of the two phenomena described above (license proliferation and software history). In addition, we will discuss how the “Definitions”, involving the two problems, contribute to the spread of the above mentioned Sun’s view into the social world of software development.

The first thing to be noticed is that CDDL is a file–based license: this means that it only protects/covers the individual files that belongs to OpenSolarisTM, not the program as a whole. This can be noticed at Term 1.3, which states that:

“Covered Software means (a) the Original Software, or (b) Modifications, or (c) the combination of files containing Original Software with files containing Modifications, in each case including portions thereof.” (emphasis added)

Now, how does this Term connects with the phenomenon of legacy license? In order to answer this question, we need to refer to another Term of Section 1: Term 1.6, that defines “Larger Work” as “a work which combines Covered Software or portions thereof with code not governed by the terms of this License.” In this case, the file–based protection allows Sun to combine source files released under the CDDL license with files protected by other licenses. This clause, connected with 3.5, (“Distribution of Executable Versions”), and 3.6, (“Larger Works”), acts in defining who could be the participants in the common to be constructed; a boundary is traced, and people who want to release their larger work under a different license are now included.

One of the aims of this license is to enable the “creation of larger works for commercial purposes” (Sun Microsystems, 2005b); this purpose sets an important difference between CDDL and GPL, shaping the interests of potential participants to FLOSS projects.

The traced boundary not only includes all the above mentioned characters, but it also excludes two groups of developers. Indeed, the presence of the copyleft clause (see 3.1. “Availability of Source Code”, and 3.2. “Modifications”), chosen in order to provide “the protections and freedoms necessary for true open source” (Sun Microsystems, 2005b), exploits the same GPL “hack”, but it paradoxically excludes the possibility of combining CDDL–covered software with code covered by the GPL. Sun seems to share with FSF the idea that copyleft maintains the vitality of the software commons, but this choice divides CDDL developers from GPL developers. The second excluded group is people who want to distribute in a proprietary form their Modifications of the covered files.

The second issue to influence the shape of the license is license proliferation: the increasing number of file–based FLOSS licenses, due to the mobilizing role of Open Source Initiative in enrolling a large number of software companies into the FLOSS scenario. According to Phipps (2005), it seems that there are only four ways to reduce this phenomenon: to use the GPL for everything; to create a chart showing which are the effects of existing licenses, in order to make them reusable; to close the OSI; and to create a small set of generic licenses that can be gently modified. Sun’s declared aim, when proposing the CDDL, is to contribute to the fourth kind of solution, and the license itself was conceived to belong to the small set of licenses. This purpose motivates one of the differences between MPL and CDDL: the possibility to release software under one specific version of the license, without automatically adopting subsequent versions. The rationale of this choice is explicitly declared:

“This change was made to make the license more reusable by others: it addresses the concern that the license steward could change the terms of the license in ways that are not compatible with a community's (and the Initial Developer’s) values and objectives.” (Sun Microsystems, 2005c).

Since actors can now choose the version of the license that best suits their interests, they are more protected from licenses’ modifications: Sun’s purpose with this license is to enable additional actors to be enrolled in the software common. More than that, the aim is to establish new connections with other programs: projects using CDDL will be fully compatible, from the legal point of view, with OpenSolarisTM, entering, in this way, the software common.

In summary, the two issues (license proliferation and history) which influenced Sun’s choices have been translated into legal language in the CDDL license (the above mentioned “Terms”). During this passage, they shape the interests of the potential participants to the community, making them compatible with the software common. In this way, Sun’s view of the world and Solaris’ history are on the one hand shaping the way developers can participate and contribute to the code, as well as, on the other hand, they are selecting potential joiners to the community. At the same time, the license allows the creation of alliances between Sun and other companies (see for example Nexenta, distributing its own version of a GNU/OpenSolarisTM system [15]).

The last aspect we want to highlight is the control enacted by the license by means of the license steward and the “patent peace” provision. The license steward is an entity (Sun in this case) that has the right to change the license, and through this right enacts a form of partial control on the future of the project.

Let us consider now more extensively the “patent peace” provision. In Section 2 and Section 6 there are two different and complementary statements related to the “software patent” subject: Section 2 indicates that both the Initial Developer and the Contributors grant to other users of the software the right to use the patents they could have on the contributed code only within the context of the code itself, that is no right is granted for the use of the patent in developing new code or for any other purpose. Section 6 states that if “you” assert “a patent infringement claim (excluding declaratory judgement actions) against Initial Developer or a Contributor [...] alleging that the Participant Software [...] directly or indirectly infringes any patent, then any and all rights granted directly or indirectly to You by such Participant, [...] shall, [...] terminate prospectively and automatically”. So, since the license explicitly excludes “patent terrorists” (Wilder, 2005) from participating to the software’s common and since it strongly regulates the behavior of them within the community, we can affirm that a mechanism of reciprocity about patents is inscribed in the license. This is a clear and declared tentative to create a “patent–safe developer commons around OpenSolaris” (Phipps, 2005), and it is also considered one of the reasons to exclude GPLv2 [16] as the possible license for the project.

We have just seen that the system history, as well as general issues in software development, such as license proliferation and software patents, have been taken into account in the writing of the license. These aspects also shape the boundary around the potential participants to the projects — both human and non–human — as well as the community behavior. The remaining part of our analysis will focus on the discussions about the relationships between community participants and licenses. These discussions shape both the licenses themselves and the community participation, control, alliances construction, and socio-technical co–evolution.


The Geographical Information System GRASS (Geographic Resources Analysis Support System [17]) was started at the beginning of the eighties as a small development project of the U.S. Army Construction Engineering Research Laboratory (USACerl) and it was distributed as public domain software [18] (PD).

The project attracted other U.S. public institutions into the development and in a few years the GRASS community grew up. In 1993 GRASS source code was approximately 300,000 lines and there were more than 15 locations developing the system, with a development effort estimated as the work of five persons/year (Westervelt, 2004).

In 1996 USACerl decided to stop GRASS development and asked the users to migrate toward proprietary GIS (USACerl, 1996).

In 1998, a new GRASS development team (GDT) was formed with the purpose to re–launch voluntary GRASS development and community. The new GDT was a group of researchers affiliated to several international institutions; the new team took a structure very close to the “town council” model (Cox, 1998), characterized by a restricted group of programmers leading the development of a large project.

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. The GDT had two problems: to manage the copyright of a software developed by the U.S. Army; and, to protect their new modifications and work on GRASS. Despite the existence of different viewpoints inside the GDT, there was an agreement in considering the new versions of GRASS as new works of art based on the previous USACerl GRASS.

In 1999, a discussion on the possibility to release GRASS under a FLOSS license took place in the GRASS users’ mailing lists. After some negotiations, the GDT adopted the GPL (V.2.0) as the copyright license for GRASS software.

The GRASS community found then an agreement by choosing a well–known FLOSS license. GPL has been chosen by the different institutions and individuals participating in the new course of GRASS. Moreover, with the GRASS release under GPL, the GNU translation process was mobilized with a clear definition of the entities: GRASS and its community moved from an uncertain public domain situations toward the GPL copyright protection (GRASS Development Team, 1999).

4.4 “WHY GPL”

The GPL Copyleft “method” represents a form of controversy and a source of discussions within GRASS mailing lists. Controversies and anti–programs around the GDT agreement on the choice of the GPL emerged many times. The Copyleft clause of the GPL excludes the participation of applications with incompatible licenses and their developers. In the anti–programs, the complexity of GRASS community life emerges together with the different positions about the role of GPL in the community itself.

“WHY GPL” is a discussion thread occurred within the GRASS Developers’ Mailing List in March 2001. Some aspects of the GRASS release under GPL were questioned by a list newcomer, that we will call Pippo. Here we will assume Pippo’s point of view while looking at his attempt to impose a new translation on the GRASS framework:

“It is possible for the authors of the original code to re–release their code under the LGPL or another license.”

The proposal to choose the LGPL must be seen as an anti–program against the GPL adoption. LGPL (Free Software Foundation, 1999) is a license of the GNU project used by the FSF to cover specific GNU libraries. Differently from GPL, it allows the integration with almost any kind of software, including proprietary one. The goal of this anti–program is to strengthen the statement “to re–release GRASS with the LesserGPL”, weakening at the same time the current licensing terms (the GPL). Here Pippo is proposing a new problematization with a new and different definition of the involved entities:

“People who may want to write plugins (views, commands (and other controllers), etc.) for the GRASS framework I propose may want to use their own license. If the code is only released in GPL form that’s not allowed given the current (read:RMS) interpretation of the GPL.”
(SA, GRASS DevML [19] — discussion dated 22 March 2001)

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 it 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 the anti–program the identities, roles and desires of the enlisted entities are redefined in a new network of heterogeneous associations. This re–definition can be achieved through the choice of the LGPL by the authors of the original code. With the LGPL, the entities’ identity and roles are once more stabilized: GRASS could be integrated with plugins written for specific applications; participants in GRASS could then use their own licenses: programmers would still be protected in their rights by the LGPL.

At this point the new associations must be tested and the success of the interessement depends on the trials of strength and on the spokesman ability to anticipate others’ objections. Will Pippo be able to make the LGPL, rather than the GPL, the new Obligatory Point of Passage for the GRASS community? Pippo is thus forced to defend his own associations against the GDT previous agreement “to release GRASS under the GPL”:

> 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.”
(EM, GRASS DevML — discussion dated 22 March 2001 (the quoted part is Pippo’s message)


“If end users get accustomed to the proprietary enhancements, the owner of the proprietary rights to get 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.”
(BR, GRASS DevML — discussion dated 26 March 2001)

Here emerges a protection of the GDT agreement on the GPL. For these two GDT members there is no reason to doubt the previous translation result. These members assume that, through a different license (even another FLOSS licenses such as the LGPL), owners of the proprietary rights over a proprietary extension of GRASS can exercise some power on the overall system development. Pippo’s anti–program is then contradicted and his translation attempt fails. The associations defined by Pippo do not resist the trials of strength: the authors would not re–release their code as LGPL, they do not see enough advantages in allowing proprietary applications to link with the system. In this way a newcomer to the Development List (Pippo) is asked not to 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 the GRASS development and community.

The above–described problem with GRASS extensions is then a controversy and a source of discussion within the mailing lists. In September 2003, in the Users’ Mailing List, another discussion took place on the same topic: whether to build proprietary applications for GRASS using some of the system libraries. Below we report a discussion thread to follow the developer Pluto (real name initials are RB):

> because not all GRASS developers agree with Pluto’s mission to
> promote the development of proprietary software on top of GRASS.

It really seems, that I am last to leave the GRASS boat, but it is not clear what other developers want. So I want to ask developers contributing to GRASS, if they could clearly say, if it is acceptable for them, to open GRASS for proprietary applications. That means to relicense some libraries, probably gis, vector and dbmi to LGPL or similar license.”
(RB, GRASS UsersML [20] — discussion dated 18 September 2003)

A problem raised by a developer — a member of the GDT — is that the copyleft nature of the GPL is a limit. In his arguments a less restrictive license would allow the construction of niche proprietary applications for geographic data management, drawing more individuals to GRASS development and use. However, the permissions and restrictions — raised by the GPL — are seen by other developers as important to the GRASS community:

“For my part, I don’t want to see any of GRASS re–licensed under terms other than the GPL.”
(GC, GRASS UsersML — discussion dated 18 September 2003)

Once again, around the GPL, we can recognize a boundary defining different and conflictual positions, this time inside the GDT core. The GPL Copyleft character is again a source of controversies. However, the separation in this case is not as radical as before. Pluto disagrees with the Copyleft method adopted for GRASS: nonetheless, he still participates in the GRASS development as an important GDT member. Thus, whereas in the 2001 case the consequence was a separation from the GRASS framework of both the developer and his code, in the 2003 case, Pluto and his code still participate in the development of GRASS. However, Pluto is allowed neither to develop proprietary application for GRASS, nor to carry on his anti–program.

4.5 OPENSOLARIS, or “CDDL & GPL incompatible, what does it mean?”

The thread we describe in this section was started by a non–developer member of the community, who asked how it is possible that the project includes some GPLed software when CDDL and GPL licenses are considered incompatible by the Free Software Foundation. There are actually three debates within this thread, and they all took place between July and September 2005. The first one, started with the above mentioned question and reached a conclusion in two days, with the specification (mainly by Sun’s employees) that the GPLed software included in the project is composed of separated programs, not linked modules: in this way each license is applied to the respective programs. In this sense the participation boundaries are shaped by different technical ways to connect different software, and the license issue acts as a boundary object between developers and non–developers in the definition of a “technical” concern.

The second round, lasting 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.”
(AR, osol — discuss [21] discussion dated 8 July 2005)

The post involved both part of the license text and the use of conflictual expressions, like FUD [22]. Four answers followed this post, the last of which contained a link to the “CDDL Reflections” by Phipps (2005) that presented Sun’s position on the subject. In this case, the political boundaries between different licenses and Sun’s positioning in the FLOSS panorama were defined through the action of a recognized spokesman.

The third round was debated even more vigorously: it lasted one month and involved a much larger number of posts than the previous two [23]. 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.”
(RF, osol — discuss, discussion dated 19 August 2005)

The long post included three passages aimed at supporting the author’s argument: the need to ask directly the FSF’s opinion; the need for the license compatibility in order to make the project flourish; the author’s withdrawal from the project in relation to the perceived hostility towards the GPL. In this message, the author’s participation and the alliance between the project and the Free Software movement are connected by the licenses. The discussion went on, involving the GPL role also with some messages from Stallman, and the argument mixing continued with other issues: the requests for modifying the CDDL and the GPL in order to improve their compatibility; the GPL perception as a constitutive element of the Open Source movement; the definition of the OpenSolarisTM community itself and of its participants/users. Let us take a look at these messages:

“the bottom line is that opensource developers and users want their software to be GPL. if it is not then these people will be turned off by opensolaris.”
(MW, osol — discuss, discussion dated 20 August 2005)


“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. [...] It would make it more attractive those developers that actually care about the license, or are GPL zealots. The majority of users don’t care what license a program is under. They just like good software.”
(SW, osol — discuss, discussion dated 20 August 2005)

What is involved and shaped during this debate are the meanings of different entities: open source developers and users, a group of “GPL zealots”, the majority of users, and the participants in OpenSolarisTM. A lot of messages involved the CDDL’s political positioning, mainly in relation to the distinction between the Free Software movement and the Open Source one (Stallman, 1999a). Since this complex topic is not the focus of this paper we will proceed analyzing other messages (see Best, 2003, for an account of this complexity).

At the beginning of September, a non–Sun member posted a series of messages commenting on previous e–mail messages. He dealt with both technical matters and philosophical topics, entering directly the debate with a lot of participants. After some posts, another participant made explicit the author’s Debian membership and that he was exploring the possibility of assembling a Debian version based on the OpenSolarisTM kernel. What is relevant for our analysis in this exchange is the role of one clause, the so–called choice–of–venue clause, that allows the choice of the jurisdiction by the Initial Developer and its communication in a note at the end of the license. The problem arose because:

“The CDDL is possibly considered non–free by Debian because of the choice of venue clause. And since the Debian DFSG was what evolved later in the OSI guidelines, that indeed carries some weight.”
(SL, osol — discuss, discussion dated 7 September 2005)

In this case, a clause unproblematic for FSF (as declared explicitly in a post by Stallman), which does not therefore constitutes a boundary with the Free Software movement, is acting as a boundary with a different FLOSS project. At the time of writing, the matter is still evolving. So licenses and the debate around them not only include/exclude and shape individuals but also shape the construction of alliances, involving also other artefacts (i.e., the DFSG, Debian Free Software Guidelines [24]) and suggesting changes in the license itself. The debate was long and continued to involve also other matters not discussed here, in order to focus our attention on the main result of our research. Licenses regulate FLOSS projects, both as artefacts that carry views of the world, and as boundary objects in the mutual definition of entities that participate in software development.

As a final example, let us consider the debate on the mailing lists themselves:

“Irrelevant discussion on an open source project mailing list is a cancer. It must be cut out to prevent those of us with high email loads from unsubscribing. Pretty soon, the only people left on the mailing list will be the ones not working on the project. BTW, that is also why Apache project lists are called ‘dev’, not ‘discuss’, since it narrows the acceptable discussion to something that active engineers can keep up with and still do their work.”
(RF, osol — discuss, discussion dated 7 September 2005)


“Some engineers and managers have, indeed, unsubscribed — primarily due to flames, unfocused discussion, and volume. [...] Around mid–pilot we started creating more lists to try to distribute the load so the technical conversations would not get lost. The most substantive technical conversations are happening on code, DTrace, etc. However, we do need a venue for newcomers and general issues that are project–wide. Although this is certainly developer program, we do want to grow and get more diverse over time.”
(JG, osol — discuss, discussion dated 7 September 2005)

This discussion, related to coordination, was introduced by a topic debated at length: the license matter, through the intermediating role of mailing lists, is enacting relationships among the individuals participating in the project. At the same time, some participants do not accept being aligned with the license discussion, and they criticize the intermediary organization itself. As a result of the debate, the coordination of the entire project is questioned. Once again, the license is a boundary object that allows one to draw a separation between allies and anti–programs.



5. Conclusions

In this paper, we have discussed how software licenses participate in the community life of two FLOSS projects. Our analysis has been based on an ecological view of Actor–Network Theory. In our in–depth investigation of two large FLOSS projects, we have focused on both the process of license choice and on discussions about an already chosen license.

The controversies about licenses emerging in our cases allowed us to argue against a homogeneous view of communities. While the majority of the sociological debate has taken the free/open character of FLOSS projects as given and universal, we argued instead that this character is negotiated in everyday practices. Our analysis has elucidated the existence of conflicts about the free/open character of communities, artefacts, and software code.

According to the socio–technical perspective (Lanzara and Morner, 2005; Lin, 2005; Scacchi, 2005), artefacts have to be considered in the study of FLOSS, because of their ability to connect different social worlds and to support socio–technical interactions. Looking at licenses as artefacts and at social practices, we have been able to show that they participate in the construction of both relational ecologies and political and technical boundaries. From this point of view, these legal artefacts act as boundary objects (Star and Griesemer, 1989), co–participating in the construction of an ecology of practices in community life. In our cases, conflicts and agreements relationally redefine legitimate participants, network of alliances, artefacts, technologies, and communities themselves. For instance, we have described how the attempt at building an alliance between the Debian project and OpenSolarisTM was mediated by the license, whose provisions lead to unexpected outcomes, such as the debate about the “choice–of–venue” clause, the one discussing the mailing list name, and the questioning of the whole project coordination. In the GRASS case, the conflicts related to the GPL license don’t always exclude developers from participation, while they exclude proprietary code from the system.

As a final remark, we 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 FLOSS participants practices. This shift would allow the social researcher a better understanding of the political, technical, and organizational boundaries around and among the communities and their life. End of article


About the authors

Stefano De Paoli has a PhD in Sociology and Social Research, from the University of Trento (Italy). He is now postdoctoral researcher at the National University of Ireland, Maynooth. His research interests comprises different aspects of Information Systems, in particular phenomenology of software development and software licenses.

Maurizio Teli, PhD in Sociology and Social Research, University of Trento (Italy), has a background in Political Science. He is involved in and researches about the importance of FLOSS “practices of freedom” in the processes of organizing a community and producing technology.

Vincenzo D’Andrea is an associate professor at the University of Trento, where he teaches Information Systems. His research interests includes service–oriented computing, free and open source licensing, virtual communities.



We thank the colleagues Camilla Rossi, Gabriella Coleman, and David Hakken, for their interest in our work and for their valuable comments.



1. The debate on the notion of community is a quite rich one, but we don’t want to address it in this paper. We will use the term community referring to the fact that FLOSS developers and users define themselves with this term.

2. Although Himanen and Kelty are not sociologists themselves, they base their argumentation on two authors that are considered classics in sociology, such as Max Weber and Robert K. Merton. For this reason we consider them as participating to the sociological debate.

3. Gherardi, 2006, p. 34.

4. OpenSolarisTM and Solaris are trademarks of Sun Microsystems, Inc. (

5. Scacchi, 2005, p. 2.

6. Star and Griesemer, 1989, p. 393.

7. Star and Griesemer, 1989, p. 389.

8. Inscription is the act of inscribing in an artefact a framework of action which defines “actors with specific tastes, competences, motives, aspirations, political prejudices, and the rest, and assumes that morality, technology, science and economy will evolve in particular ways” (Akrich, 1992, p. 208).

9. Except few cases, FLOSS licenses have not been litigated in courts, so we have to focus on their textual power that, as we show in this paper, is important in establishing constraints for developers even without an actual litigation.

10. Chrisman and Harvey, 1998, p. 1690.

11. Law, 2004, pp. 13–14.

12. Program–based licenses apply to the program as a whole, while file–based licenses apply to each individual source file separately. These are considered more flexible in composing source files covered by different licenses.




16. While GPLv3 contains an explicit patent provision, this is not the case for GPLv2, which was the available version at the time of the writing of CDDL.


18. U.S. Copyright Act § 105. Subject matter of copyright: United States Government works, at

19. GRASS Development Mailing List Archive, at

20. GRASS Users’ Mailing List Archive, at

21. osol — discuss archives, at

22. Fear, Uncertainty and Doubt, normally used to “refer to any kind of disinformation used as a competitive weapon” (Raymond, 2003).

23. The first two rounds together involved thirteen posts, the third two hundred.




M. Akrich, 1992. “The description of technical objects,” In: W. Bijker and J. Law (editors). Shaping technology/building society: Studies in sociotechnical change. Cambridge, Mass.: MIT Press, pp. 205–224.

K. Best, 2003. “Beating them at their own game: The cultural politics of the open software movement and the gift economy,” International Journal of Cultural Studies, volume 6, pp. 449–470.

N. Bezroukov, 1999. “Open source software development as a special type of academic research (critique of vulgar Raymondism),” First Monday, volume 4, number 10, at, accessed 27 January 2007.

M. Callon, 1986. “Some elements of a sociology of translation: Domestication of the scallops and the fishermen of Saint Brieuc Bay,” In: J. Law (editor). Power, action and belief: A new sociology of knowledge? London: Routledge & Kegan Paul, pp. 196–223.

N. Chrisman and F. Harvey, 1998. “Boundary objects and the social construction of GIS technology,” Environment and Planning A, volume 30, number 9, pp. 1683–1694.

A. Cox, 1998. “Cathedrals, bazaars and the town council,” Slashdot, at, accessed 27 January 2007.

Free Software Foundation (FSF), 1999. “Lesser General Public License 2.1,” at, accessed 27 January 2007.

Free Software Foundation, 1991. “GNU/General Public License 2.0,” at, accessed 27 January 2007.

S. Gherardi, 2006. Organizational knowledge: The texture of workplace learning. Oxford: Blackwell.

S. Gherardi and D. Nicolini, 2005. “Actor–networks: Ecology and entrepreneurs,” In: B. Czarniawska and T. Hernes (editors). Actor–network theory and organizing. Copenhagen: Copenhagen Business School Press, pp. 285–306.

B.G. Glaser and A.L. Strauss, 1968. The discovery of grounded theory: strategies for qualitative research. London: Weidenfeld and Nicolson.

GRASS Development Team (GDT), 1999. “Press release, GRASS GIS released under GNU–GPL,” at, accessed 27 January 2007.

D. Hakken, 1999. Cyborg@cyberspace? An ethnographer looks to the future. New York: Routledge.

P. Himanen, 2001. The hacker ethic, and the spirit of the information age. New York: Random House.

C.M. Kelty, 2001. “Free software/free science,” First Monday, volume 6, number 12 (December), at, accessed 27 January 2007.

G.F. Lanzara and M. Morner, 2005. “Artifacts rule! How organizing happens in open software projects,” In: B. Czarniawska and T. Hernes (editors). Actor–network theory and organizing. Copenhagen: Copenhagen Business School Press, pp. 67–90.

G.F. Lanzara and M. Morner, 2004. “Making and sharing knowledge at electronic crossroads: The evolutionary ecology of open source,” Paper presented at the Fifth European Conference on Organizational Knowledge, Learning and Capabilities, Innsbruck, Austria; version at, accessed 20 September 2008.

B. Latour, 1987. Science in action: How to follow scientists and engineers through society. Milton Keynes: Open University Press.

J. Law, 2004. After method: Mess in social science research. London: Routledge.

J. Law, 1986. “The heterogeneity of texts,” In: M. Callon, J. Law and A. Rip (editors). Mapping the dynamics of science and technology: Sociology of science in the real world. London: Macmillan, pp. 67–83.

Y. Lin, 2005. “The future of sociology of FLOSS,” First Monday, Special Issue 2: Open Source, at, accessed 27 January 2007.

Y. Lin, 2004. “Hacking practices and software development: A social worlds analysis of ICT innovation and the role of Free/Libre Open Source Software,” Unpublished doctoral dissertation, University of York, U.K.; version at, accessed 20 September 2008.

R.K. Merton, 1973. “The normative structure of science,” In: R.K. Merton (N.W. Storer, editor). The sociology of science: Theoretical and empirical investigations. Chicago: University of Chicago Press.

S. Phipps, 2005. “CDDL reflections” (13 July), at, accessed 27 January 2007.

E.S. Raymond, 2003. “The jargon file,” version 4.4.7, at, accessed 27 January 2007.

E.S. Raymond, 1999. The cathedral and the bazaar: Musings on Linux and open source by an accidental revolutionary. Sebastopol, Calif.: O’Reilly; see also E.S. Raymond, 1998. “The cathedral and the bazaar,” First Monday, volume 3, number 3 (March), at, accessed 20 September 2008.

W. Scacchi, 2005. “Socio–technical interaction networks in free/open source software development processes,” In: S. Acuna and N. Juristo (editors). Software process modeling. New York: Springer, pp. 1–28.

R. Stallman, 1999a. “The GNU operating system and the free software movement,” In: C. DiBona, S. Ockman and M. Stone (editors). Open sources: Voices from the open source revolution. Sebastopol, Calif.: O’Reilly, at, accessed 27 January 2007.

R. Stallman, 1999b. “Copyleft: Pragmatic idealism,” at, accessed 27 January 2007.

R. Stallman, 1986. “BYTE interview with Stallman,” conducted by D. Betz and J. Edwards, Byte (July), at, accessed 27 January 2007.

R. Stallman, 1985. “The GNU manifesto,” at, accessed 27 January 2007.

S.L. Star and J.R. Griesemer, 1989. “Institutional ecology, ‘translations’ and boundary objects: Amateurs and professionals in Berkeley’s Museum of Vertebrate Zoology, 1907–39,” Social Studies of Science, volume 19, number 3, pp. 387–420.

Sun Microsystems, 2005a. “Common Development and Distribution License,” at, accessed 27 January 2007.

Sun Microsystems, 2005b. “FAQ: Common Development and Distribution License (CDDL),” at, accessed 27 January 2007.

Sun Microsystems, 2005c. “Common Development and Distribution License (CDDL): Description and rationale,” at, accessed 27 January 2007.

M. Teli, F. Pisanu, and D. Hakken, 2007. “The Internet as a library–of–people: For a cyberethnography of online groups,” Forum Qualitative Sozialforschung/Forum: Qualitative Social Research, volume 8, number 3 (September), article 33, at, accessed 20 September 2008.

U.S. Army Construction Engineering Research Laboratory (CERL), 1996. “Announcements: Corps lab ends GRASS development” (29 March), at, accessed 27 January 2007.

M. Weber, 1904. “The Protestant ethic and the spirit of capitalism,” at, accessed 30 June 2008.

S. Weber, 2004. The success of open source. Cambridge, Mass.: Harvard University Press.

J. Westervelt, 2004,. “GRASS roots,” Paper presented at the FOSS/GRASS Users Conference (12-14 September, Bangkok), at, accessed 27 January 2007.

R. Wilder, 2005. “How to fight against patent terrorism,” (6 January), at, accessed 27 January 2007.


Editorial history

Paper received 8 December 2007; accepted 10 September 2008.

Creative Commons License
“Free and open source licenses in community life: Two empirical cases” by Stefano De Paoli, Maurizio Teli, Vincenzo D’Andrea
is licensed under a Creative Commons Attribuzione-Non commerciale-Condividi allo stesso modo 3.0 Unported License.

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

A Great Cities Initiative of the University of Illinois at Chicago University Library.

© First Monday, 1995-2014.