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.

1. Free/Open Source Software
Angelo Corsaro
Strategic and Technological Planning Directorate
SELEX SI
angelo.corsaro@selex-si.com
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. 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. (http://www.opensource.org/licenses/ accessed on
April 13th, 2006).
2

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. 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. 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. 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. 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. 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. References
[1] “Free Software Foundation”, http://www.fsf.org/
[1] “Open Source Initiative”, http://www.opensource.org/
[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”, http://www.rosenlaw.com/html/GPL. DF
P
[4] “Frequently Asked Questions about the GNU GPL”, http://www.gnu.org/licenses/gpl-faq.html
[5] “The GNU Project”, http://www.gnu.org
[6] J. Lerner, J. Tirole, “The Simple Economics of Open Source”, Journal of Industrial Economics, 50
(June 2002): 197-234. Also available at http://www.people.hbs.edu/jlerner/publications.html.
[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
http://opensource.mit.edu/papers/hippelkrogh.pdf.
[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
http://www.people.hbs.edu/somahony/Research%20Policy%20article.pdf
[9] http://www.gpl-violations.org/news/20041024-linux-tomtom.html
9