Free and Open Source Software

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

• The Gift, by Lewis Hyde. Chapter Five "The Gift Community" (p. 96-120).
• Some Simple Economics of Open Source, by Josh Lerner.
• Faculty Presentation 9/11/2008, by Eben Moglen. (skim)
• Two Bits, by Christopher Kelty. Chapters 3 (only pages 107-117) and 6.

Required Meddling

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

Optional Reading

• Perspectives on Free and Open Source Software, MIT press 2007
• The Dynamics of Collaborative Innovation - A Berkman Center Luncheon Video of a talk by Ned Gulley and Karim R. Lakhani.
• Open Source as Open Law - a power-point presentation by Wendy Seltzer
• Legal Reseach 2.0: The Power of a Million Attorneys - an article created using the Wiki Legal Journal
• The Emergence of Governance in an Open Source Community, by O'Mahony and Ferraro.

Guest

Benjamin Mako Hill joined 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, was invaluable in helping us understand FOSS.

We asked 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.

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. 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".

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 of motivation

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. The different motivations were 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 do not necessarily arise 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's existence, or a process 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.

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

The possibility of creating legal materials and legal norms using methods and tools of the FOSS movement could help promote several important ideals that are not addressed by current means of creating law (legislation, adjudication or drafting legal materials in law firms).

• Using decentralized mechanisms can help fix immediately inefficient or unjust law. If we compare these kinds of law to buggy code, then correcting it should follow Eric S. Raymond's saying: "with enough eyeballs, are bugs are shallow". There will be no need to leave bad laws in place just because no one had noticed them until they get litigated. Thus, the flexibility of law would create more efficient and flexible norms, who could follow the changing needs of society.
• Decentralized creation of law, allowing everyone to engage in law-making rather than only members of specific institutions, may promote our ideals of participatory democracy. By enhancing the public's sense of participation in law making, it may in turn increase the percieved legitimacy of law and the public's adherence to it. Different studies in psychological analysis of law have noted that as the law allows more participation to its subjects, it increases the obedience to it.
• FOSS methods may allow for greater experimentation in law, thus promoting experimental democracy. Moreover, in a radical recasting of federalism, the forking phenomenon of software development might be implemented in legal development, allowing different communities of flexible size to agree to different regulatory, criminal, and common-law systems to the extent our nation-state would allow it.
• As seen on the open structure of Wikipedia, for example, creating a successful open law project would require a lot of discussion and consensus-seeking. This, in turn, will promote the ideals of deliberative democracy and will engage more people in the discussion following the laws.

Problems

Unfortunately, there are also obvious downsides to the possibility of using FOSS as a method for creating law.

• According to the 80/20 rule, a phenomenon seen in Wikipedia for example, 80% of the law would be written by 20% of the people. This would place a huge amount of power in the hands of a small non-elected minority rather than in the hands of the entire population. On the other hand, it could be argued that a separation of 80/20 is still much better than the current situation insofar as we aim to maximize participation.
• The major problem that would stem from totally free modification of law is the problem of lack of democratic legitimacy; since the writers of the law are not elected in this totally open take on open source law, we would have no control over the values that the law will hold in the form of open participant collaboration. One possible answer to this concern may be to limit open source law to private law making only, allowing experimental legal structures to happen in significantly more cabined environments.
• The participants of open source law would lack formal training in legalese, and could create ambiguous and amateur laws. If statutory construction and interpretation can turn so wildly on minor textual issues, we might limit access to open source law-making to only the legally educated elite. On the other hand, the "with enough eyeballs, all bugs are shallow" formulation may just as well apply when sufficient laymen examine statutory law; over time, bugs will be rooted out and textual statutory construction will be substantially more limited.
• Added flexibility, introduced by open source methods applied to the law, may seriously undermine the stability of the law, thereby damaging parties that, for personal or commercial reasons, must rely on the law and would suffer enormous expenses and burdens if their expectations are subject to extreme jitter. Risk management, in this scenario, could be impossibly difficult.
• Without institutional mechanisms, these is a danger that minority voices will be silenced and that the open source law will become the tool of a tyrannical majority, or the tool of those who would game the system.
• The downside for the ability of forking law to match specific communities is that usually we aim for a unified body law. FOSS doesn't answer the question of who gets to make the final call on what becomes the law (following a twitt trom Leejbaker.
• As far as experimental democracy and experimental federalism is concerned, we may be too risk-averse to pursue these paths. We often aim for a unified body of law. Open source methods may not immediately answer the question of who gets to make the final call on deciding what the law is (following a tweet from Lee Baker ).

Examples of Free Software Principles Applied to the Law

There are a number of problems that emerge in applying FOSS methods to the law, yet each may hold promise of normitively better processes. We identify three specific implementations of "open source law", all relying on collaborative techology.

• Increasing transparency in the existing system
• Collaborative legal writing
• Collaborative law making

As http-based web browsing is the most familiar use of the Internet, the examples here will be focused to that domain. That is, other technologies important to FOSS, such as revision control, will not recieve treatment. For these limited purposes, we will focus on "Web 2.0". This term may refer to either particular web page encoding mechanisms to increase interactivity (e.g., it may refer to something like Ajax or to structures of web site design that enhance the client's role in contributing to the substantive product available at the site, thereby increasing its value to all clients).

Increasing Transparency in the Existing System

Web 2.0 technologies may be most easily used not to give people direct participatory roles in writing the law, but rather to increase transparency. Certain projects, for example, focus on making data on government action easily accounted for and tracked. Tools may allow citizens to monitor bills as the work through the legislature, they may attempt to match election donors and favorable treatment, and they may even allow for a streamlined notice and comment process. Several projects are already well underway...

• PublicResource.org : Carl Malamud's project aims to make statutory and case law of the United States of America (state and federal) freely accessible in a public domain archive (read more). Such an implementation doesn't necessarily add new material to the public domain, however it does make the public domain accessible to the public.
• 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.

• See also:
  • My Society
  • Congressional Committees Project
  • Open House Project
  • Congresspedia
  • Metavid
  • Govtrack
• Laura Gordon-Murnane Mashups, Blogs, Wikis Go Federal: Creative Uses of Government and Public Data

These projects may be the most successful because they don't attempt to alter any actual properties of the existing legal system. Rather, these systems only attempt to enhance the access to data and the meaningfulness of data. As such, they relate to the truth seeking function of open source methods and also enhance the risk to government agents of reputation damaging acts by making those acts accessible and understandable.

Collaborative Legal Writing

Several projects have used collaborative writing of other means of laymen participation as mechanisms of creating legal documents for one side in an adjudication.

• The OpenLaw Project uses FOSS-like suite of tools to discuss cases, and solicit evidence in order to help its lawyers write amicus briefs and other materials.
• The legal staff behind Joel Fights Back utilizes comments and suggestions from the general public in order to improve the quality of the legal briefs they write.

Collaborative Law Making

A more radical use of FOSS law would be, of course, to create actual binding legal norms. This take on open source law is used today in the internal regulation of online communities. The most well known example is the creation of 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. (for more information see R. Stuart Geiger, There is No Cabal: An Investigation into Wikipedia's Legal Subculture and David Hoffman & Salil Mehra, Wikitruth Through Wikiorder)

A glimpse to the possible use of FOSS to create national law could might be seen on 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.

Using Etherpad, we 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.

Another nexus of FOSS and law that could be discussed is the ways in which formal law promotes FOSS projects and open collaborations or holds them back. Lawrence Lessig argued, 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. Therefore, The GPL license was invented as a license designed to support FOSS and make people to switch to the sharing paradigm (see here and here for more information on the history of GPL).

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.