De Paoli http://www.uic.edu/htbin/cgiwrap/bin/ojs/index.php...

First Monday, Volume 13 Number 10 - 6 October 2008

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.

Contents
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

1 di 16 27/01/2011 15:32
De Paoli http://www.uic.edu/htbin/cgiwrap/bin/ojs/index.php...

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

2 di 16 27/01/2011 15:32
De Paoli http://www.uic.edu/htbin/cgiwrap/bin/ojs/index.php...

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

3 di 16 27/01/2011 15:32
De Paoli http://www.uic.edu/htbin/cgiwrap/bin/ojs/index.php...

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,

4 di 16 27/01/2011 15:32
De Paoli http://www.uic.edu/htbin/cgiwrap/bin/ojs/index.php...

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):

“GNU GENERAL PUBLIC LICENSE”

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):

5 di 16 27/01/2011 15:32
De Paoli http://www.uic.edu/htbin/cgiwrap/bin/ojs/index.php...

“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

6 di 16 27/01/2011 15:32
De Paoli http://www.uic.edu/htbin/cgiwrap/bin/ojs/index.php...

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]).

7 di 16 27/01/2011 15:32
De Paoli http://www.uic.edu/htbin/cgiwrap/bin/ojs/index.php...

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.

4.3 GRASS

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”

8 di 16 27/01/2011 15:32
De Paoli http://www.uic.edu/htbin/cgiwrap/bin/ojs/index.php...

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)

9 di 16 27/01/2011 15:32
De Paoli http://www.uic.edu/htbin/cgiwrap/bin/ojs/index.php...

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

10 di 16 27/01/2011 15:32
De Paoli http://www.uic.edu/htbin/cgiwrap/bin/ojs/index.php...

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

11 di 16 27/01/2011 15:32
De Paoli http://www.uic.edu/htbin/cgiwrap/bin/ojs/index.php...

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

12 di 16 27/01/2011 15:32
De Paoli http://www.uic.edu/htbin/cgiwrap/bin/ojs/index.php...

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.

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.

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

Notes
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. (http://www.sun.com/).

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,

13 di 16 27/01/2011 15:32
De Paoli http://www.uic.edu/htbin/cgiwrap/bin/ojs/index.php...

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.

13. http://www.opensource.org/docs/policy/licenseproliferation.php.

14. http://www.mozilla.org/MPL/MPL-1.1.html.

15. http://www.gnusolaris.org/gswiki.

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.

17. http://grass.itc.it/.

18. U.S. Copyright Act § 105. Subject matter of copyright: United States Government works, at
http://www.copyright.gov/title17/92chap1.html#105.

19. GRASS Development Mailing List Archive, at http://grass.itc.it/pipermail/grass5/.

20. GRASS Users’ Mailing List Archive, at http://grass.itc.it/pipermail/grassuser/.

21. osol — discuss archives, at http://www.opensolaris.org/jive/forum.jspa?forumID=13.

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.

24. http://www.debian.org/social_contract#guidelines.

References
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
http://www.firstmonday.org/issues/issue4_10/bezroukov/, 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 http://slashdot.org
/features/98/10/13/1423253.shtml, accessed 27 January 2007.

Free Software Foundation (FSF), 1999. “Lesser General Public License 2.1,” at
http://www.gnu.org/copyleft/lesser.html, accessed 27 January 2007.

Free Software Foundation, 1991. “GNU/General Public License 2.0,” at http://www.gnu.org

/copyleft/gpl.html, accessed 27 January 2007.

14 di 16 27/01/2011 15:32
De Paoli http://www.uic.edu/htbin/cgiwrap/bin/ojs/index.php...

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 http://grass.itc.it/announces/gnu-release.html, 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 http://www.firstmonday.org/issues/issue6_12/kelty/, 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
http://www2.warwick.ac.uk/fac/soc/wbs/conf/olkc/archive/oklc5/papers/j-3_lanzara.pdf,
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
http://www.firstmonday.org/issues/special10_10/lin/, 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 http://opensource.mit.edu/papers/lin2.pdf, 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 http://blogs.sun.com/webmink/entry

/cddl_reflections, accessed 27 January 2007.

E.S. Raymond, 2003. “The jargon file,” version 4.4.7, at http://www.catb.org/jargon/, 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
http://www.firstmonday.org/issues/issue3_3/raymond/, 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 http://oreilly.com/catalog/opensources
/book/stallman.html, accessed 27 January 2007.

15 di 16 27/01/2011 15:32
De Paoli http://www.uic.edu/htbin/cgiwrap/bin/ojs/index.php...

R. Stallman, 1999b. “Copyleft: Pragmatic idealism,” at http://www.gnu.org/philosophy

/pragmatic.html, accessed 27 January 2007.

R. Stallman, 1986. “BYTE interview with Stallman,” conducted by D. Betz and J. Edwards, Byte
(July), at http://www.gnu.org/gnu/byte-interview.html, accessed 27 January 2007.

R. Stallman, 1985. “The GNU manifesto,” at http://www.gnu.org/gnu/manifesto.html, 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

http://www.opensolaris.org/os/licensing/opensolaris_license/, accessed 27 January 2007.

Sun Microsystems, 2005b. “FAQ: Common Development and Distribution License (CDDL),” at
http://www.opensolaris.org/os/about/faq/licensing_faq/, accessed 27 January 2007.

Sun Microsystems, 2005c. “Common Development and Distribution License (CDDL): Description
and rationale,” at http://www.sun.com/cddl/CDDL_why_details.html, 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 http://www.qualitative-research.net
/index.php/fqs/article/view/283/621, accessed 20 September 2008.

U.S. Army Construction Engineering Research Laboratory (CERL), 1996. “Announcements: Corps
lab ends GRASS development” (29 March), at http://web.archive.org/web/19970619195255
/www.cecer.army.mil/announcements/grass.html, accessed 27 January 2007.

M. Weber, 1904. “The Protestant ethic and the spirit of capitalism,” at http://www.ne.jp/asahi
/moriyuki/abukuma/weber/world/ethic/pro_eth_frame.html, 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 http://gisws.media.osaka-cu.ac.jp/grass04
/viewabstract.php?id=53, accessed 27 January 2007.

R. Wilder, 2005. “How to fight against patent terrorism,” News.com (6 January), at

http://news.com.com/How+to+fight+against+patent+terrorism/2010-1014_3-5513518.html,
accessed 27 January 2007.

Editorial history
Paper received 8 December 2007; accepted 10 September 2008.

“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
http://www.uic.edu/htbin/cgiwrap/bin/ojs/index.php/fm/rt/printerFriendly/2064/2030

16 di 16 27/01/2011 15:32