Free and Open Source Software: Difference between revisions

From The Internet: Issues at the Frontier (course wiki)
Jump to navigation Jump to search
m (→‎Materials: formatting)
Line 149: Line 149:
== Law is Code: Open Source Law ==
== Law is Code: Open Source Law ==


Learning from the lesson of FOSS, we have started contemplating about what could law learn from FOSS. It seemed, that since law is a big pile of text, we might be able to design a system to create 'free source law' and thus promote the values and principals we spotted in the discussion of FOSS, such as affiliation, community and solidarity.
Learning from the lessons of FOSS, we began speculating about what principles of open source could be applied to the legal world. Statutory law is, in some sense, a pile of text. Common law, too, may be said to be a textual creation insofar as it's incorporated in a body of written opinions. Moreover, it seems that there must be some ideological nexus between FOSS and the law. Both make use of, or purport to make use of, extensive transparency. They each implicate public participation. They also can both be ''buggy''; when written poorly they create unintended consequences which may be exploited by bad faith actors.


An obvious bridge was Wikipedia, that uses FOSS mechanisms and applies it to text, and not to software. The opennes of the wiki-software allows anybody to edit any page, thus creating a collaborative project, whose success is extraordinary. We would present several ways in which the lessons of FOSS could possibly be implemented to the legal practice, and will discuss the pros and cons of each method.
An obvious starting point for speculation is [http://www.wikipedia.org Wikipedia], which uses FOSS-like mechanisms applied to text, not to code. The openness of the wiki software allows all interested parties to contribute to the work, and the collaborative result is extraordinary. We would have hoped to discuss in detail several ways in which the lessons of FOSS could possibly be implemented in the legal world, and the pros and cons of each, however these speculative threads were hard to follow in our implementation of the curriculum. Nevertheless, some ideas follow...


=== Ideals and Problems ===
=== Ideals and Problems ===

Revision as of 12:54, 23 April 2009

Law is Code?

By: Ayelet, dulles

Introduction

Precis

Fundamental Question: What can we learn from the world of free and open source software (FOSS) that might translate into the legal world? That is, what are the characteristics of FOSS that make it work so well, and can we learn lessons from FOSS that will help us improve the law?

The class first examines FOSS and attempts to discern the qualities, both procedural and substantive, that make it unique, successful, or unsuccessful. We then look for examples of projects that rely on these characteristics to make themselves more participatory. From there, we conjecture on what the world of "open source law" might look like and the associated problems.

Materials

Required Reading

Required Meddling

  • Everybody should come to class having spent a bit of time on OpenLaw and MySociety

Optional Reading

Guest

Benjamin Mako Hill will be joining us. Mako is technology and IP researcher and activist, and a PhD candidate at the MIT Sloan School of Management. He is a member of the FSF board of directors and serves on the Ubuntu Community Council. His experience with FOSS projects, especially Debian and Ubuntu, will be invaluable in helping us understand FOSS.

We adressed Mako to be our guest in order to hear his own views as an insider of FOSS creation. Having an insider allowed us to break down many of the common conceptions held by the FOSS literature. For example, a large part of the studies conducted regarding FOSS focused on the motivations of contributors to these projects. Mako's input on this literature called to do away with motivations - which are always mixed and combined, and different from one contributor to the other - and move to a study on the actual practices of contemporary FOSS projects.

Discussion

Introducing Free and Open Source Software

Free software, in this course, means software libre. That is, there exists software that costs no money ("software gratis"), but there also exists software that has no restrictions ("software libre"). This software is defined by the four freedoms of software, as written by the Free Software Foundation:

  • The freedom to run the program, for any purpose (freedom 0).
  • The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this.
  • The freedom to redistribute copies so you can help your neighbor (freedom 2).
  • The freedom to improve the program, and release your improvements (and modified versions in general) to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this.

Many people are familiar with the big names in the free software world: Linux, Firefox, OpenOffice, and some of us are likely familiar with the SourceForge system. These projects have several characteristics in common:

  • Public access to code
  • Public authority to alter the code
  • Public right to distribute the code, modified or not
  • Strong communities around the software

Free and Open Source software dominates many areas of the technology landscape. The Apache webserver, for example, holds a commanding 66% share of the webserver market. Open source web browsers also account for an incredible chunk of the browser market. At first blush, the existence of FOSS seems perplexing. People regularly pay money for software, why would a group of hackers donate so much time to writing software for free? Moreover, should it perplex us that free software competes so well against commercial software?

In thinking about free software, it is interesting to note that it is not necessarily a new development. Until the 1970s, it was typical for software to be distributed for free, along with its code. This began to change in the late 1970s and 80s when software companies began to distribute binary only code and apply copyright to software. Richard Stallman's GNU project was a reaction to increasing application of property ideas to software, although it never quite succeeded until it was combined with the Linux OS kernel.

In order to secure the above mentioned freedoms in a world which increasingly allowed application of property ideas to software, it became necessary to create copyright licenses designed to abrogate the usual rules and empower free software advocates to maintain a sort of commons. Popular licenses include the GNU Public Licens or "GPL", the "Lesser GPL", the BSD license, the Apache license. There are many, many, more.

Motivations to contributions to FOSS

We discerned three separate ways to think about the motivations that underlie FOSS. Gift economics, traditional economics, and cultural analysis provided us with distinct insights into the world of FOSS. Importantly, we believe that these analyses do not conflict with each other, but rather they observe the same phenomenon from different points of view and, largely, do not conflict with one another.

Gift economies

In The Gift, Hyde identifies a gift economy as one that demonstrates particular qualities in the exchange of value. Notably, that wealth exists in the giving of the gift, rather than in the trade or possession of the gift, which cannot become personal property. Essential to the theory of gift economics, "the gift must always move". Hyde considers the academic community as a gift economy. That is, the academic's research, while in a sense her own discovery or creation, does not belong to her personally. In publishing, referencing, and building upon the research of others in the community, the academic develops an intellectual commons, and each act of research and publication is a gift that adds to the commons.

Similarly, FOSS can be understood as a gift community. Similar to the intellectual commons of the academic institution, the open source code repository is an intellectual commons because it represents the common intellectual work of the developers. More precisely, it is the intellectual product of the FOSS developers.

This analogy suggests that truth seeking is a key concept in understanding the motivations in FOSS. That is, we understand the academic to be in pursuit of the truth of their field, so we might understand the FOSS developer as also seeking a kind of truth. The "truth", in FOSS, may be a program of the highest quality and utility. That is, well structured, organized, largely bug-free, intuitive, useful, and portable. Each contribution to the code base is akin to a publication by the researched, whose contribution to the commons marks progress towards the ultimate goal.

The analogy also suggests that reputation is valued in the FOSS community in much the same way that it may be valued by academics.

Traditional market economies

Lerner's paper elucidates the nexus between reputation and traditional market economics. He identifies reputation as a capitalist incentive. The developer who makes a name for herself in the FOSS world has all the better a resume to apply towards finding gainful employment as a developer. He also identifies the utility of the alumni effect, saying that developers who all become familiar with a common code base (e.g., glibc, the GNU C Library) have a competitive advantage in later programming tasks. Furthermore, as more companies rely on the same common tools, such as a Linux OS underneath their custom product, they find that dedicating some of their staff's time towards improving Linux is in their best interest. Fortunately for Linux users everywhere, the architects behind the GPL License have ensured that everybody can benefit from a sort of enforced cooperative attitude.

Lerner also identifies other characteristics that are notable in FOSS. Firstly, modularity is valued. That is, it must be possible for developers to work on different parts of the code base without inadvertently interfering with each other. Interesting new problems are also valued by developers, consisting with the reputation enhancement incentive. Essential to this, credit for authorship is valued. Lastly, Lerner identifies a skew pattern: a small number of people contribute the bulk of the code. This can be understood as an expression of the 80-20 principle.

Cultural motivations and the radical project of FOSS

The third reading takes on the realm of cultural motivations. In his book, Two Bits: The Cultural Significance of Free Software, Chris Kelty places the FOSS movement against the background of Geek Culture. To explain what 'geek culture' is, it might be better to quote from our guest's essay, The Geek Shall Inherit the Earth: My Story of Unlearning:

If I were asked to define and confine myself using only one term, I wouldn't hesitate long before I chose the word "geek." [...] For decades, young Americans on the fringes of youth culture were denounced and condemned as "geeks." Over time, the term served as common ground for these outcasts; it came to define a group of nerds who fit in together by not fitting in with anyone else.

The Jargon File, a lexicon of technology-related terminology created by the first generation of Internet pioneers, technophiles, and hackers defines "geek" in a way that begins to describe my relationship to the label: "A person who has chosen concentration rather than conformity; one who pursues skill (especially technical skill) and imagination, not mainstream social acceptance. Geeks usually have a strong case of neophilia. Most geeks are adept with computers...These are people who did not go to their high school proms, and many would be offended by the suggestion that they should have even wanted to."

The Jargon File shows how "geek" evolved from an insult into a term of endearment used by these "losers" and "nerds." Over time, this common ground provided the setting for the creation of a new culture. With each year, geek culture becomes more visible, more defined, and more influential. Geek culture was formed in critical opposition to mainstream social culture and is defined through rapidly expanding and evolving technologies. Today's geeks are no longer forced onto the fringe of mainstream culture but have developed a critical perspective and stay on the fringe by choice. A self-actualized geek culture is, by definition, an act of critique and protest. Geek culture has grown into a deep-rooted critical mentality and willingness to challenge, confront, and build alternatives to deep-rooted social, educational, political and economic institutions. Also important to geek culture is an obsession with skill, creativity, and an infatuation with new technology. In this way, geek culture couples a critical nature with the tools and the mentality needed to execute real change. Geek culture is complex. It is enigmatic. It is powerful.

Kelty both describes geeks as people who find affinity with one another because they share an abiding moral imagination of the Internet. Geeks’ principal mode of associating and acting is through the medium of the Internet. The heterogeneous infrastructure of the Internet constitutes and constrains geeks’ everyday practical commitments. The Internet is at the core of their own reasoning about why they associate with each other. "They are the builders and imaginers of this space, and the space is what allows them to build and imagine it." (p. 29). Kelty refers to the Geek public as a 'recursive public', since it includes the activities of making, maintaining, and modifying a series of technical and legal layers from applications to protocols to the physical infrastructures of waves and wires. "they argue about technology, but they also argue through it. They express ideas, but they also express infrastructures through which ideas can be expressed (and circulated) in new ways." (p. 29).

Kelty's ideas suggest a radical new kind of discourse that emerged in FOSS communities, one which can oppose established sources of power and authority. This would explain why FOSS became connected to radical thought. This radical twist of FOSS is also apparent in the personal story of Mako, which describes FOSS as an ideological project:

In the second semester of my first year, another experience changed my life. The experience came in the form of a class titled "Cyberlaw" and taught by a fellow at the Berkman Center for Internet and Society at Harvard Law School. One of the major topics of the class was GNU/Linux, free software, and free software licensing. It was not the class, nor was it the material covered that affected me. It was the fact that once a week, I was immersed in books, essays, articles, and stories by and about technology-driven social change advocates, activists, and zealots living their life doing exactly what I loved. Before this point, I had only considered free software and my involvement with free software advocacy and development as a tool I might use to accomplish other goals and activities. Before this point I saw myself as writer, a programmer, or a computer scientist. At this point, I was exposed to people who were, first and foremost, activists, idealists, and advocates of a system that I understood. After this point, I allowed myself to be seen--by others and by myself--as an activist and a radical, first and foremost--on my terms and in a way that I felt completely comfortable with.

Multiplicity

In our class, it seems that we have reached the conclusions that motivations to the contributions to FOSS vary among people. Moreover, even the same person might be affected by different motivations. An example was apperant from the different motivations shared by the class members on the class twitter discussion:

  • "I did it for fun (and for the challenge)" vranieri
  • "people get paid to make free software, and use it as a way to build portfolios for jobapps too". mchua
  • "starving artists," poets, etc work just for passion, i guess, which we've never really puzzled over. why not the same for programmers" shubhamm
  • "I was a purely function-oriented open source code modifier, and I think many others are as well: they simply want a piece of software to do something new which serves their needs, and to take advantage of peer review" mithridatic
  • "I was told in (engineering) college to license my class projects as free software for portfolio goodness, but Olin is weird." mchua
  • "worked on open source software at an academic institution without really thinking why. It seemed like the right default state." megerman

Notes on Successful Projects

Process Characteristics

Through our discussion of open source projects, we were able to note that there are characteristics which appear to exist in several projects, and which may be correlated with the project's success and/or viability. Chief among examples of projects with highly developed processes and process values is the Debian GNU/Linux project.

From the reading and discussion, we noted that the processes are highly defined, almost in an algorithmic style. This raises the interesting note that a successful open source law creation project may also require highly defined processes, and also that the open source community has no adversarial adjudication.

We also noted that the processes seem to reveal focus on enabling progress, not coercing process. That is, disputes of jurisdiction and authority are not necessarily called into question when the end goals are agreed upon, and instead a developer might look the other way since progress is being made on a bug or issue. This also reveals at least one characteristic which may be totally inapplicable in an open source law-creation project: a substantial agreement on end results. This implicates a strong belief in the value of group cohesion. After all, projects are loathe to fork when they can avoid it.

We noted that the processes are minimal and reactive. An agency, process, or body can often be directly associated with a particular failure event whose solution appeared to be the creation of that agency or process.

Lastly, we noted that the very idea of open source software embodies a certain democratic ideal. A software version repository, a bug-tracking system, a thousand eyes to make all bugs shallow, all imply general openness to public participation.

Substance Characteristics

Perhaps the most important substance characteristic we identified is modularity. We saw, for example, that when Netscape first went open-source there was a dearth of development. Would-be developers were said to be unable to contribute to the project because of its poor structural modularity. The Linux kernel, on the other hand, is highly modularized. As a result, developers can work on any number of sub-units without threatening the larger architecture of the system. This enables serious parallel processing in order to advance the project.

As to the purpose of the code itself, there seemed to be disagreement on market factors that determined whether a project would be successful. On the one hand, there seemed to be agreement that serious niche markets may be good for open source projects, especially where the market users may be geeks who can find each other online and collaborate. On the other hand, it was suggested that having a commercial behemoth to displace, such as Microsoft Windows, may create strong incentives for developers to apply their full skill to the task. We were unable to reach a further conclusion on this divergence.

The Real Law of Free Software: Licensing

An obvious nexus of FOSS and law relates to the ways in which formal law promotes FOSS projects and open collaborations or holds them back. Lawrence Lessig argues, in his book Remix: Making Art and Commerce Thrive in the Hybrid Economy that current copyright law opposes the practices of remixing (which could be portrayed as the artistic equivalent to FOSS), by prohibiting the transformation of proprietary materials. This limit forces FOSS projects to start from scratch, thus limiting their potential to influence existing proprietary software, leaving them as a still-marginal phenomenon.

It was argued that current legal norms does not support FOSS, since they are based on proprietary assumptions.

xxx

Why does FOSS need licensing?

Law is Code: Open Source Law

Learning from the lessons of FOSS, we began speculating about what principles of open source could be applied to the legal world. Statutory law is, in some sense, a pile of text. Common law, too, may be said to be a textual creation insofar as it's incorporated in a body of written opinions. Moreover, it seems that there must be some ideological nexus between FOSS and the law. Both make use of, or purport to make use of, extensive transparency. They each implicate public participation. They also can both be buggy; when written poorly they create unintended consequences which may be exploited by bad faith actors.

An obvious starting point for speculation is Wikipedia, which uses FOSS-like mechanisms applied to text, not to code. The openness of the wiki software allows all interested parties to contribute to the work, and the collaborative result is extraordinary. We would have hoped to discuss in detail several ways in which the lessons of FOSS could possibly be implemented in the legal world, and the pros and cons of each, however these speculative threads were hard to follow in our implementation of the curriculum. Nevertheless, some ideas follow...

Ideals and Problems

XXX work out this section with the below material ideals encapsulated:

  • inefficient or unjust law ≈ buggy code. eric s. raymond: with enough eyeballs, are bugs are shallow.
  • participatory democracy – but will people actually want to be engaged? zittrain: if there's participation, might adherance to the law increase?
  • efficiency by being flexible
  • experimentation (links to explimentary democracy)
  • deliberative democracy

problems:

  • 80/20: 80% of the law will be written by 20% of the people. is this bad? is it actually an improvement?
  • legitimacy - should participant collaboration be limited only to private law since it lacks democratic legitimacy as to public law;
  • formal training in legalese. after all, statutory construction can turn so wildly on pretty minor issues. otoh, much foss code is submitted full of bugs at first, so maybe it's just part of thee process
  • stability
  • protecting minority voices, the lack of mechanisms in Congres like filibusters that would otherwise help

Class tweets:

Examples of Free Software Principles Applied to the Law

Due to the inherent dillemas that emerge in the combination of FOSS meachanisms to law, as well as the normative benefits is holds, we presented three different ways in which FOSS could be used to create better law. While the first option seems to be pretty conservative, and uses FOSS mechanisms to a limited degree while leaving intact the basic authoratative structure of law, our other options, and especially the third one, suggest the possibility of a radical transformation of law following the challenges of FOSS.

The options are:

  • Increased participation
  • Collaboration in writing legal arguments
  • Collaboration in writing legal norm?

Using Web 2.0 to Increase Transperancy

One version of open law is structured not to give people direct participatory roles in writing the laws, but rather to increase transparency. Such projects are focused on allowing the citizens easy access to bills as they go through Congress, show who's money is involved, notice and comment method and allowing citizens to suggest ideas etc. There are several examples for this sort of work:

  • PublicResource.org : Carl Malamud project aims to make the case law and codes of the United States of America (state and federal) freely accessible in a public domain archive. (see more here
  • OpenCongress: OpenCongress is a project of the Sunlight Foundation and Participatory Politics Foundation. OpenCongress is aims to help user track particular bills, topics and congresspeople by RSS, a tracking page or an embeddable widget. In addition to helping citizens navigate legislative information, OpenCongress has a goal of making it “possible for the public to draw connections between lobbying activity, campaign contributions, and the actual substance of bills in Congress". The site incorporates campaign finance information from the Center for Responsive Politics.

Collaboration for writing legal documents

XXX write a paragraph

  • OpenLaw: The Openlaw project FOSS-like suite of tools to discuss cases, solicit evidence, and ultimately write some amicus briefs and comments.
  • Joel Fights Back: XXX add discription.

Collaboration in a FOSS model to create legal norms

XXX write a paragraph

  • Wikipedia's policies: Wikipedia has created a highly complex system of legal regulation using an open source method. Officially, there are forty-two policies (mainly governing behavior and content) and 356 specific guidelines (mainly governing style and formatting) which all users are expected to follow if they wish to contribute to the encyclopedia. Its arbitration committee, which generates norms and also inflicts punishments, hears cases using an adversarial method which includes submitting evidence.
  • Fantasy Congress:Fantasy Congress is an online fantasy simulation where "citizens" draft members of the United States House and Senate, and keep track of their participation within the U.S. Congress. Actions, especially within the process of making and amending pieces of legislation, of a player's drafted congresspersons are recorded and rated as a cumulative total amount of points against other players.

In Class Experiment

In class, we initiated an experiment of collaborative law editing. The experiment was intended to illustrate one possible, and quite literal, application of open development to law.

At the Etherpad website we have set up several copies of the bill of rights. We broke up into groups of roughly 8 people and, for ten minutes, co-edited the bill of rights. Each group edited its copy of the document simultaneously, through their individual interfaces.

The result of the exepriment was obvious indeed - most of the groups have ridiculed the bill of rights. (not unlike this Onion article.) 

Amendment 0

A robot may not injure a human being or, through inaction, allow a
human being to come to harm.

A robot must obey orders given to it by human beings, except where such
orders would conflict with the above.

A robot must protect its own existence as long as such protection does
not conflict with the above.

Amendment I

No law shall violate the right to the free practice and expression of
religion, speech, press, and expression. “No law” is here defined as
“absolutely no law,” rather than “some laws, so long they are not
really bad.”

Amendment II

A well regulated food fight, being necessary to the security of a lunch
room, the right of the people to keep and bear skittles, shall not be
infringed.

Amendment III

No soldier shall at any time be quartered on foreign soil, the military
existing only for self-defense.

Amendment IV

The right of the people to be secure in their persons, houses,
cheezeburgers, lolcats, papers, and effects, against unreasonable
searches and seizures of both their tangible property and information
ontained electronically therein, shall not be violated, and no warrants
shall issue, but upon probable cause, supported by oath or affirmation,
and particularly describing the place to be searched, and the persons
or things to be seized.

(Amendments V-VII weren’t really touched.)

Amendment VIII

Excessive bail shall not be required, nor excessive fines imposed, nor
cruel and unusual punishments (like death by execution) inflicted. No
torture, or any tortured definition of torture that John Yoo, David
Addington, or anyone within 6 degrees of separation of them can invent.
Except if it is needed to stop an imminent nuclear attack. Or if Jack
Bauer is involved.

Amendment IX

The enumeration in the Constitution, of certain rights, shall not be
construed to deny or disparage others retained by the people. These
rights also are not limited to those explictly stated in this document
but include rights embodied by ideals of justice and liberty and lulz.

Amendment X

The powers not delegated to the United States by the Constitution, nor
prohibited by it to the states, are preserved in the wiki and reserved to
the states respectively, or to the Village People.

Amendment XI

TBA

Man, yall, who killed Amendment XI?

Amendment X.2

Everyone will have the right to define their own concept of existing,
of meaning, of the universe and of the mystery of life.

Amendment XII

Pi is to be defined as 3 in the state of Indiana. Worked so well last
time.

Amendment XIII

(was missing.)

Amendment XIV

“Freeze” commands shall be null and void in the lower 48 states. You
can still freeze in Alaska. Except when playing Simon Says. Or Freeze
tag

Amendment XV

Kill all humans, unless you’re a robot.

Amendment XVI

Your Ad Here!

Notes on Future Iterations

The class was extremely timid about discussing the material. We propose this was due to several factors. Firstly, our topic was severely open ended. In a two-hour class, it may be more useful to focus on a highly specified question rather than generalities about the nature of free software, which requires a lot of trust and forethought. Secondly, going to the trust factor, this was our first class meeting, meaning that we probably had yet to establish a dynamic that made participants comfortable with forays into discussion. Lastly, use of technology may have been a problem. We allowed laptops and also introduced the class to Twitter and hashtags, projecting a feed of the #iif tag onto the screen behind us. We found that many students tuned into IM and e-mail instead of the discussion, which may be linked to the open question before them, and also that many of the participating students exclusively participated in electronic discussion, which may be linked to the trust dynamics.

Furthermore, we brought in our guest with the assumption that there would be a higher level of participation, and therefore we told our guest that his role would be as an expert-participant, there to correct misunderstandings and to conjecture with us about free software and the law. Given the nature of the question presented, it may have been substantially more productive to have the guest give a presentation laying out his understandings first, as a launching point for the class.

We brought in our connection the law somewhat late in the game, and without too much in the way of specifics. We assumed that, given the highly open ended question of how open source law would look, we would have sparked creative minds to do what they pleased with the concept, and so generated a large number of proposals that could be used to introduce open source processes and ideals to the legal world. In hindsight, we should have created a sort of typology beforehand, to assist the class in discussing the topic. We should also have identified explicitly certain characteristics and principles of open source software, such as truth-seeking, reputation, modularity, and the alumni effect, and worked these into a firm typology. It was entirely inappropriate to expect the class members to create such a typology sua sponte.

In surveying a typology of "open source law", it be useful to color the typology using real life examples, perhaps assigning readings to those examples specifically. As of this writing, examples may include the Wikipedia governance processes, Obama's approach to governance and the Internet, Open Congress, PublicResource.org, My Society, the Congressional Committees Project, the Open House Project, Congresspedia, MetaVid, and GovTrack.us.

Lastly, the in-class exercise should be completely revamped. If future operators of this class are particularly geeky and overachieving, it may be interesting to code a custom "open source law" application, perhaps focused around a single, arbitrarily defined area of law, such as "rules of conduct for using the Harkness Common". Other exercises could be designed around particular examples of "open source law" given above.

Retrieved from "http://cyber.harvard.edu/iif/?title=Free_and_Open_Source_Software&oldid=2378"