Free/Open Source Software


Published on

This paper provides a short introduction to the Open Source Model. It explains the most important aspects of Open Source Licensing as well as the Innovation Model at the foundation of Open Source.

Published in: Technology, News & Politics
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Free/Open Source Software

  1. 1. Free/Open Source Software Angelo Corsaro Strategic and Technological Planning Directorate SELEX SI Abstract. This position paper provides an overview of the Open Source Software movement and defines how companies can approach, exploit, and learn from it. More specifically, this position paper will first provide the needed details on Open Source licensing models – a key element to be aware of in order to safely approach Open Source. Then, it will provide motivating rationales for getting involved in Open Source software production. It will define a reference innovation model which might be used as a basis for Open Source projects, along with a few suggestions on how to protect Intellectual Properties associated to Open Source Projects. Key Points. After reading this document you will learn about the following key points:  Free/Open Source (F/OSS) Software does not mean free as in “free beer” but free as in “free speech”. This means that F/OSS can, and it is not rare, be commercialized.  F/OSS is a term referred to software which is licensed according to one of the licenses approved and maintained by the Open Source Initiative (OSI).  GNU Public License (GPL) and Lesser/Library GPL (LGPL) are the two most common licensing schemes applied to F/OSS. The key concepts of these licensing model are based on the copyright law and are thus strongly based on derivative work.  The GPL license is typically referred as viral, while the LGPL is typically safe w.r.t. proprietary SW. This document highlights under which circumstances the GPL licensed SW contaminates proprietary SW.  Depending on (1) the interactions of proprietary developed software and F/OSS, and (2) on the F/OSS license, then, some parts of the proprietary developed software might be licensed as Open Source– however, this does not mean that sources have to be provided for free, i.e., a fee might be charged.  The Open Source paradigm enables and promotes user-driven innovation and its underlying innovation model – the private/collective innovation model – can be used as a model for enterprise innovation.  Open Source is not naïve as it provides some effective means for intellectual property and assets protections. Executives Roadmap. The document is organized into three different sections. Section 1 provides a historical overview of the F/OSS movement. Section 2 explains the F/OSS licensing models, and Section 3 provides an Innovation model which can be used in Open Source projects. Depending on your immediate needs and interest the document can be read all at once, or at different times following the roadmap outlined below:  Understand F/OSS Licensing – Read Section 1 and 2.  Innovation Models for F/OSS – Read Section 3. 1
  2. 2. Introduction In the past several years, the Free/Open-Source Software (F/OSS) community has been enjoying a vibrant software development activity which has made available several high quality software artefacts. Some of the most notable examples of this productive activity are the GNU/Linux Operating System, the Apache web server, the GNU C Compiler (GCC) family, etc. As the quality of many F/OSS is quite outstanding, and their source code is available and can be readily adapted and extended to user needs, a growing number of corporate have started to increasingly adopt F/OSS as a valid counterpart to commercial and proprietary software. Due to the increasing importance of F/OSS, this position paper has the goal of clarifying what F/OSS actually is, what are the terms associated with its use, and what other hints which can be gained from this movement. 1.1. Historical Background The sparkle which gave birth to the whole movement was Richard Stallman, which in 1983 started the GNU (GNU is Not Unix) Project [2] with the intent of building a free computing platform. In 1985, Stallman, founded the Free Software Foundation (FSF) [1] to support the GNU Project for bringing freedom to software user and developers. Stallman, along with other members of the FSF, contributed to the seminal development and diffusion of legal mechanism that could preserve free access to the software developed under the FSF, specifically the GNU General Public License (GPL). As stated in the FSF manifesto, their interpretation of Free Software is as in free speech and not as in free bear. This means that they tolerate that free software might be available at a fee, however the presence of the term “free” has historically created confusion and has often more or less mistakenly interpreted as “for free”– meaning at no fee. This interpretation had for sometimes limited the adoption of the ideas promoted by the FSF within the mainstream industry. To overcome this issue, in 1998, Bruce Perens and Eric Raymond funded the Open Source Initiative (OSI) movement. Open Source Software relies on the same licensing schemes of FSF, and its main differences with respect to the FSF are philosophical–preferring the pragmatic benefits of the GPL licensing schemes over the ideological and moral rightness of granting user freedom. In the reminder of this document we will fly over these philosophical differences and will refer to Free and Open Source Software as a single entity identified by the acronym F/OSS. 1.2. Paper Organization The reminder of this paper is organized as follows, Section 2 will provide an overview of the issues which should be considered when using F/OSS, and specifically it will explain to a certain details F/OSS licensing; Section 3 will describe in which cases proactively making F/OSS can be a good strategic choice for a company, and will describe the techniques which can be used to protect the investment as well as the underlying innovation model which should be considered. 2. Using Free/Open-Source Software The key distinguishing characteristics of F/OSS, with respect to traditional software, is its licensing scheme. A software artefact can be labelled as Open Source, if and only if its licensing scheme has been accepted by the Open Software Initiative (OSI) [5]. Currently1 are available more than fifty licenses, but the most frequently used licenses are respectively the GPL and the Library or “Lesser” GPL (LGPL). Just for sake of completeness, it is worth mentioning that the Free Software Foundation has a stricter perspective and allows as the only possible licensing scheme the GPL and in some rare cases the Library or “Lesser” GPL (LGPL). Since the difference in terms of rights and obligations depends on the kind of F/OSS license, developing an understanding of the basic concepts is fundamental to avoid issues sometimes caused by the viral effect of some of these licenses. In this section we will provide an overview of the major F/OSS licensing schemes, and will dispel some misconceptions and misunderstanding about typical F/OSS licensing, as well as outline some areas of shades. In the reminder of this Section we will provide a brief overview of the basics of Copyright law, and then we will dwell on Open Source Licensing. 1 At the time of writing the OSI website lists 58 Open Source licenses. ( accessed on April 13th, 2006). 2
  3. 3. 2.1. Open Source Licensing and Copyright Open Source Licensing has the peculiarity of exploiting certain features of the Copyright law in an extremely creative way. Thus, before proceeding with the explanation of some of the implications of the most popular Open Source licenses, it is worth reviewing the basic principles of Copyright Law. As defined by the Berne Convention and the World Trade Organization agreement on Intellectual Property Rights, copyright is automatically attached to every novel expression of an idea, whether through text, sounds or drawings. Nobody, other than the copyright holder, has under the copyright law, the rights to create derivative work, i.e., work that depends or extends the original copyrighted work. This characteristic of the copyright is particularly relevant to Open Source licenses as it is used in a way that is in a way opposite to the original intention of the copyright law. Based on the copyright law, works created “for hire” are still subject to the copyright protection, however, in this case the copyright belongs to the employer of the creator, or the person who commissioned the work, not the creator. The copyright legislation also contemplates the concepts of “fair use” of copyrighted material as non infringing, and “transformative derivative work”. “Fair Use” allows persons other than the creator to make certain limited use of the copyrighted material for commenting or criticizing the work, for reporting, or teaching related to the copyright protected material. “Transformative derivative work” is one that fundamentally alters the work on which is based upon to result in a new work, as a consequence the copyright holder of the original work has no rights on the transformative derivative work. Finally, it is worth mentioning that the copyright protection is limited in time. Specifically, the copyright expires either with the death of the author, or after a specific amount of time after the creation. Once the copyright protection expires, the work goes into the “public domain”. 2.2. F/OSS Licensing The goal of F/OSS licensing is to deny to anybody the right to exclusively exploit a work, so to allow a broader community to exploit and further develop the original work. To do so, the F/OSS licensing exploits the copyright law so to obtain a result which is at the odds with the usual intent of copyright. Specifically, the key intent of F/OSS licensing is that of promoting derivative work, under certain constraint, instead of restricting it. Depending on what is imposed on derivative work, Open Source licenses can be distinguished between those subject to generational limitation and those that are not. The generational limitation consists on requiring that derivative work is distributed under the same licensing scheme of the original work—this is typically used to enforce that all derivation of a F/OSS remain open. To the date several different licenses exist which are recognized as Open Source. These licenses are maintained by the Open Source Initiative (OSI) web site [2], and typically range from very restrictive such as the GNU General Public (GPL) license to quite generous such as the BSD or the MIT licenses. In the reminder of this Section we will provide a detailed description of some of the more representative F/OSS licenses. 2.2.1. GNU General Public License (GPL) The GNU GPL is the one of the most widely used licenses for Open Source Software, and it is the preferred FSF license. The GPL employs copyright to suspend the usual operation of copyright within the domain of F/OSS development. This license defines two important terms, (1) “the Program” means a work subject to the license, and (2) a “work based on the Program” which refers to any derivative work under the copyright law: that is to say, a work containing “the Program” or a portion of it, either verbatim or with modifications and/or translated into another language. The main purpose of the GPL license can be reassumed into three points: 1. Keep “the Program” free so that it can be distributed and modified without additional permissions of the licensor. 2. Ensure that licensees are aware that “the Program” under license is distributed “as is” and without warranty. 3. Ensure that the licensed “Program” is free of restrictive patents. Specifically, if a patent applies to the licensed “Program” it should be licensed in parallel with the code. 3
  4. 4. The Program is kept free by relying on generational limitation and requiring that derivative work of “the Program” be GPL licensed. Failing to comply with this requirement immediately terminates the validity of the license—this restriction is typically referred as copyleft. Because of this generational limitation, for which GPL has gained the appellative of viral license, is extremely important to understand the scope of derivate work as applicable, based on the GPL license ,and the copyright law. “the Program” “another Program” “the Program” “the Program” extension generates interaction “the Program” “the Program” “another Program” “another Program” (a) (b) (c) (d) Figure 1 – Classification of GPL Derivative Work. Figure 1 shows graphically a classification of interactions between “the Program”, here assumed as a GPL licensed software, and “another Program”. Depending on the kind of interaction, “another Program” might be considered as derivative work of “the Program”—in this case would have to be GPL licensed—or not. The most straightforward case of derivate work of “the Program” is represented by any extension or modification of “the Program” itself, as depicted Figure 1(a). Another case of derivative work is depicted in Figure 1(b), in which “another Program” combines the “the Program” by either including its source or by statically linking it. In both of these cases “another Program” is derived work under the copyright law, and has to be GPL licensed. The case depicted in Figure 1(c) covers the case in which “the Program” generates code. The generated code has to be considered as derivative work of “the Program” only if part of “the Program” source code are copied into the generated code. Otherwise the generated code cannot be considered as derived work and can then be used in proprietary software without any fears. Figure 1(d) refers to the case in which “another Program” interacts at runtime with “the Program”. In this case depending on how the interaction happens the answer differs – and for some instances of these case, there are no clear answers, as it depends on how strictly the concept of derived work is interpreted. At the risk of getting to technical, we provide a few examples, adapted from [4], of cases for which, depending on the kind of interaction, “another Program” would be considered a derivative work of “the Program” or not. Dynamically Linked Library. If “the Program” is a library and “another Program” links it dynamically than it is considered to be derivative work, and will have to be GPL licensed. Plug-in. If we assume that “another Program” is a plug-in for “the Program”, then it depends on how “the Program” invokes its plug-ins. If “the Program” uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them – which means that “another Program” is not considered derivative work of “the Program”. If “the Program” dynamically links plug-ins, and they make function calls to each other and share data structures, the FSF and OSI believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed. If “the Program” dynamically links plug-ins, but the communication between them is limited to invoking the `main' function of the plug-in with some options and waiting for it to return, that is a borderline case. Aggregation and Combination. Mere aggregation of two programs means putting them side by side on the same medium such as a CD-ROM or an hard disk. Thus the term aggregation is used when the two program are separate, not parts of a single program. In this case, if one of the two programs is covered by the GPL, this has no effect on the other program. Combining two modules means connecting them together so that they form a single larger program. If either part is covered by the GPL, the whole combination must also be released under the GPL. What constitutes combining two parts into one program is a legal question, which ultimately judges will decide. A proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of 4
  5. 5. information are interchanged). If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program. By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program. Finally, it is worth pointing a few points, (1) the sources for the derived work have to be made available only if the derived work is distributed. This means that if the derived work is used within the an enterprise, no source- code has to be made available, (2) currently there is a theoretical, but remote, possibility that the copyright holder of the GPL licensed program might terminate the license to switch to a proprietary one. This possibility might be forbidden by future extensions of the GPL license, (3) a company can sell GPL licensed software to a client for a fee, but once bought, unless other restriction are imposed, the client has all the rights granted by the GPL license, which means he can copy, modify, distributed, etc. 2.2.2. GNU Lesser or Library General Public License (LGPL) The GNU Lesser General Public License (LGPL) has been created by the FSF for allowing the combination of certain class of programs, i.e., libraries, with non GPL, and proprietary, software programs. This license specifically address the case depicted in Figure 1(d) when the interaction is due to “the Program” being linked into “another Program”. Essentially what this license does is to reduce the scope of derivative work as intended for regular GPL licenses, by allowing a program which interacts with a GPL program by linking it, not to be considered as derived work. Finally it is worth noticing that the FSF only accepts and recognizes as F/OSS licenses the GPL and LGPL, moreover, the preferred license is GPL – the use of LGPL is discouraged as much as possible, and limited to some special cases, for example the most common case is when a free library’s features are readily available for proprietary software through other alternative libraries. In that case, the library cannot give free software any particular advantage, so it is better to use the LGPL for that library. Table 1 summarizes the relation between “the Program” licensing and “another Program” implied licensing depending on the interaction between the two. Table 1—Summary of derivative work licensing implications. “the Program” License “another Program” License GPL GPL Extension LGPL LGPL GPL GPL Combination LGPL LGPL GPL only if generated code contains part GPL of “the Program” Generation LGPL only if generated code contains part LGPL of “the Program” GPL Depends on the details of interaction Interaction LGPL Any 2.2.3. MIT License The MIT license is perhaps one of the earliest Open Source License. This license is extremely generous and permissive as it grants practically all the rights to the licensee. More specifically, the license only requires that the copyright notice be included in derived work, but then does not impose any restriction on availability and licensing of the derived code. Thus differently from what was required by the GPL license, the MIT license does not impose any generational limitation. 5
  6. 6. 2.2.4. BSD License The BSD, along with the MIT license, is one of the earliest and more generous Open Source Licenses. However, compared with the MIT license, the BSD is a little bit more restrictive as it requires that neither the name of the organization nor the name of the authors might be used to endorse or promote products derived from this software without any prior written permission . To avoid the incorrect use of the first author’s name, some old versions of this license used on distribution of BSD Unix, included a clause, named “advertising clause” , stating; “All advertising materials mentioning features or use of this software must display the following acknowledgement: this product includes software developed by the University of California, Berkeley and its contributions.” The above mentioned clause never took away the freedom nor the correspondence to F/OSS criteria, but could create practical problems for the compatibility with the GPL; in fact the union of code parts with the two licenses may be actually prevented owing to GPL clause that prevents from adding further conditions. Currently, Berkeley University has removed this clause from all codes created by the University itself; the clause was officially rescinded by the Director of the Office of Technology Licensing of the University of California on July 22 1999. He states that clause 3 is “hereby deleted in its entirety.” In this Section we have explained the basic principles on which Open Source licenses rely upon, and have provided an overview of the most popular Open Source licenses. The interested reader can refer to the OSI [1] web site for a complete list of all the recognized Open Source licenses. We believe that what explained in this Section should provide the basic background information needed for easily understanding the difference between different licenses. Figure 2 – Private/Collective Innovation Model 3. Making Free/Open-Source Software For a long time F/OSS has been puzzling many researcher at top business schools around the world, such as the Harvard Business School or the MIT Sloan School of Management, etc. What was not clear to researcher, and still is partially understood, were the motivations and economics behind F/OSS. At first sight, in their eyes, F/OSS was economically a hard to explain movement. Today, many of the key researcher working on understanding the success of F/OSS, and formalizing some of its alchemy, have provided basic economical models [6], innovation models [7], and protection models [8] for F/OSS projects. Other very inspiring and influencing contributions, which are worth exploring from a corporate perspective, are in the area of organizational science. It is fair to say that the understanding of F/OSS is increasing both in the academia and in the industry. The latter is learning how to exploit F/OSS as a non-zero-sum, or win-win, game, in which innovation and 6
  7. 7. competitive advantage is gained in an open and shared environment. F/OSS principles are also being exploited for governance and innovation model within large corporate. Due to the growing importance of the basic principles behind F/OSS, in the reminder of this Section we will provide an overview of (1) the innovation model which can be assumed as a model organizing F/OSS projects, and (2) the techniques which can be used to protect intellectual properties in an open and shared environment. 3.1. Private/Collective Innovation Model The F/OSS movement has defined a novel and successful alternative to traditional innovation model. This alternative, which is often referred as Private/Collective Innovation Model [7] is opposed to the usual Private Innovation model which assumes that innovation is supported by private investments and private returns. In private innovation model, to encourage private investments in innovation, the society grants to innovators some payback in the form of intellectual property law mechanisms, such as copyrights, patents, trade secrets, etc. These can be exploited by innovator in order to have competitive advantage and private returns from their innovation investments. On the other hand the Private/Collective Innovation model combines the private investment model with the model of free revealing and sharing of innovation which is typical of collective innovation models. This is based under the assumption that sharing innovation is not detrimental for private investment, but actually fosters and catalyses more innovation. graphically illustrates the concepts behind the Private/Collective Innovation Model. Here it can be seen how a smaller core, denoted by the private set, proactively contributes to the F/OSS project by providing a combination of their time, skills, technology, funds etc., depending on whether they are individual contributors or corporations. At the same time they get back, improved skills, technology, reputation, career opportunity, fun, etc. What makes this scheme interesting is that even free-riders —those that use without consciously contributing—contribute positively to this ecosystem by testing the used technology, and building up popularity, credibility and acceptance for the technology under development. Critical for the success of a F/OSS project is the composition of the private portion of the model. Several studies suggest that the right ecosystem should contain other than initial investors, members of the user community, Small Medium Enterprises which will commercialize the development of the ecosystem. It is not rare that the parties funding the project also come from the user community, and are motivated by satisfying some of their need which are not currently well captured by the market, or commoditizing some technology. As a practical example of this kind of ecosystems, shows the CARDAMOM ecosystem. CARDAMOM is a project jointly developed by SELEX Sistemi Integrati (SI) and THALES whose goal is the creation of a standard-based middleware platform for near real-time fault-tolerant mission and safety critical systems, such as Air Traffic Control Systems, Combat Management Systems, Airborne Systems, etc. The first main user of the CARDAMOM technology will be the European Flight Data Processor (FDP) project which SELEX-SI and THALES are developing for Italian (ENAV), French (STNA) and Swiss (Skyguide), national aviation administrations. This complex ecosystems shows that there are two parties, SELEX-SI and THALES, which through a Common Development Organization (CDO), are committed to the development of the CARDAMOM project. Then, within the ecosystem, there is also a PrismTech, a SME which will provide commercial support for CARDAMOM and ObjectWeb which is an OpenSource consortium providing some help in giving CARDAMOM visibility within the open source community. An additional element present in , is the Object Management Group (OMG), through which the CARDAMOM technology is standardized. 7
  8. 8. Figure 3—The CARDAMOM Ecosystem. 3.2. Protecting Open Source As it was described earlier in this Section the F/OSS development model can be a viewed as a way of fostering innovation, especially in sectors which are characterized by high level of user-driven innovation. In the reminder of this Section we will tackle the issue of protecting the investment. To this end we will provide a list of practices which have been adopted with good success for avoiding hijacking, and protecting the investment by many F/OSS projects, and which might be relevant for a company of the group. In what follows we will provide a list of practices adopted by most representative F/OSS projects such as the GNU Project, Linux. Apache. etc.  Licensing. One practice that is followed, by all F/OSS projects is that of adopting software licensing with distribution terms that restrict proprietary appropriation. This is typically done by adopting GPL, LGPL, or another of the available Open Source licenses which impose the generational limitation. As an example, the CARDAMOM project is licensed as LGPL. This choice was made to avoid hijacking by other companies, and to make it possible that our own proprietary software build upon CARDAMOM does not need to be Open Source (see Section 2.2.2).  Trademarks and Logos. The main motivation for filing a trademark is to ensure that the project is uniquely distinguished and to prevent others from confusing a project with other related work. Often it is recognized that some form of active protection of the trademark is needed in order to prevent the project name or symbol from misuse. As an example the name CARDAMOM™ is a shared trademark between SELEX-SI and THALES, its visual logo has also been registered to be the CARDAMOM text in green.  Legal and Normative Sanctions. Compliance with licensing terms through normative and legal sanctions should be encouraged. For instance the Free Software Foundation (FSF) will pursue violations of GPLed work which they holds copyrights and offer assistance to other copyright holders as requested. It is worth pointing out that the FSF is quite active in pursuing violation, the last most notable case of copyright infringement is that of TomTom a Dutch vendor of navigation systems (see [9]).  Other practices which are often used by F/OSS projects, and either trivially apply, or, might not directly applicable, to our case consist of, Incorporate to hold assets and protect individual contributors from liability, transfer individual property rights to corporation, and assigning trademarks to a foundation. If these practices are used in synergy make a F/OSS quite robust with respect to hijacking and provide a good protection of investments and intellectual properties. To make sense of all of this require a different perspective and a paradigm shift, but it should be recognized that there is a lot of potential for exploiting the power of F/OSS. 8
  9. 9. References [1] “Free Software Foundation”, [1] “Open Source Initiative”, [2] J. Feller, B. Fitzgerald S. A. Hissam, K. R. Lakhani editors, “Perspectives on Free and Open Source Software”, The MIT Press, 2005 [3] L. Rosen, “The Unreasonable Fear of Infection”, DF P [4] “Frequently Asked Questions about the GNU GPL”, [5] “The GNU Project”, [6] J. Lerner, J. Tirole, “The Simple Economics of Open Source”, Journal of Industrial Economics, 50 (June 2002): 197-234. Also available at [7] E. von Hippel, G. von Krogh, “Open Source Software and the „Private-Collective“ Innovation Model: Issues for Organizetion Science“, Organization Science, 14 (2), 209-223. Also available at [8] S. O’Mahony, “Guarding the Commons: how Community Managed Software Projects Protect their Work”, Elsevier Research Policy, 32 (7), 1179-1198, Also available at [9] 9