Open Source Biotechnology ProjectHomeTheoretical Perspectives* Introduction* Sociology of Science * Economics * Law Biotechnology Industry* Introduction* Industry Overview * Intellectual Property and Industry Structure Open Source* Introduction* What is Open Source? * Open Source as a Business Approach * Open Source Biotechnology? Project Design* Research Plan* Ethics * Researcher Profile and Contact Information LinksRevision historyCopyright (c) 2003 Janet Hope, Research School of Social Sciences, Australian National University, Canberra, ACT 0200. Verbatim copying and distribution of this site is permitted in any medium, provided this notice is preserved. |
What is open source?The sections under this heading provide some historical background to the concept of open source, then attempt to explain why in this website I have chosen to use the term "open source" rather than "free" to describe the model of biotechnology licensing this study aims to develop. Evolution
of Open Source Evolution of Open SourceTo understand what is meant by open source software licensing, let us first look at the more usual style of software licensing, which is sometimes called "closed source". To make useful modifications to a computer program, or to use parts of the program code in another program, it is necessary to have access to the source code. (A computer program is a sequence of instructions written by a human to be executed by computer. But computers can only execute instructions encoded as strings of binary numbers. So a computer program is first written in a form that can be read and understood by human beings, known as source code, and then translated by means of another program into binary form, known as machine or object code.) Many biotechnology research tools are protected by patent. But source code historically has not been regarded as patentable subject matter because it is essentially a series of mathematical algorithms or mental steps and is therefore on the wrong side of the discovery/invention divide in patent law. Instead, source code is usually protected as a literary work under copyright law. The owner of a copyrighted program has certain exclusive rights, including the right to reproduce and distribute the program and to prepare derivative works. Unlike patent protection, copyright protection also applies to unpublished works, so source code can be simultaneously protected by copyright and as a trade secret. The upshot is that anyone who buys a copy of a typical proprietary software program, such as Microsoft Word for Windows, is prevented from changing the program or using bits of it to make a new program in two ways: 1. They only receive the binary or machine code version of the program, the source code being kept secret -- those who need to see it, like employees of the owner, have to sign nondisclosure agreements. This is a practical form of protection. 2. Even if they had access to the source code, they would be legally prevented from changing or building on it by the terms of the licence agreement: the typical licence keeps the right to make copies, to redistribute or modify the program as exclusive to the owner. This is a legal form of protection. The business model that goes with this standard approach essentially treats the software as if it were a manufactured good. In the early days of computer programming, these proprietary restrictions on access to and use of source code did not exist. Instead, programmers exchanged source code according to etiquette within the computer science community, just as molecular biologists at that time followed their own community etiquette in exchanging information and resources. But in the late 1970s to early 1980s, intellectual property aspects of commercialisation began to affect the culture of the computer science community as well as the molecular biology community. Programmers left public sector institutions for well paid jobs with private companies, where they were asked to sign nondisclosure agreements as a condition of employment. One programmer who objected to these developments was Richard M. Stallman. He set out to create a suite of what he termed "free" software which would allow programmers to continue modifying and swapping software, including source code, to suit their specific needs without fear of being sued for breach of intellectual property rights. The word "free" in free software doesn't refer to price: Stallman didn't say that programmers had to work for free. What he did say was that copyright owners should allow the people who used their software certain liberties, in particular, the liberty to run the program for any purpose, to study how it works and adapted to specific needs, to redistribute copies, and to improve the program and release those improvements. In order to provide these freedoms, copyright owners would have to both provide physical access to the source code and also build legal freedoms into the copyright licence. In order to ensure that software developed as free software would continue to be available in all its derivative forms to the software development community at large, Stallman came up with an ingenious form of copyright licence that allows unrestricted modification and redistribution of the program with the entire source code, and in addition requires that works derived from the program must be licensed under the same terms. This kind of licence is known as "copyleft" ("all rights reversed"!), and it basically ensures that no one can privatise already licensed code under different terms. The idea is that once copylefted, the source code is forever available to the public. The archetypal copyleft licence is the GPL, which stands for GNU Public Licence (or General Public Licence). The GNU project was Stallman's first step towards the creation of a complete suite of free software. Begun in 1982, involves the construction of an entire clone of the popular UNIX operating system: GNU is a recursive acronym that stands for "Gnu is Not Unix". The GNU project was co-operative in that it drew on contributions from many individuals of programs and work as well as donations of machines and money by computer manufacturers. By 1990, Stallman's Free Software Foundation had developed almost all the components of a UNIX-like operating system, except for one crucial element -- the kernel. (The kernel is the core of a computer operating system; it provides basic services for all other parts of the operating system, including those that respond to user commands.) In 1991, a Helsinki University student named Linus Torvalds stepped into the breach. Torvalds began developing a free UNIX kernel using tools made available by the Free Software Foundation. He made good progress, and his initial success attracted lots of Internet hackers to help him develop Linux. Linux became a full featured UNIX with entirely free and redistributable source code; by late 1993, the program could compete on stability and reliability with many commercial UNIXs and hosted vastly more software. From the perspective of someone concerned about problems of access to proprietary tools for biotechnology research, however, the interesting thing about Linux was not the fact that it was developed, but the way it was developed. Before Linux, most people in the software development community, including the free software movement, believed that any software as complex as an operating system had to be developed in a carefully coordinated way by a relatively small, tightly knit group of people. But Linux evolved completely differently. Almost from the start, it was worked on rather casually by huge numbers of volunteers coordinating only through the Internet, which was just starting to take off around the early 1990s. Quality was maintained not by rigid standards or micromanagement, but by the simple strategy of releasing the code every week and getting almost instantaneous feedback from hundreds of users, a sort of rapid Darwinian selection on the mutations introduced by developers. Within hacker culture, these two contrasting models of software development are usually termed "the cathedral and the bazaar", following the metaphors in Eric S. Raymond's well-known essay of the same name: the "cathedral" is a program carefully constructed according to a pre-existing plan and the "bazaar" is a babble of different agendas and approaches. Looking at these contrasting development styles through a wider lens, it is easy to see strong parallels with ideas in the sociology of science literature about the relative merits of centralised and decentralised scientific research and also in the economics and intellectual property literature about whether certain economic justifications for having patent rights are suited to the needs of basic scientific research (in particular, Kitch's "prospect development model"). In fact, the "bazaar" model of software development shares many of its claimed good points with traditional academic scientific research, both in computer science and in biotechnology. The hurdle we now come up against in both cases is, how do we make this style of research pay? One way to analyse the software situation is to say that in economic terms, hacker culture exists in a post-material scarcity zone of surplus as a kind of "gift-exchange" culture where participants whose basic needs were met by employment in day jobs or as students gave away their coding efforts in exchange for enhancing their reputations within the community. Again, this is strongly parallel to traditional sociology of science analyses of academic scientific research. For commercial players, however, shareholders demand a more concrete return on investment while even for many non-commercial players some commercial activities may be necessary to cover funding shortfalls. What could be the motivation for a for-profit organisation, or a non-profit organisation that relies on licensing revenue for some of its income, to donate free access to its intellectual property to everyone, including competitors? In other words, is there any such thing as a viable "free" business model? In the case of biotechnology, this question has not yet been answered. But in the software context, we are starting to see the germ of a possible solution to the problem of how to make cooperative development pay in the emergence of many successful commercial enterprises that take a different approach to the standard "proprietary" business model of extracting rent from intellectual property. Essentially what these enterprises have in common is that instead of making money by charging for access, they allow relatively free access to the intellectual property and aim to make their profits in a secondary market, such as technical support or customising a basic product for special needs. Apart from this common element, there is a great variety of business models and a corresponding variety of open source licences. The term "open source" was coined essentially as a marketing strategy to promote a "free" licensing strategy to business. In the late 1990s, Netscape decided to license its Web browser under a free software license as a way of countering Microsoft's growing Internet Explorer market share, and hired Eric S. Raymond to advise on an appropriate licence. The free version of Netscape - Mozilla - was very successful, but more importantly, it was from this experience of thinking about free software from a business perspective that Raymond and others came up with the idea of open source. Before Mozilla, free software had not been of much interest to the business community, with the consequence that the influence of the "bazaar" method of development, which many members of the community considered superior to conventional development methods, was limited to noncommercial software development. In 1998, Raymond, Bruce Perens and others founded the Open Source Initiative. They developed an official definition of open source licensing, based on existing guidelines that had originally been developed by Perens, with input from users of the Debian GNU/Linux distribution, to help distinguish between licences that really did guarantee freedom to users and licences that had some similar features but were basically still proprietary licences. They also registered a certification mark to be applied to licences that complied with the official definition. The term "open source" has generated plenty of controversy within the free software community (see next section). However, it has also succeeded in getting businesspeople interested in free software. The key elements of the open source software definition are similar to the key elements of the free software definition. To be open source, software must be distributed under a license that guarantees the user three rights without charging any fee in return: 1. The right to have access to the source code (i.e. to have access to a version of the software program that can be understood and modified by a human being.) 2. The right to make copies of the program sell them or give them away. 3. The right to create modifications and derived works, and to redistribute these new versions under the same terms as the original license. (This aspect of the open source definition is looser than the GPL: under the GPL the user is actually obliged to distribute new versions on the same terms.) A range of approved open source licences exist. These licences lie at different points along a spectrum that is characterised by the amount of freedom given to licensees, or users of the software, and correspondingly how restrictive they are in terms of how the copyright owner can make money from the software. In choosing a license, it is necessary to strike an appropriate balance between these two priorities. Clearly, businesses will value their own freedom to sell their products in any way they want. But freedom for users is also a priority for the software owner because by treating users as codevelopers, and treating them well so they are motivated to co-operate, a business can save on development costs while building the kind of quality assurance and good rapport with customers that is essential for firms that regard themselves as being in the business of delivering a tool rather than just selling a commodity. Wherever an organisation wants to place itself along this line, a licence can be written to match (if there is none already available that is suitable!). In summary, open source licensing is a style of intellectual property management that seeks to combine freedom of access and freedom cooperate for users with the ability to generate revenue for owners. This style of licensing evolved out of the free software movement, but has adopted a specific role of promoting the ideals of free access and cooperative development on pragmatic terms to commercial software developers. The next section deals with the debate between proponents of the term "free software" and proponents of the term "open source" as it relates to the present study. References: Raymond, Eric S. 1999. A Brief History of Hackerdom. In Open Sources: Voices from the Open Source Revolution, edited by C. DiBona, S. Ockman and M. Stone. Online version: O'Reilly. Available from http://www.oreilly.com/catalog/opensources/chapter/ch01.html. DiBona, Chris, Sam Ockman, and Mark Stone. 1999. Prologue. In Open Sources: Voices from the Open Source Revolution, edited by C. DiBona, S. Ockman and M. Stone. Online version: O'Reilly. Available from http://www.oreilly.com/catalog/opensources/book/intro.html. Stallman, Richard M. 1999. The GNU Operating System and the Free Software Movement. In Open Sources: Voices from the Open Source Revolution, edited by C. DiBona, S. Ockman and M. Stone. Online version: O'Reilly. Available from http://www.oreilly.com/catalog/opensources/book/stallman.html. Raymond, Eric S. 2001. The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary. 2001. Online version: O'Reilly. Available from http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/. Perens, Bruce. 1999. The Open Source Definition. In Open Sources: Voices from the Open Source Revolution, edited by C. DiBona, S. Ockman and M. Stone. Online version: O'Reilly. Available from http://www.oreilly.com/catalog/opensources/book/perens.html. Kennedy, Dennis M. A Primer on Open Source Licensing Legal Issues: Copyright, Copyleft and Copyfuture. "Free" vs "Open Source" in software and biotechnologyIn this study, I have made a conscious choice to adopt the term "open source", with its connotation of deliberately trying to appeal to a business audience on the base of economic self-interest, instead of using the language of "freedom". This choice has been made with an awareness of the philosophical debate between proponents of free and of open source software. There are good arguments on both sides (which I do not attempt to reproduce here), but much as I would prefer to sit on the fence, defining this project has required me to make decisions that effectively align me with the proponents of open source terminology, even though the focus of the project is on biotechnology rather than software. I have chosen to try to make out the case for open source biotechnology on pragmatic/economic self-interest grounds for the following reasons: 1. As we have seen in the theoretical perspectives section, arguments in favour of unrestricted access to biotechnology research tools in the public interest are well-documented and generally convincing from a social welfare perspective. Most opposition to the idea of unrestricted access relies on pragmatic arguments, particularly on economic arguments about what would happen to the biotechnology industry if the players were forced to take a more open approach to their intellectual property. Thus, if this project could succeed in making an economic case for an open source approach to biotechnology, it would (perhaps ironically) constitute a more telling blow for the cause of freedom than even the most elegant theoretical demonstration of the importance of freedom of access. 2. The word "forced" in the previous paragraph is significant. As discussed in the theoretical perspectives section, one way to improve freedom of access to proprietary research tools is to deny owners of those tools the protection of intellectual property laws, or at least reduce the scope of that protection, through law reform; another is for the state or some other regulator to intervene in transactions following the grant of protection by the state to try to ensure transaction costs are low enough that research tools end up in the hands of those who value them most. These "top-down" approaches are being explored by other researchers. By contrast, the present study examines how participants in biotechnology research and development might be encouraged to consider a voluntary shift in intellectual property management practices towards a less restrictive approach by developing - if it is possible to do so - open source-style biotechnology business models capable of generating profits equal to or higher than profits generated by the traditional intellectual property-rent approach. This would remove not only the economic justification for restricting access to important tools, but the economic motive for doing so. In other words, pragmatic arguments in favour of unrestricted access hold out the hope that both sides of the IP debate might actually be able to agree on a course of conduct (even if their reasons differ). 3. By focusing on the economic motive for restricting access to research tools I do not intend to suggest that other drivers of human behaviour are absent or insignificant. For example, for many individual biotechnology researchers, the desire to help others is, I believe, a strong motivating force. But the biotechnology industry is made up of many different types of institutions, many of which have been established in order to serve private rather than public interests. Arguments that rely for their persuasive force on a commitment to promoting the public interest are even less likely to succeed with these institutions than with institutions who have at least some degree of commitment to promoting general social welfare. If the aim is to achieve a voluntary shift towards more open IP practices throughout the whole or a significant segment of the biotechnology industry, it will be necessary to find arguments that have a chance of swaying private as well as public sector and non-profit players. 4. A related point is that economic considerations may have the power to constrain those individuals who would otherwise be in favour of unrestricted access, or those institutions whose missions do include significant public interest components: universities are a case in point. In such cases, enumerating ideological arguments would be preaching to the converted. The problem is that the converted don't always have the resources to act purely in the public interest, whether because of declining public funding for research, barriers to entry given existing industry structure or other disadvantage. It is therefore necessary to find a way to allow such players to manage their IP in the public interest while at the same time retaining the ability to generate needed income. 5. The previous point highlights the fact that economic arguments are not always incompatible with, or even different from, public interest arguments. Saying that participants in the biotechnology industry should consider adopting an open source approach because they will (sometimes) make more money that way is one kind of economic argument. But another kind is to say that adopting an open source approach is a strategic tool for weaker players and public interest research institutions to change the nature of the biotechnology industry itself so as to overcome existing disadvantages and make the industry more competitive. In this way the economic motivations of individual industry players would become more closely aligned overall with the public interest (this has echoes of Merton's "functional norms"-- see sociology of science discussion). Of course, these arguments are open to some of the same criticisms made by free software critics of the open source movement. In particular, proponents of the term "free software" argue that by abandoning ideological arguments as unpersuasive to some members of our audience, we implicitly accept (and spread) the economic rationalist view that the only good arguments are economic arguments, which of course is not true. Adherents of the free software movement also argue that if you achieve freedom at the cost of talking about freedom, you ensure the victory is short-lived because those who come after will not have been trained to fight for freedom and accept the responsibilities that go with it (another way to put this is that freedom is sustained through normative structures that must be passed on within the culture). These are undeniably good points-- some days I think they ought to prevail. But to the extent that they are raised in opposition to use of the term "open source", they seem to be based on the assumption that it is unconvincing to talk about the ideology of freedom while simultaneously advancing other more pragmatic arguments in its favour -- or in other words, that it is somehow not legitimate to present arguments for free access to intellectual property "in the alternative". It may be that presenting different arguments to different people depending on what they are most likely to find convincing does diminish overall credibility. But I think it probably doesn't -- to the extent that different audiences are aware of the message as a whole (as distinct from just that part of the message that is targeted at them), I think they can handle the complexity. At any rate, I have chosen to hope so. (After all, I am a lawyer. :) ) References: Open Source Initiative, "Why "Free" Software is too Ambiguous": http://www.opensource.org/advocacy/free-notfree.php Free Software Foundation, "Why ``Free Software'' is better than ``Open Source''": http://www.gnu.org/philosophy/free-software-for-freedom.html |