Constant Verlag*

Group by
Language
 
.

From source code to text code: textual norms and practices in the Debian community

Translation: Nil Ramos

Introduction

Charters, codes of conduct, manuals, technical documents, user guides … The internet is flooded with a multitude of textual resources aimed at directing and framing the digital activities of collectives and individuals. This abundance of text eventually creates an information cloud whose role and influence on the activities of internet users still remains unclear.

In this text, I would like to suggest a few ideas for thought on this phenomenon, by examining the “textual practices” of the members of an online community dedicated to developing free software. I will try to show and understand how various textual resources are created, negotiated and discussed by the community members in order to support the main activity of software development.

To shed a light on this phenomenon, I will use an ethnographic approach, more specifically a field survey about the Debian community, whose aim is the development of an operating system based on the Linux core [1]. I will not only look at the purely technical work but also at how participants in the Debian project are in constant dialogue with a multitude of textual resources. As we will see, these texts – founding documents with a philosophical or ideological character, legal documents (such as licences) and technical documents (such as developers’ guides), aim to organise the modalities for participation, cooperation and mutual help within the project.

In general, my aim is to point out how closely (source) code and text are linked in “the free movement”. Even though both of these elements have a prescriptive character of their own, it is by looking at their conjunction that we can gain an understanding of the driving forces behind a project such as Debian.

It should be noted from the start that “the free movement” is based on an unusual hybrid technical-legal status: the link between a computer programme and a legal text, between software and a copylefted licence. The copyleft mechanism is so original because it translates the recognised rights of the author, automatically granted through legal rules in terms of intellectual property, into freedom for the users, by formalising them in a licence in which the author defines the conditions for the exploitation of his work. In practice, this means the demands in terms of liberty stated by the original author are likely to spread; automatically, they will apply to each new copy of the software and to every derived piece of software. This reversal of the copyright principles to the benefit of freedom for users shows the genius of the free software movement. The copyleft concept derives its efficiency from the legal framework, and its originality lies in turning it inside out to safeguard the “viral character” of the original work. “Free” software is software that, as if by contagion, propagates and contaminates every derived programme and all subsequent acts of distribution [2]. As Ph. Laurent puts it: “is there anything more admirable than a right allowing the elaboration of its opposite … than a system based on the appropriation of intellectual rights on works that allows authors to refuse, by means of licence contracts, this appropriation and prevents anyone to claim these rights, to the benefit of an entire community? [3].

Besides the free or copylefted licences, I will stress that within the Debian project, there is a series of founding texts through which members can be “educated” and practices can be normalised, texts that are used by the debianists to gradually build up a prescriptive aspect to their commitment. They should be considered, in the terminology of B. Latour, as actors, i.e. entities that sustain the practices, mobilising and unifying members in order to build a collective, to build what some people would call social or community aspects [4].

I. A brief portrait of the Debian project

The Debian community, involving the participation of several thousands of individuals all over the world, both users and developers, turns out to be a crucial, unique entity in this network movement championing “freedom of software”. It distinguishes itself through the role it has played in the history of this movement but also by its high level of sophistication, both in terms of technology and organisation.

From a technical point of view, the Debian project, as indicated on its website, is an “association of individuals who have made common cause to create a free operating system”. An operating system is a set of basic programmes and utilities allowing a computer to function. However, the Debian project is much more than just an operating system. Indeed, Debian is one of the principal Linux distributions, i.e. a coherent set of tools and components: a Linux core, of course, but also software (a web browser, an e-mail reader, an FTP server, etc.), a method to easily install and uninstall these programmes and an installation programme for the operating system.

It is customary within the free software movement to point out the enormous technical dimension of the Debian project by referring to the number of packages in the distribution. Today, it contains more than 16,000 packages, i.e. pre-compiled software components conceived with the aim of being easily installed on a computer. In this regard, Debian has the largest ready-to-use library of all Linux distributions.

The Debian distribution not only has an astounding number of packages, it is also, in contrast to its competitors, available for a large number of different architectures. The Debian distribution will work on a wide range of systems, from palmtops and PDAs to supercomputers and nearly every type of machine in between. Here again, Debian is gigantic; its competitors usually limit themselves to one or two different types of architecture.

Today, Debian is the last remaining major Linux distributor that is not a commercial entity. It is the result of the work of an worldwide association composed of a thousand developers, most of them based in North America and Europe. When it comes to the characterisation of Debian, the field survey has revealed that two socio-political aspects are regularly mentioned in free software fans’ descriptions of the Debian project.

On the one hand, it is characterised by the permanent ambition to offer users software of the highest technical quality, which leads most of them to qualify the project as something “for purists”. On the other hand, it is characterised by a high degree of transparency and formalisation with regard to its organisation, decision-making and software development processes. Debian has a series of “prescriptive” documents, such as a Social Contract for users and a Constitution for the organisation of the project. Furthermore, in order to reach and maintain the highest possible levels of quality, Debian has adopted a whole set of technical rules and procedures aimed at facilitating and coordinating the work of the developers.

II. Textual resources

Amongst the wide range of documents used within the Debian project framework, we can identify five types of textual resources. We will briefly discuss them below.

A. Documents with a “philosophical” character: the Social Contract

A few years after the launch of the Debian project (1993), the project members felt the need to formalise their approach in several texts they themselves describe as “founding”. The main ones are the Debian Social Contract and the Debian Free Software Guidelines. These texts constitute the axiological, perhaps even ideological base of the project, and therefore have an explicitly militant tone. In general, the aim was to confirm a series of principles in order to set out the underlying “free philosophy” of the project activities, and to establish a certain number of guidelines in this perspective.

The main founding document at the base of the Debian project is usually called the Social Contract, a term implying a great philosophical weight … The elaboration of such a social contract has to happen within a certain context. For one thing, the apparition of the famous GPL and other licences consecrating the copyleft principle in various ways, led to an increasing number of problems for the Debian project members to accurately define what could be considered free and what not. Besides the confusion about the multiplication of concurring licences, there was also the fact that Debian had never clearly indicated which criteria should be taken into account to define “freedom of software”.

It is interesting to look at the title of the message sent by B. Perens, project leader at the time, to announce this event to the Debian project members, as it gives a clear insight into the intentions of the author and his partners. This text, titled Debian’s ‘social contract’ with the free software community, aims to be much more than just a document for the sole use of the Debian project: it not only wants to clarify the Debian commitments towards the “open source community”, but also aims to position the Debian project within this upcoming movement, thereby acting as a model. In the same message, we can read the following statement: “We hope that other software projects, including other Linux distributions, will use this document as a model. We will gladly grant permission for any such use”. This wish, expressed at the time by the Debian project leader, was later fulfilled. Indeed, other distributions such as Gentoo inspired themselves on the Debian Social Contract, adding certain clarifications or changes when needed.

B. Documents with a “legal” character: free licences

Documents with a legal character – the licences associated to software [5] – make up a large part of the textual resources within the Debian project.

To correctly understand the importance of this type of resource, one should know that the majority of the work by Debian developers consists in packaging existing software, i.e. software they did not develop themselves within the Debian project. Most Debian developers first and foremost play the role of a maintainer. As such they differ from proper developers who write software, in that they usually start with existing software and transform it into a package in order to include it in the Debian distribution.

Within this framework, during their packaging activities Debian developers will occasionally have to take into account the terms and conditions of the user licences associated to the software they are using, as determined by the original authors.

C. Documents with an “institutional” character: the Constitution

The Debian project is characterised by a high level of sophistication in terms of organisation and policies. To coordinate the participation of a thousand or so developers, over the years the members have edited a set of documents formalising policies regulating the organisational structure and the decision-making processes of the project.

In this domain, the central document is the “Constitution”. The aim of this document is to describe the status and role of a certain number of people and institutions central to the Debian project organisation. In particular, the Constitution specifies their prerogatives and responsibilities, the way they are appointed and their composition. Furthermore, it dictates a set of rules concerning the various decision-making processes that are essential to the proper functioning of the project.

In its second article, the Constitution lists the “decision-making bodies and individuals”; amongst them are: the developers, the Project Leader, the Technical Committee and/or its Chairman, the individual developer working on a particular task, the delegates appointed by the Project Leader for specific tasks, the Project Secretary. Even though there is a multitude of institutional figures, the developer is still the paradigmatic character amongst the Debian project organisation. Not only will the developer be consulted before any decisions are made, he is also vested with certain powers formally defined by the Constitution, which are liable to have a considerable impact on the directions the project is taking. Next to the technical mastery regarding the software packages he is responsible for, he also has the right, in accordance with Debian’s typical democratic working ways, to propose or support new rules (general resolutions) and to vote during resolution procedures and project leader elections.

D. Documents with a “technical” character: developer’s guides

The technical documents often constitute a set of good practices, not only meant to facilitate the technical work but also, and chiefly, to coordinate the actions of developers worldwide.

The most crucial technical document is the Debian Policy; it establishes a complex set of technical standards aimed at ensuring the quality of the packages and the perfect interoperability and functionality of all the packages forming the distribution. This policy, which is essentially prescriptive, mostly tackles issues related to the design of the operating system and the technical requirements that every package has to fulfil in order to be included in the distribution. One of the essential characteristics of this document is its flexibility. Whoever wishes to do so – this includes experienced users or external developers – can suggest modifications to the Debian Policy after submitting a bug report (severity: wishlist) about the policy. Any developer who is a member of the project can turn it into an official proposal that will be subject to discussion in the discussion list created for this purpose. In case of consensus the amendment will be applied to the text by a specific group of maintainers. The editorial process of the charter is relatively open and permanently evolves whenever new proposals emerge.

This policy, a true technical bible, is completed by a series of more informative documents. One of the most important of these documents is the Debian Developer’s Reference. This document aims to give a general view of the procedures to be followed and the resources at the disposal of Debian developers. The procedures explain, amongst other things, how to become a Debian maintainer, how to create new packages, how to manage bug reports, how to move, delete or abandon a package, etc. The resources in this manual concern the technical tools allowing developers to complete their work.

E. Documents with an epistemic character: discussion lists and archives

Globally, the Debian project is based on two cognitive modes of cooperation: assistance and collaboration. Concretely, this dual cooperation is generally organised through discussion lists which are the preferred method of communication [6]. This makes them valuable indicators of the activities within the project. In this regard, it should be noted that these lists allow for a specific form of organisation and cognitive division of the work between users and developers [7], which manifests itself most obviously when one pays close attention to these discussion lists.

At first, one cannot help but be surprised by the large number of discussion lists the Debian project offers participants (around 160 of them) and the enormous variety of topics discussed. This multitude reflects the various types of segmentation within the project. The large variety of themes tackled in the discussion lists is an indication of the broad range of tasks that need completing in order to keep this project going. Hence there is a large number of lists dedicated to specific activities such as the bug tracking system, translation and localisation problems, legal issues, the core of the operating system, graphic environments, etc. This “technical/themed” segmentation is superimposed by a “geographical” segmentation. Indeed, there are various lists based on geographical areas or linguistic groups, such as debian-french, debian-chinese, debian-russian, etc.

Furthermore, some lists are solely dedicated to informing participants about events and news. These “news” type lists (debian-annonce, debian-news) do not generate any discussion threads but instead inform members about the work in progress and notable events in the life of the collective.

Finally, there is one essential characteristic of these lists that needs mentioning: the fact that they are mostly publicly and freely accessible; those who wish to do so can subscribe to the lists and the discussions taking place. Thanks to this openness, users and developers often come together in the same list.

The use of these lists requires a certain learning process. More specifically, one needs to learn how to find one’s way in this gigantic labyrinth of archives and discussion lists. Knowledge of the archives makes it possible to actively take part in the discussion lists, by asking the right questions or making valid contributions. Otherwise one runs the risk, for instance when asking an irrelevant question, to be told off, usually with a request to read the topic in which the issue was previously discussed. In extreme – although thankfully rare – cases, less tolerant users will retort with a snappy RTFM (Read the Fucking Manual) of STFW (Search The Fucking Web).

III. The Social Contract

In this section we will have a closer look at the so-called “founding” documents of the project, to underscore their surprising vitality.

A. Two “mirroring” texts

The Debian Social Contract is divided in two parts mirroring each other, that should be read as such: one about the commitments of the Debian project towards the “free software community”, the other about the principles of free software according to Debian.

1. The commitment towards the “free software community”

This part of the Contract specifies the commitments of the Debian project towards the “user community”; it is based on five statements which are briefly discussed below.

a) “Debian will remain 100% free”

This statement is the golden rule of the Debian project; it confirms the free status of all software developed by Debian. In particular, it states that the system and all of its components are and will remain free, in accordance with the Debian Free Software Guidelines. The statement, however, adds that the Debian project aims to support people who create and use both free and non-free work on Debian.

b) “We will give back to the free software community”

This statement intends to confirm a principle of cooperation, distribution and sharing of knowledge. On the one hand, it aims to ensure that the new components of the Debian system are published under a licence that is compatible with the Debian Free Software Guidelines so that they can be widely spread and used. On the other hand, it is important to report bug fixes, improvements, user requests etc. to the authors of the original works included in the Debian system.

c) “We will not hide problems”

This statement bestows a principle of transparency. The development of a large operating system such as Debian is a permanent work in progress, as reflected by the threefold elaboration mentioned before: every day, there are weaknesses to be improved, problems to correct. All these bugs are classified in a database accessible to everybody at all times. There is the will to provide the clearest possible information about the progress and the quality of the system, to keep users informed.

d) “Our priorities are our users and free software”

This statement, formulated in very general, perhaps even ambiguous terms, stresses Debian’s commitment towards its users. On the one hand, it aims to satisfy their technical needs by providing them with a quality system working on a wide range of architectures. On the other, it reiterates Debian’s particular commitment to the “free movement”; it stipulates that Debian will not oppose non-free works functioning on its system and Debian will allow, without asking for any compensation, others to create distributions containing combinations of Debian software and other works.

e) “Works that do not meet our free software standards”

With this statement, Debian recognises and accepts that its users wish to be able to use works that do not conform to the Debian Free Software Guidelines. To this end, even though non-free works are not officially part of the Debian system, its members commit themselves to take their use into account and to deliver the necessary infrastructure (such as the bug tracking system and the mailing lists).

2. Debian Free Software Guidelines

The document called Debian Free Software Guidelines (DFSG) states the criteria used by the Debian project to determine whether work is “free” or not. In a way this text constitutes the “free code” according to Debian and acts as a reference to determine which software is sufficiently free in order to be included in Debian. More specifically, the goal here is to determine whether or not the licence pertaining to this or that software conforms to these principles, so that it can be added to the main section of the distribution.

It is important to point out that the Debian distribution is divided into three sections: main, non-free and contrib. The main section is the most important one in Debian and constitutes the official Debian GNU/Linux distribution. It contains most of the packages. In principle, all packages in the official Debian distribution are free, i.e. compliant with the definition in the Debian Free Software Guidelines (DFSG) and all other recommendations outlined in the Debian charter. This guarantees the free use and redistribution of the packages and their complete source code. However, Debian also delivers software packages that cannot be distributed in the main archive for legal reasons or because their licences are too restrictive. Because they do not adhere, to various degrees, to the free concept according to Debian, they are not officially part of Debian GNU/Linux and they are stored in separate sections. The non-free section contains all the packages that are not compliant with the DFSG. They are no longer officially part of the distribution and are not maintained by the Debian developers. The contrib section is designed for packages that are compliant with the DFSG but depend on a package in the non-free section. To correctly understand the importance of the presence of non-free packages in this distribution, one should keep in mind that the majority of the work by Debian developers consists of packaging existing software, i.e. software they did not develop themselves within the Debian project. Within the framework of their packaging activities, the developers have to take into account the terms and conditions of the user licences pertaining to the software they are processing.

This text, rather than being just a simple evaluation roster, carries with it a certain “historical” weight, as it served as a model for the definition of “Open Source”, one of the first formal definitions of free software. Indeed, a few years after their promulgation, Bruce Perens withdrew every reference to the Debian project from the DFSG and turned them into the founding text for the Open Source Initiative.

Taking into account the very legal character of this document and its strong similarity to the GPL (General Public License), well-known by free software fans [8], we will limit ourselves to listing the statements. The Debian Free Software Guidelines are made up of nine points: 1. Free redistribution; 2. Source code; 3. Derived works; 4. Integrity of the author’s source code; 5. No discrimination against persons or groups; 6. No discrimination against fields of endeavour; 7. Distribution of licence; 8. Licence must not be specific to Debian; 9. Licence must not contaminate other software. At the end of the document, the “GNU-GPL” (GNU General Public License), “BSD” and “Artistic” licenses are cited as examples considered free by Debian, in that they respect the nine guidelines listed above.

B. On the vitality of the founding documents

One should note that these texts are not fossilised documents that remain dead letters or simple declarations of intent with a purely “propagandist” character. On the contrary, these texts, truly at the core of the Debian project, are remarkably alive. They can be considered as true actors with whom the Debianists regularly interact.

First of all, they are mentioned in the very first lines of the Debian website homepage. There is a clear will to explain the principles underlying the project to people visiting the website.

Next, a field survey has revealed that these founding texts are often evoked (invoked?) by the Debian project members, whether they are active members or simply sympathetic users. For instance, these texts are often referred to within discussion lists and forums. Even more, the texts are also well-known outside the Debian project boundaries. In general, they are true proof of the singularity of the Debian project and can therefore be considered “identity markers”. Indeed, when meeting various free software fans who didn’t use the Debian system nor had any specific affection towards the project, I noticed that most of them referred to the Social Contract when asked about their opinions on the Debian project.

Finally, by defining a series of principles about “software freedom”, these texts are a continuous source of debate, sometimes controversy, and provoke a permanent process of reflection about the objectives of the Debian project. This feature is very obvious in the Debian discussion lists dedicated to legal issues (debian-legal). Many users use these lists to ask questions about the free characteristics of this or that licence, to ask which type of licence should be used for which type of creation (software, documentation …) etc. The answers provided daily by subscribers are held against the Debian Free Software Guidelines, which remain the point of reference in this domain. Strangely enough, the vast majority of participants in these legal discussion lists are not legal specialists, even though the questions asked are often quite complex. They often require a delicate interpretation of the terms and conditions of the licenses. Added to that are the problems of private international law, with national legislation concerning intellectual property sometimes being totally different. We notice, however, that some participants in the discussions are very adept with legal terms and have no trouble handling certain concepts; they manage to flawlessly put together the rules regarding intellectual property and the Debian Free Software Guidelines.

When project participants refer to the founding texts, it is not only typical of certain specific or even general discussion lists. These texts can also be evoked and lead to real debates when certain crucial events occur in the project lifecycle, such as campaigns for the election of new Project Leaders, selection procedures for aspiring developers, or more occasionally, the announcement of a partnership with a private company [9].

Moreover, these texts, that are at the centre of the political life of the project, are not set in stone. They can be subject to political debate, and can be revised by strictly defined rules. For instance, in January 2004 a proposal to change the Social Contract with the aim of deleting the non-free section of the distribution was put to a vote among the Debian developers.

Generally, the rules and principles in these founding texts have a descriptive value. In that case, their aim is to make explicit the philosophy and “free spirit” of the Debian project. On the other hand, these founding texts also have a prescriptive value. Their purpose is to set a series of standards to act as guidelines for the Debian project members, and thus to preserve a certain stability for the organisation [10]. This search for stability is most obvious in the procedure for the initiation and selection of candidate developers; knowledge and mastery of the founding documents is a crucial step in this procedure.

C. Initiation and selection of candidate developers

In general, within the free software movement, the recruitment of new developers is based on “cooptation and their existing contribution to the product” [11]. In the case of the Debian project, even though these principles remain true, it seems that they have been formalised in specific tests, with a mix of technical and ideological aspects. The selection procedure for “new Debian maintainers” is known for its strictness and length [12].

Here’s what the Debian website has to say on this subject:

The Debian Project is an open community and welcomes everyone who wants to use our distribution or even tries to help us. Nevertheless, appointing new developers is controlled by a very strict and thorough process: Every official Debian developer is associated with Debian, is allowed to vote about issues regarding the whole project, can log in on most systems that keep Debian running and has upload permissions for all packages. Giving this kind of access is accompanied by a great deal of trust, as we heavily depend on our secure infrastructure.

This is not meant to discourage people interested in becoming a registered developer, but it is meant to explain why we want people to contribute before applying and why the New Maintainer checks take so much time. [13]

In principle, the candidate has to be able to fulfil his future role as a maintainer. To do this, it is important that he or she is familiar with the Debian distribution; this means the candidate has to have previous experience with packaging and the maintenance of packages, or that he or she has made contributions by writing documents, making translations, sending corrections. It is therefore recommended that candidates find a sponsor to help them acquire this experience. The sponsor is then supposed to act as a mentor for the candidate. After having acquired a certain amount of experience under the guidance of a sponsor, the future developer officially submits his application. What follows is a series of tests under the authority of an application manager. He will assess the candidate and gather the necessary information to write a report that will eventually be delivered to the Debian applicant manager, who has the final right to decide about the acceptance of the application.

The skill tests are divided into two categories. On the one hand they focus on the knowledge of the philosophy and the rules and procedures, on the other hand, on the purely technical skills of the candidates. For instance, in a post in the debian-women discussion list, a candidate gives her impressions and explains what this first assessment phase, the so-called P&P or Philosophy and Policy, consists of. First, her applicant manager sent her a series of 30 questions which took a couple of nights to answer:

My P&P questions started with the necessary stuff about understanding the Debian Social Contract and the DFSG (Debian Free Software Guidelines). Then they moved on to some fairly difficult questions about licensing issues. Then there were a long string of questions about details of the normal Debian practises for things like handling bug reports, maintainer uploads, internationalisation of packages, and so on.

A few weeks after submitting her answers, her manager sent her a list of detailed remarks and asked for more specifications about some questions she answered incorrectly or with insufficient detail, until she passed the assessment.

Without a doubt this high degree of formalisation guarantees that a whole set of technical values and competences are shared by all members of the Debian project. This way, it contributes to the optimum preservation of the group identity [14]. This is particularly important when considering the assessment of the knowledge of the history and philosophy of the Debian project. This aspect is stressed in the short explanation on the website about this step in the selection procedure: “it is important to the stability of such a large and amorphous project that all participants work within the same set of basic principles and beliefs [15]. Note that this is one of the aspects differentiating Debian from other well-known projects such as Ubuntu, in which no such formal selection procedures have been set up.

IV. From information technology to policy: participation and commitment within the community

A. Tensions within the Debian project

In this last part, I would like to give a concrete example, based on an event during the field survey, of the complex intricacy between code and text, between IT programming work and the use of various textual resources (Social Contract, discussion lists, etc.). In particular, this brief case study will show how the proper technical evolution of the project contributes to a set of “textual practices” mobilising the political values of the project and how the Debianists use them, in different ways, to build up their sense of participation and commitment.

The way Debianists identify themselves with the political values of the Debian project remains particularly hard to understand, both because of the variety of reasons for participating in the project and because of the highly specific project policies within the free movement.

The specific characteristics are mostly written in the Debian Social Contract. Without going back to the detailed contents of this founding text, it is worth recalling some of its aspects. The main characteristic is that it is divided into two parts mirroring each other: the first one is about the project’s commitment towards the “free software community”, the second one is about the Debian Free Software Guidelines (DFSG). One could say this division in a sense confirms the distinction between “final values” and “instrumental values”, the former describing the goals aspired to, the latter being the means to reach those goals [16]. Indeed, the DFSG, which could be considered a more sophisticated form of the four freedoms granted by the GNU-GPL license, appear as the necessary conditions for Debian’s commitment towards the community. In other words, these technical liberties, supported by the opening of the code, allow for the pursuit of the “end values” such as mutual help, sharing of knowledge, technical quality, transparency and user satisfaction.

It is precisely this last aspect – the user – that is crucial to understand the specific policies of the Debian project within the free software movement. Indeed, “freedom”, according to Debian, takes the shape of tolerance for non-free work so that users who wish to do so can use this type of software. More specifically, in the Social Contract, Debian pledges to provide them with non-free packages – i.e. noncompliant with the DFSG – specifically configured so as to be compatible with the whole distribution. As outlined before, these non-free packages are grouped in a specific section labelled non-free.

This tolerance for the proprietary model has earned the project the status of leader of the “pragmatic” movement, which is supposedly radically opposed to the “ethical” movement of the Free Software Foundation (FSF). This black and white vision, however, does not accurately reflect the internal tensions within the Debian project, taking place behind the shiny façade of the Social Contract. Indeed, the status of this non-free section is a repeated source of controversy, which has ranged from heated debate in the discussion lists to concrete proposals for changes to the Social Contract. A quick glance at the project archives reveals the occurrence of significant controversy within the project during the past years: in 2000 through a proposal for a general resolution submitted by certain developers, which however did not lead to a vote, in 2003 after the apparition of a new GNU licence dedicated to documentation [17], in 2004 with a general proposal to modify the Social Contract followed by a vote by the developers, and in 2006, after the announced collaboration between Sun Microsystems Inc. and Debian.

B. Collaboration as a “total social event”

During the field survey, the announcement of a collaboration between Sun Microsystems Inc. and Debian re-ignited the debate about the non-free section of the Debian distribution.

More specifically, this collaboration entailed the addition of Sun’s Java package to the [18] section of the Debian project, enabling execution environments for Java (such as Kaffe and GCJ). To this end, Sun has worked together with the Debian and Ubuntu developers to prepare packages – Sun’s Java Development Kit (JDK) and Java Runtime Environment (JRE) – meant to be stored in the non-free repository of the unstable branch of Debian. On the other hand, Sun slightly altered its licence so as to allow for the inclusion of Java in the non-free directories.

When this happened, the debian-legal discussion list, to which I had been subscribed since the beginning of my field survey and which, until then, had been characterised by a peaceful routine of legal questions concerning free software, started buzzing: my mailbox was overflowing with ever more raging, not to say flaming messages – actually my e-mail client had to flag several messages containing offensive language. Even though the impact of this event on the Debian project is hard to measure, several pieces of empirical data, collected in the debian-legal discussion list, allow us to grasp its importance, even if only partially.

By observing the stream of messages in this list, one could notice phenomena that had never before been witnessed. For instance, there was a great deal of aggression in the messages, which had previously always been characterised by their polite tone. Since participation in these lists is subject to the use of an e-mail client, the “offensive” messages were usually flagged with striking pictograms, for instance hot peppers. Never before did my e-mail client have to use that many warnings.

Another notable occurrence, hitherto unseen, was the widespread diffraction of the themes discussed after just one message. Usually a message in these lists starts a single thread of comments, based around a certain idea or question in the original message. Discussion threads usually don’t last more than 3 or 4 days. But after the message announcing the collaboration with Sun (Sun Java available from non-free), the discussion gradually split up in a whole series of other threads, at first closely sticking to the original theme, for instance discussing the clarification of Sun’s intentions (Sun responds to questions on the DLJ and Sun clarifies intent of the DLJ). However, the messages kept on moving further and further away from the original issue and became more touchy, discussing topics such as the political organisation of the project itself or the status of the contributors (Non DD’s in debian legal) and the power of the developers to contractually commit the community (Who can make binding agreements?). Finally, during this period of controversy between the 17th of May and the 20th of June 2006 (more than one month), the pace of discussion in the debian-legal list was particularly high, with the number of messages per hour reaching one of the highest peaks since the beginning of the year.

Without going into too much detail about the points of discord between the members involved in these discussions, a number of elements need to be explained so as to properly understand what was at stake in this debate. At the start of the polemic, the main problem raised by some of the regular members in this discussion list concerned the type of licence pertaining to the Sun Java packages; one particular clause in this licence, though slightly modified in view of the collaboration with Debian, could potentially be harmful to the project as it stipulated the payment of compensation in a certain situation that is not unusual when software is distributed. And so a simple clause unleashed a mass of messages that, rather than focusing on the “legal” aspect, focused on the “political” aspect of the Debian project.

The Sun collaboration shed light on the internal tensions in the Debian project that go back to the founding text. In a more general way, these tensions also reveal the difficulties of the juxtaposition of the free movement and the market. Of the numerous arguments brought forward during this controversy, only a few will be explored below; however, the issue gave a clear insight into the weight given to the concept of “freedom” within Debian. Here is a series of messages that give a good idea of the tension between project members. The first poster condemns, quite explicitly, the presence of a non-free section in the distribution. The second one, true to the Social Contract, insists on the specific needs of certain users:

> I’m afraid I have more interesting things to do than helping non-free software
> developers to get their non-free crap in the non-free archive.
> I don’t feel like I have to justify myself, and I also think my work at Debconf has been
> more productive and more of a right example than that of people interested in Sun-
> related PRs (public relations).
Good, but you shouldn’t decide what others have to do. Some people are interested in java in non-free, it’s not your job to try to forbid them to work on that.

For some, the collaboration with Sun was nothing short of a pact with the devil, causing Debian to lose its soul. On the other hand, some people mention the interest of working with a corporation, while pointing out their appraisal for the socio-cultural dimension of a project such as Debian.

> The essence of Debian should be free software and technical excellence.
> I am afraid this is no more a priority for many of us.
I don’t see the contradiction here. For me, Debian is about free software and technical excellence. But it would be *really* boring to do the work alone. And it would also be much
less interesting to do the work in a company with traditional organization. Therefore, the fact that Debian is a social entity , too, with a particular culture , contributes to my motivation
to work for it.

The interest in allowing a collaboration with Sun or other corporations seems to be, for some, a case of “moderate proselytising” aimed at exposing, through joint efforts, arguments in favour of free software, while feeding the hope that one day the litigious software will be totally free.


(1) Let me first preface this with a caveat and an apology: after the fact it was pointed out
that the mail I sent was needlesly inflamatory; that was not my intention and for that I apologize. I also appreciate the desire of Sun to work with Debian in order to create a license that distributions can distribute; I hope that they continue down this path and eventually end up at a license for Sun Java that is trivially DFSG Free . (…)
I personally don’t buy the non-free is Debian too argument, but then again, I’m one of the
people for whome non-free basically doesn’t exist .333

(2) The license is good enough for Debian (ftpmasters took their decisions). There’s no fix to require, but it would be good to continue working them to enhance even more the license. Such a constructive behaviour would put us in a good position to make sure that Sun releases java in a DFSG-free compliant license when they will open-source it.

(3) I would furthermore strongly encourage people to work *with* Sun towards improving
> the current license and developing sufficient confidence in the Debian and free software
> community to release Java under an entirely free license . The end goal isn’t to turn this
> into a PR stunt to make sure Debian’s viewed the right way, it’s both to help our users get
> software they need, free or not, and to encourage more people to make their software
free.334

The social contract should not be used as an excuse to take unwise legal risks. Nor should
it be used as an excuse to bypass proper channels for approving legal contracts.

In general, many messages in the discussion lists, often between the lines, point out the fear that the project will “sell out” to the market, echoing the well-known commercial strategies of certain corporations. As J.-S. Beuscart points out, “this way firms hope to benefit from the productivity of a community of user-developers (in accordance with Raymond’s model) that allows for an improved quality of their central product while at the same time gaining income from the auxiliary functions and utilities, which remain proprietary, and from any services offered” [19]. These fears reveal the dilemma between “purism” and “compromise for expansion” that currently exists within the Debian project. Moreover the words of some Sun developers, who without doubt have good intentions, have been wrongly interpreted by Debianists who saw them as an attempt to pacify them:


Sun Developer:

I enjoyed meeting you and many other Debian Developers. Perhaps the biggest thing for me to grok was that Debian isn’t as much a "technical organization" as a "social organization" that happens to produce very interesting technical works.
Sun needs to understand the role of "nonmarket" forces because: To be able to understand
these choices, to be able to make them well, we must recognize that they are part of what
is fundamentally a social and political choice - a choice about how to be free, equal, productive human beings under a new set of technological and economic conditions.

Debianists:

(1) >Debian would become (viewed as, at least, as) one more project to not take care about
> what "Free Software" is , despite the strong emphasis issued in most public statements...
Neither Sun nor Debian have at any point said that Sun Java is free software - it’s been uploaded to non-free for precisely that reason. If anyone does think that, it’s pretty easy to
clarify for them - Debian’s stance is that free software is important, but that doesn’t mean
that we can ignore non-free software that our users want 336.

(2) I am also troubled about the potentially murky legal water in which we are now, with a potentially unauthorized agreement with Sun and thus potentially unauthorized downloads
in non-free. And I know you would like me to just go away and shut up about this, but this project is too important, and this action has too many unknowns at this stage, to just put blind faith in Sun’s lawyers doing the right thing for Debian337. I am greatly troubled by the
lack of foresight and communication with which this situation has been handled. It feels very much that the interests of Sun have been placed ahead of those of Debian.

(3) This all really smells strong and after reading the license carefully and talked with several other people I came to the conclusion that I have to do anything that I can to get this out of debian again. This is not the freedom I’m standing for . And after all that’ s not
the way I wanted a project I’m working in to act, I see this way of acting as a personal affront to me and my Debian work... This really went wrong and I want to have some good
explanations or we will have to bear the consequences338.

These brief excerpts of the discussion show just how much the presence of a non-free section in the Debian distribution is a sensitive issue. It is so sensitive that the collaboration with Sun was rushed through in a hurry. In fact, by not consulting the “experts” in the debian-legal discussion list, and to a wider extent the project members, it has led to a great number of disputes about the organisation of the “community” itself; some complained about the inadequate recognition of non-developers specialised in legal matters, others questioned the Project Leader’s commitment towards the whole community.

Despite these various controversies, reflecting both political and organisational tensions within the Debian project, fact is that the clause about the non-free section has still not been removed from the Social Contract. Also, despite all this, the Debian project has not collapsed following mass desertion by discontented developers and users.

This confirms that there are a multitude of reasons for people to adhere to and participate in this project. Participation can have various justifications and be the source of various satisfactions. Most of the participants we spoke to during this survey express, in varying degrees, a feeling of belonging to the “Debian” community. Moreover, by keeping the non-free section throughout the years, it is clear that it is one of the core values of the project, giving it a strong political identity within the free movement.

Conclusion

This strongly marked identity owes a lot to the crucial role of the founding documents and other related textual resources. These documents feed a certain number of critical discussions and negotiations, forcing the participants to give a lot of thought to the movement and, more specifically, to the reasons for their commitment and the project values they adhere to.

In this regard, is it important to point out that these documents and the formal organisational rules they contain have no binding power in the legal sense of the word. Therefore, they do not possess the character of exteriority that the law has. We cannot identify any form of heteronomy aiming to make a certain behaviour or task compulsory.

So the organisation and regulation strived for through various textual resources do not originate from binding legal rules but rather from what we could call the institution [20]. It is typically a “positive model of action” stimulating initiative and aimed at the inventive capacity of the actors, as opposed to the law, which rather acts as a limitation of the action. This, it seems, is the point of view we should use when analysing the scope of the various regulating documents discussed in this text: the “text code” institutes and relays the opening of the “source code”, confirming inventiveness and freedom, way beyond the purely technical aspects.

Christophe Lazaro [21]

[1Ch. Lazaro, La liberté logicielle. Une ethnographie des pratiques d’échange et de coopération au sein de la communauté Debian, Anthropologie Prospective n° 2, Academia-Bruylant, Louvain-la-Neuve, 2008.

[2S. Dusollier, “Open source et copyleft : une remise en cause de la figure de l’auteur”, Revue Nouvelle, Dossier “Pour les logiciels libres”, V. Guffens & M. Hilgers (under dir. of), June-July 2005, n° 6-7, p. 4.

[3”Ph. Laurent, Logiciels libres : le droit d’auteur contre le droit d’auteur, Thesis submitted for the degree of Master in intellectual rights, Katholieke Universiteit Brussel (KUB), under the direction of A. Strowel, year 2002-2003, p. 52. Of course, evoking this association between software/copyleft is not enough to explain why the free movement, characterised by sharing, giving, cooperating, is so original. Indeed, copylefted licences don’t oblige anyone to put a derived work at the disposal of others; only when a developer distributes software based on previous work, will the copyleft produce its effects.

[4B. Latour, L’espoir de Pandore. Pour une version réaliste de l’activité scientifique, translated from English by D. Gille, La Découverte/Poche, Paris, 2007.

[5Without going into specific legal details, a licence can be considered as a contract specifying a certain number of rights and obligations between the licenser and the licensee. As a consequence, all exploitation of software that is not compliant with the terms and conditions of the licence, should be considered both as contract infringement and piracy.

[6N. Auray even qualifies them as the “collective property” of the project; see “La régulation de la connaissance : arbitrage sur la taille et gestion aux frontières de la communauté Debian”, Revue d’économie politique, special issue “Communautés d’agents et marchés en ligne”, n° 113, 2004, pp. 160-182.

[7B. Conein & S. Delsalle, “Le logiciel libre comme communauté de connaissance : normes épistémiques et normes sociales”, in S. Proulx, F. Massit-Folléa et B. Conein (under dir. of), Internet, une utopie limitée. Nouvelles régulations, nouvelles solidarités, Les Presses de l’Université de Laval, Québec, 2005, p. 45.

[8As a reminder, I should point out that the expression “free software” refers to the freedom users have to run, copy, distribute, study, change and improve the software. More specifically, it refers to four types of freedom for the software user: 1. the freedom to run the programme, for any purpose (freedom 0); 2. The freedom to study how the programme works, and change it to make it do what you wish (freedom 1). Access to the source code is a precondition for this; 3. the freedom to redistribute copies so you can help your neighbour (freedom 2); 4. the freedom to distribute copies of your modified versions to others, giving the whole community a chance to benefit from your changes (freedom 3). Access to the source code is a precondition for this.

[9See below, the comments about the collaboration between Debian and Sun Microsystems and the problems with the non-free section of the Debian archive.

[10Note that the term “value” was used on purpose here. I admit the possibility of a varying degree of intensity of the norm, and at the same time recognise the scope of this norm varies depending on the reader of the document in question: developers, contributors or sympathising users.

[11D. Demazière, F. Horn & N. Jullien, “Le travail des développeurs de logiciels libres. La mobilisation dans des ‘communautés distantes’”, Records of the CLERSE event “La représentation économique de l’acteur au travail”, Villeneuve d’Ascq, 20-21 November 2003, p. 17, available online at http://www.marsouin.org/IMG/pdf/DD-FH-NJ_S4C3_norm.pdf.

[12On average, the procedure to become a Debian developer takes 477 days. Sometimes it can take up to 691 days, or nearly 2 years. These statistics are published on the Debian website: https://nm.debian.org/.

[14D. Demazière, F. Horn & N. Jullien, op. cit., pp. 16-17.

[16R. Rezsohazy, Sociologie des valeurs, Armand Colin, Paris, 2006, p. 5.

[17The licence referred to is the GNU Free Documentation License (GFDL); it is meant to regulate the status of documentations pertaining to free software. This licence led to a major conflict between the FSF and Debian, a conflict that even spread within the Debian project itself. The basis of the conflict was relatively simple: the GNU FDL license was not compliant with the Debian Free Software Guidelines, not only in terms of commodity but also for ideological reasons.

[18non-free

[19J.-S. Beuscart, “Les communautés du logiciel libre face au marché et à l’action publique”, Melissa – Mettre en ligne les sciences sociales aujourd’hui, September 2002, p. 8, available online at http://www.melissa.ens-cachan.fr/article.php3?id_article=91.

[20N. Auray, “Le sens du juste dans un noyau d’experts : Debian et le puritanisme civique”, in S. Proulx, F. Massit-Folléa et B. Conein. (under dir. of), Internet, une utopie limitée. Nouvelles régulations, nouvelles solidarités, Les Presses de l’Université de Laval, Québec, 2005, p. 78.

[21PhD student at the European University Institute, Florence (Italy); scientific research worker at the Centre de Recherches Informatique et Droit, Facultés Universitaires Notre-Dame de la Paix, Namur (Belgium); associated researcher at the Laboratoire d’Anthropologie Prospective, Université Catholique de Louvain, Louvain-la-Neuve (Belgium).

[Close]
Welcome to Constant Verlag

Constant Verlag is a repository of texts from the depth of the Constant Archives. Some of those texts were already available on line, others just saved on one of our harddrives; some written in French, others in English or Dutch; recent or as early as 1997. As most texts have been published under open content licenses, you are invited to use, copy, modify and redistribute the material.

More about Constant Verlag
More about Constant