Free and Open Source Software: Difference between revisions

From The Internet: Issues at the Frontier (course wiki)
Jump to navigation Jump to search
Line 328: Line 328:
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.
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 discusing the topic. We should also have identified explicitly certain principles of open source software... left off here XXX
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, [http://opencongress.org Open Congress], [http://public.resource.org/ PublicResource.org], [http://www.mysociety.org/projects/ My Society], the [http://www.dkosopedia.com/wiki/Congressional_Committees_Project Congressional Committees Project], the [http://www.theopenhouseproject.com/ Open House Project], [http://www.sourcewatch.org/index.php?title=Congresspedia Congresspedia], [http://metavid.org/wiki/ MetaVid], and [http://www.govtrack.us/ GovTrack.us].


We would propose modifying any in-class experiment in several ways...
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.

Revision as of 13:22, 10 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.

beyond motivations?

The multiplicity of Motivations

xxx - benkler's list of motivations - xxx

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


xxx - Source from etherpad: retaining the "old school unix hacker" culture; fighting the behemoth; end of copyright; community of geeks; egoboo; ethical obligations to distribute (Stallman)

(XXX make sure to talk about all of these:

  • What characteristics of software make the open source model viable or successful?
    • Process characteristics
      • Enabling, not coercion
      • Debian's government as reactive, rewarding developers, bottom-up, minimalist (excerpt from Debian article)
      • Innate democratic principles written into the structure
      • Developers value group cohesion.
    • Substance characteristics
      • Modularity is very good. E.g., Netscape (bad), Linux (good)
      • Niche markets are great places for FOSS
      • Where big industry players dominate, FOSS attempts to attack



Law and FOSS

Legal Support for the FOSS Model

using law to support FOSS: The idea that the current legal norms are not supporting FOSS and are based on proprietary assumptions.


why does FOSS need licensing?

Applying Open Source Methods to the Creation of 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.

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

both meanings:

Ideals and Problems

xxx 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 and uses of FOSS principles to creation of 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=2249"