A Sentence-Matching Method for Automatic License
Identification of Source Code Files
Daniel M. German

Yuki Manabe

Katsuro Inoue

University of Victoria, Canada

Osaka University, Japan

Osaka University, Japan

dmg@uvic.ca

y-manabe@ist.osakau.ac.jp

inoue@ist.osaka-u.ac.jp

ABSTRACTThe reuse of free and open source software (FOSS) components is becoming more prevalent. One of the major challenges in ﬁnding the right component is ﬁnding one thathas a license that is adequate for its intended use. The license of a FOSS component is determined by the licenses
of its source code ﬁles. In this paper, we describe the challenges of identifying the license under which source code
is made available, and propose a sentence-based matchingalgorithm to automatically do it. We demonstrate the feasibility of our approach by implementing a tool named Ninka.
We performed an evaluation that shows that Ninka outperforms other methods of license identiﬁcation in precision andspeed. We also performed an empirical study on 0.8 million
source code ﬁles of Debian that highlight interesting facts
about the manner in which licenses are used by FOSS.

1. INTRODUCTION
Free and Open Source Software (FOSS) has become an
important source of reusable code [19]. To be able to reusea FOSS component an application (proprietary or FOSS)
should satisfy all the requirements and conditions that thelicense of the component imposes [17]. Sometimes a component is available under various licenses, giving the integrator the ability to choose the license that best ﬁts her
purpose (the license of the component is compatible with
the intended use). For example, the MySQL database canbe used under the conditions of the General Public License(GPL) version 2, or the integrator can buy a commercial
license for her speciﬁc needs [10]. Most frequently, however,a component can only be used under one license. For example, in August of this year, Nokia tried to convince thedevelopers of PyQT to change its license from GPL version
2 to the Lesser GPL version v2.1, but did not succeed. As aresult, Nokia has started a project to create a replacement,
called PySide[16]. Nokia explains its rational: “PySide has
been published as a response to the lack of suitably licensed
Qt bindings for Python. PySide is licensed under the LGPL

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.
Copyright 200X ACM X-XXXXX-XX-X/XX/XX ...$10.00.

version 2.1 license, allowing both Free/Open source softwareand proprietary software development.”
In an empirical study, Li et al. reported that 37% of companies that used OSS components modify their source code[15]. They also emphasize that any organization wanting toreuse FOSS components (either with or without modiﬁcation) should consider the legal implications of such changes.
The legal issues of reusing FOSS components aﬀect not
only companies, but other FOSS components and applications. As reported in [10], FOSS applications are also concerned about licensing issues, primarily if the license of the
FOSS component is compatible with the license of the application that uses it. If they are not, then the component
cannot be used.
One of the major challenges of intellectual property clearance is to identify the license under which a FOSS component, and each of its ﬁles, is made available. This is due
to several factors: 1) there is a vast number of open source
licenses, some approved by the Open Source Initiative (currently 65), and many more that are not—Table 1 showssome frequent FOSS licenses and their abbreviations, as usedin this paper; 2) a FOSS product might be made available
under several licenses, 3) diﬀerent versions of a FOSS component might be available under diﬀerent licenses; and 4) the
overall license of a product might be diﬀerent than the license of each of its ﬁles.
When ﬁles under various licenses are combined to create
a FOSS component, there is a risk that one of these licenses
might be incompatible with the overall license of the component, hence any integrator using that component might
be liable for infringement [17, 18].
Another problem is that several well-known licenses exist in various versions. For example, the GPL exists inversions 1, 2 and 3, and each of these versions is incompatible with the others (ﬁles under one version cannot be
combined with ﬁles under another version, as described in[8]); similarly code under the BSD4 code cannot be included
in software released under the BSD3 or BSD2. Frequently
FOSS software portals, such as SourceForge, only list thename of the license and omit the version in the metadata of
the applications they host. Furthermore, they make no attempt to verify that this license listed is indeed the license of
the component. For example, the FOSS portal Freshmeat(freshmeat.net) lists Eclipse as licensed under the CPL,
when in fact, it uses the EPLv1 (the CPL is a predecessorof the EPL).
The contributions of this paper are: 1) We describe andcategorize the challenges of license identiﬁcation. 2) We pro-Abbrev.

Name

ApacheBSD4Apache Public License
Original BSD, also known as BSD with 4
clauses
BSD4 minus advertisement clause
BSD3 minus endorsement clause
The Boost Software license
Common Public License
Common Development and Distribution
LicenseEclipse Public License
General Public License
IBM Public License
Lesser General Public License (successor of
the Library GPL, also known as LGPL)
Library General Public License (alsoknown as LGPL)
Original license of X11 released by the MIT
License similar to the MIT/X11, but with
diﬀerent wording
Mozilla Public License
File is licensed in the same terms as Perl
File points to another where the its licenseisSimple license used by software developedby Sun Microsystems
The zlib/libpng license

BSD3
BSD2
boost
CPL
CDDL
EPL
GPL
IBM
LesserGPL
LibraryGPL
MIT/X11
MIToldMPL
SameAsPerl
SeeFileSunSimpleLic
ZLIBref

second method for license identiﬁcation is used by FOSSology [12]. It uses an algorithm called the Binary Symbolic Alignment Matrix (bSAM), traditionally used in protein alignment. All these tools are open source.
In [21] Tuunanen et al. compared OSLC, FOSSology andtheir own implementation, called ASLA (based on the regular expression method). Their evaluation consisted in an
empirical study that used 12 FOSS applications. They measured the recall of each of the tools, but did not verify theirprecision. They also reported that the major disadvantage
of FOSSology is that it is slow (it took approximately 1minute per ﬁle) compared to OSLC and ASLA (that wereable to process almost 4000 ﬁles per minute in the same
computer). To date, this has been the only formal evaluation of license identiﬁcation tools. License identiﬁcation is
only a facet of ALSA. It is also a GUI environment for the
analysis of the interactions between the licenses of diﬀerent
FOSS components in a heterogeneous system. Similar work
has been proposed by Alspaugh et al. [1].
Research we have performed in the last two years has required the identiﬁcation of licenses of a large collection ofﬁles (see [11, 6, 7]). We have identiﬁed the following issues
with the current license identiﬁcation systems:• They are not precise enough. In many cases these systems can identify the family of a license, but not its
version. In [7] and [9] we have demonstrated that license evolution is a growing issue, acerbated by lack oftools that properly identify the version of a license. As
licenses evolve, the new versions are not always compatible with older versions.

Table 1: Names of common open source licenses andtheir abbreviations used in this article. Many ofthese licenses have several versions. In that case
we use the suﬃx v<number> to identify it. If it
is followed by +, that means the user can choose
this version or any newer: “or later”. For example,
GPLv2+ means “GPL version 2 or later”.

• They do not report unknown licenses. It is important
to know that a ﬁle has a license, even if the tool is notcapable of identifying it. A legal auditor can skip ﬁlesthat do not to include any license, and concentrate on
those with an unknown one.

pose a method for license identiﬁcation based on the analysis
of each of the sentences in the license statement of a sourcecode ﬁle (the portion of the ﬁle that contains the terms underwhich the ﬁle is licensed). 3) We perform an empirical evaluation of our method and three other license identiﬁcation
tools showing that our method outperforms the others inprecision and speed. Finally, we present an empirical studyof approximately 0.8 million source code ﬁles that demonstrates the feasibility of our method and highlights somecharacteristics of the legal landscape of FOSS.

• They report false positives. ohcount and OSLC use
simple regular expressions that might be matched even
if the intention of the licensor is the opposite. For example, we have encountered cases in which these systems report a ﬁle as using the General Public License
because it was found in text such as: “This ﬁle is notlicensed under the GPL”. We presume a legal auditor
will prefer to scan a ﬁle manually than to incorrectly
assume it has a given license.
• FOSSology is slow. In our experience, FOSSology ismore accurate than the other two (we perform a comparison further below that corroborates this fact), but
runs one or two orders of magnitude slower. It requires
also a complex setup, including a running database.

1.1 Related work
Several papers have used metadata from FOSS forges andapplication portals (such as Freshmeat and SourceForge) to
identify the license of FOSS applications. In [2] Capaluppi
et al. used this data to report that, in a sample of 400
applications, 77% used the GPL, 6% the LGPL and 5% the
BSD (no versions were indicated). Other papers have used
this data to analyze the impact of a license in the successand impact of FOSS applications [20, 4]. The authors ofthese papers did not analyzed its source code.
Currently two methods exist for license identiﬁcation. The
ﬁrst is the use of regular expressions to identify the licenseof a ﬁle. Two tools use this method: ohcount, developed by
Ohloh (ohloh.net), a portal of statistics for FOSS projects
recently acquired by SourceForge; and OSLC, the Open
Source License Checker (http://oslc.sourceforge.net/). The

Barahona et al. measured diﬀerent characteristics of the
Debian distributions, but did not include licensing in theirstudy [13].

2.

LICENSING OF SOURCE CODE

The license of a source code ﬁle is typically found in acomment at the very beginning of the ﬁle. We refer to thisregion of the ﬁle as its license statement. A license statement typically contains four sections (not necessarily in thisorder) [5]: 1) a list of copyright owners, 2) a list of authors(if diﬀerent from the copyright owners), 3) the license or licenses that cover the ﬁle (see below for details), and 4) warranty and liability statements. The licenses in the licensing
statement can be of two types:
by-inclusion: the text of the license is embedded in the ﬁle,examples are the BSD and the MIT families of licenses;
by-reference: the license statement indicates where thetext of the license can be found. This can be a ﬁle (inthe case of the family of GPL licenses) or a URL (as the
Apachev2, the MPLv1.1, and the CPL).
In order to understand the characteristics of license statements as they appear in FOSS, we have created a corpus
of source code with approximately 30,000 ﬁles. This included applications such as Linux, Eclipse JDT, OpenBSD,
FreeBSD, and Mozilla. We have analyzed the licensing statements of these ﬁles in a combination of manual and automatic methods, trying to determine the various ways inwhich diﬀerent licenses are present in ﬁles. We also studied
the Open Source Initiative (OSI) approved licenses, and the
corpus of licenses of FOSSology. This exploratory study resulted in the identiﬁcation of challenges of license identiﬁcation, which are summarized in Table 2. They fall into three
categories: 1) Finding the license statement: how manylicenses are there in the ﬁle, where (within the ﬁle) they
are located; 2) Language related: the grammar, spelling,
and wording use in a license statement; and 3) License customization: the terms of the licenses are sometimes alteredby their users. Each of these challenges is described below:
F1. License statements are usually mixed with othertext. Frequently the ﬁrst comments of a ﬁle contain textthat is not part of the licensing statement, such as a description of the ﬁle, or a ChangeLog. One exception is theﬁles in various Mozilla projects, in which well-deﬁned delimiters mark the beginning and end of the licensing statement,
simplifying their identiﬁcation.
F2. Files might reference another ﬁle where the license is located. Frequently a ﬁle will contain a licensing statement such as “For licensing information, see thefile [...]”, “See [...] for licensing information”, “See [...] forlicense details”, etc.. Sometimes the ﬁle is in the same directory, sometimes in a “main”, “root” or “top” directory. The
name of the ﬁle varies: “COPYING”, “LICENSE”, “README”,“copyright.txt”, “AUTHORS”, “COPYRIGHT and LICENSE”,
another source code ﬁle, etc. (For the sake of space, we use[...] to abbreviate sections of text in the examples.)F3. Files might contain multiple licenses. It is notuncommon for ﬁles to contain more than one license. Suchlicenses can apply in a conjunction (the terms of all licenses
apply) or a disjunction (the terms of only one license, atthe choice of the licensor, applies; see disjunctive licensing
pattern in [10]). Determining the number of licenses present
in a ﬁle, and how they interact with each other, is not trivial.
L1. Licensing statements might contain spelling errors. This is not surprising. A very common mistake wefound is words split by whitespace.
L2. A given license is referred in diﬀerent ways.
When a ﬁle is licensed by-reference, usually the creator of
the license documents the recommended way to create thereference (such as the GPL family of licenses, the MPL v1.1
and the EPL v1.0). Unfortunately this is not always thecase. For example, we discovered ﬁles that refer to the GPL
as “This [...] is licensed under the GPL”, “You may use[...] under the GNU public license if you so wish”, “[...] isprovided under the provisions of the GPL”, where [...] isreplaced by “software”, “library”, “program” or the name ofthe product. We also found the variant: “[...] provides thissource code under the GPL License” where [...] is replacedwith the name of the copyright owner, or its author.
L3. Licensors change the spelling/grammar of a license. Sometimes users change the grammar or spelling.
For example, they replace “license” with “licence”, “it would
be useful” with “it will be useful”, “developed by” with “written at”, “dealings in” with “dealings with”, “Redistribution”
with “Redistributions”. The changes are also in punctuation: they add or remove a comma or a semicolon. Grammar changes are particularly signiﬁcant because they might
have the eﬀect of changing the meaning of the license (intended or unintended). It should be left to legal experts todetermine if these changes to a license should be considereda diﬀerent license or not.
C1. Several licenses must be customized when used.
Licenses such as the BSD must be customized to include thename of the copyright owner of the software. For instance,
the warranty statement of the BSD sentence should read
“THIS SOFTWARE IS PROVIDED BY <name> AS IS
AND ANY EXPRESS [...]” with the name of the copyrightowner in place of <name>.
C2. Licensors modify, add or remove conditions towell known licenses. Frequently a well-known license is
modiﬁed to create a new license. Two of the best known examples are the BSD3 license, and the Apache v.1.1. The
BSD3 is derived from the original BSD4, by removing aclause (famously known as the advertisement clause). The
Apache License v1.1 is composed of the BSD3 license plus
four more sentences. The OpenSSL license is a derivativeof the Apache License v1.1. Other licenses derived fromthe BSD licenses are the Zlib/libPng license and the Sleepycat License. In other instances, the modiﬁcations are more
subtle. For example, we found many cases in which the
MIT/X11 license was changed from “Permission to use, copy,
modify, distribute, and sell this software [...]” to “Permission to use, copy, modify and distribute this software [...]”(dropping sell ). Similarly, the BSD condition “Redistributions of source code must retain [...]” is changed to “Redistributions of source code or documentation must retain [...]”(adding or documentation). Some licenses by-reference, suchas the GPL and the MPL allow the licensor to modify thelicense using an addendum (this avoids the need to create
variants of the license). These addenda are usually known
as exceptions (they create exceptions to the conditions of
the license–see Exception Pattern in [10]). These exceptions
usually follow the reference to the license. For example,
parsers generated with Bison contain ﬁles that are licensed
under the GPLv2+ with a special addendum that allows
their use under any license: “As a special exception, when
this file is copied by Bison into a Bison output file, you may
use that output file without restriction.”
C3. Licensors modify licenses for various intents.
By-inclusion licenses are prone to being modiﬁed by its users,
willingly or unwillingly. For example, we have found variants of the BSD endorsement clause such as: “<copyrightowner names> may not be used to endorse [...]”, “Neither

Type.
Finding the license statement

Language related

License customization

Challenge
F1. License statements are usually mixed with other text
F2. Files might reference another ﬁle where the license is locatedF3. Files might contain multiple licenses
L1. Licensing statements contain spelling errors
L2. A given license is referred in diﬀerent ways
L3. Licensors change the spelling/grammar of the license statement
C1. Several licenses must be customized when used
C2. Licensors modify, add or remove conditions to well known licenses
C3. Licensors modify licenses for various intents
Table 2: Major challenges of license identiﬁcation.

the names of the authors may not be used to endorse [...]”,and “The name of the author may not be used to endorse[...]”. Similarly, we found in some cases “without prior written permission” and in others “without specific prior written
permission”. In the MIT/X11 we discovered the words developer, author and copyright owner used interchangeably;
we also found “software and associated documentation files”
replaced with “source file”; and in other ﬁles “The above
copyright notice [...] shall” replaced with “The above copyright notice [...] (including the next paragraph) shall [...]”.

2.1 An algorithm for license identification
Based on our analysis of the corpus of source code ﬁlesand the challenges described before, we developed a license
identiﬁcation algorithm. Its goals are to properly identify
each of the licenses in a ﬁle (license name and version) andto sacriﬁce recall (being able to determine the license of aﬁle) for the sake of precision (making as few mistakes as
possible), and to run eﬃciently.
It works by extracting the license statement from the ﬁle,it then breaks it apart into textual sentences, and proceeds
to ﬁnd a match for each of them individually; the list of thesematched sentences is analyzed to determine if it contains
one or more licenses. This method requires a knowledgebase with three sets of information: 1) ﬁltering keywords K,2) sets of equivalence phrases E, 3) known sentence-token
expressions T , 4) license rules R. These sets were createdduring the study of our corpus and are described below.
Set of ﬁltering keywords K: One of the challenges of license identiﬁcation is discriminating between those sentences that are part of the license statement and thosethat are not relevant (see challenges F1, and F3 above).
Any sentence that does not match at least one keyword is
not expected to contribute to the license of the ﬁle. Keywords can be composed of one or more words. Examples
of ﬁltering keywords are license, conditions, disclaimer,
written permission. We have identiﬁed 82 such keywords.
Set of sets of equivalence phrases E: To deal with language related challenges (L2 and L3) we have created setsof equivalent phrases. Any phrase that is in a set is considered semantically equivalent to any other in the same
set. Examples of these equivalence phases sets are: (atyour option) any later version, any later version or any
greater version; distributable, licensed, released or madeavailable. These sets should be created carefully: replacing one phrase with another in the same equivalence set
should not change the meaning of the sentence. For example, some might argue that “you may” is not always

equivalent to “you can”. This set also includes equivalentpunctuation (such as diﬀerent types of matching quotes“ ”, ‘ ’, ’ ’, ” ”). We have created 12 such sets.
Set of known sentence-token expressions T : We use theterm sentence-token to refer to a sentence of a known
license. A license (both by-inclusion or by-reference) is
a sequence of sentence-tokens. Sentence-tokens are generalized using one or more regular expressions (see challenges C1, C2, and C3). We refer to the pair hsentence-token,
regular expressioni as a sentence-token expression. The
objective of this set is to translate each sentence found in
the licensing statement into a sentence of a known license(a sentence-token). We have identiﬁed 427 sentencetoken expressions. For example, two of the sentencetoken expressions matching variants of the sentence-token“SeeFile” (the license is inside a given ﬁle name) are:SeeFile,^For the licensing terms see the file ([^,;]+)$
SeeFile,^See ([^,;]+) for license$
Set of license rules R: Each license corresponds to a sequence of one or more sentence-tokens (which we calla license rule) plus a set of non-critical sentence tokens (which we call its associate sentence-tokens).
Most by-inclusion licenses require matching two or moreconsecutive sentence-tokens. In contrast, by-reference
licenses usually require only one sentence-token to bematched (indicating the intention to use such license).
We have identiﬁed 126 licenses rules to match 112 licenses. For example, the BSD2 license rule is the sequence of 5 sentence-tokens, hBSDpre, BSDcondSource,
BSDcondBinary, BSDasIs, BSDW arri; in other words,
these 5 sentence-tokens should appear contiguously andin the same order for the ﬁle to be considered licensed under the BSD2. Each rule also contains a list of sentencetokens that usually appear with the license, but are notrequired for the ﬁle to have such license (its associate
sentence-tokens); for example, a ﬁle licensed under a
GPL license will also contain the typical GPL warranty
and liability sentences (as recommended by the Free Software Foundation).
Our algorithm for license identiﬁcation is divided into six
steps, detailed below; they are illustrated in Figure 1.
1. License statement extraction: The comments at theheader of the ﬁle are extracted. If no comment extractor
for the programming language exists, we simply extract
the ﬁrst 1,000 lines of text (the longest license statement
we have found is 700 lines long).

source ﬁleLegend

1. License Stmt. Extraction

Processcomments

Data
KnowledgeBase

2. Text Segmentation
sentences
3. Text normalizationequiv. phrases

normalized sentences
4. Sentence Filteringﬁltering
keywords

sentences relevant to license
5. Sentence Token Matching

known sentencetoken expressions

sentence tokens
6. License Rule Matching

rules

Licenseequiv. phrases

Figure 1: Diagram depicting the main steps of thealgorithm of license identiﬁcation.

(with parameters), each equivalent to their corresponding sentence in S+ . We call this sequence M .
6. License rule matching: ∀r ∈ R, we try to match r
to M . If r is contained in M , we output the license lthat corresponds to r. The sentence-tokens of M thatmatch r and any sentence-token that matches an associated sentence-tokens of r are marked as matched. This
step stops when all sentence-tokens in M are matched or
all rules in R are exhausted (see challenge F3).
Result: The license of the ﬁle is the list of licenses matchedin the previous step. If no license is matched, the ﬁle isconsidered to have an U N KN OW N license. From M
a sequence of sentence-tokens that were not matched isbuilt. We will refer to it as the list of unmatchedsentences.
It is possible that the algorithm identiﬁes a valid license,
and its list of unmatched sentences still contain known andunknown sentence-tokens (in other words, part of the licensestatement of the ﬁle has been identiﬁed, but another parthas not). This poses a risk that the ﬁle might contain one
or more licenses that have not being identiﬁed (see F3), andtherefore it is recommended that these lists be inspectedmanually. The list of unmatched sentences of all ﬁles can be
aggregated and inspected all at once (instead of having toinspect each ﬁle individually).

2.2

ExampleWe illustrate our method with this license statement:/* Copyright (C) 2006 Apple Computer, Inc. All rights reserved.
* Copyright (C) 2006 Michael Emmel mike.emmel@gmail.com* Copyright (C) 2007, 2008 Alp Toker <alp@atoker.com>** Redistribution and use in source and binary forms, with or* without modification, are permitted provided that the following* conditions are met:
* 1. Redistributions of source code must retain the above copyright*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following
3. Equivalent phrase substitution: Each sentence is scanned **disclaimer in the documentation and/or other materials
for occurrences of phrases in E, and if found, replaced*
provided with the distribution.
with a normalized version of the phrase.
** THIS SOFTWARE IS PROVIDED BY APPLE COMPUTER, INC. ‘‘AS IS’’ AND* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
4. Sentence ﬁltering: S is split into two sequences, S+* TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
and S− . A statement is part of S+ if it contains at least* PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL APPLE* COMPUTER, INC. OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
one legal keyword k ∈ K, otherwise it is part of S− . The* INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
relative order of the sentences in S is preserved in S+* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
and S− . If S+ is empty, the ﬁle does not have a license,* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
and we label the source ﬁle N ON E. S+ contains the* BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF* LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
sequence of all sentences that are expected to contribute* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
to the licensing of the ﬁle.
* THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF* SUCH DAMAGE. */2. Text segmentation: Using a text segmentation algorithm, the comments are converted into a sequence ofstatements S. Our implementation is based upon [3]with further modiﬁcation to remove source code comments and special characters used as preﬁxes in each line
(such as # and |).

5. Sentence-token matching: ∀si ∈ S+ , we ﬁnd its corresponding sentence-token ti ∈ T such that the regularexpression corresponding to ti matches si . If no such ti
exists, we use the sentence-token U N KN OW N instead.
Some regular expressions contain variable sections (forinstance, the BSD license requires the name of the copyright owner to be included as part of some of its sentences). Hence each sentence in S+ is equivalent to apair consisting of the sentence-token plus its list of k optional parameters hti , < p1 , ..., pk >i for a value of k ≥ 0.
The result of this step is a sequence of sentence-tokens

This license statement is segmented into 7 sentences. Sentence 6 is modiﬁed to replace “ with <QUOTES> (its preferred equivalent phrase). The number in front of each line
identiﬁes its order in the original licensing statement:
1 Copyright (C) 2006 Apple Computer, Inc. All rights reserved.
2 Copyright (C) 2006 Michael Emmel mike.emmel@gmail.com Copyri[...]
3 Redistribution and use in source and binary forms, with or w[...]
4 Redistributions of source code must retain the above copyrig[...]
5 Redistributions in binary form must reproduce the above copy[...]
6 THIS SOFTWARE IS PROVIDED BY APPLE COMPUTER, INC. <QUOTES>AS[...]
7 IN NO EVENT SHALL APPLE COMPUTER, INC. OR CONTRIBUTORS BE LI[...]

The second sentence is ﬁltered out (it contains no ﬁltering
keywords). The remaining sequence of sentences is translated to the following sequence of sentence-tokens and theirparameters:
1 <AllRights, <Copyright (C) 2006 Apple Computer, Inc.>>
3 <BSDpre, <:>>
4 <BSDcondSource, <above>>
5 <BSDcondBinary, <>>6 <BSDasIs, <APPLE COMPUTER, INC.>>
7 <BSDWarr, <APPLE COMPUTER, INC. OR CONTRIBUTORS>>

Each line is composed of the name of a sentence-token,
followed by a list of instantiated parameters. For example,
line 1 has sentence-token AllRights with a parameter of theleading string “Copyright . . . ”. Line 2 BSDpre is sometimes
followed by a colon. Line 3 BSDcondSource includes the parameter “above” because we have found two variants of thislicense, one using “above copyright notice” and another using only “copyright notice” (this variant is context dependentand cannot be an equivalence phrase). The purpose of theseparameters is to simplify the identiﬁcation of variants of thelicense, and to inform the user of how they are matched, as
sometimes there might be errors in them (e.g. the copyrightowner being diﬀerent in the BSDasIs and BSDWarr sentences, or incorrect) or a rule might have a regular expressionthat is too greedy and match more than the intended text.
In this example, the name of the copyright owner (Apple
Computer, Inc.) is consistent in the three matched rules.
This list matches the BSD2 rule: hBSDpre, BSDcondSource,
BSDcondBinary, BSDasIs, BSDW arri and AllRights ismarked as an associate sentence-token of the BSD2. For
this license statement, no unmatched or unknown sentences
exist. Hence, this ﬁle contains the BSD2 license only.

2.3 Ninka
Using this algorithm, we have developed a license identiﬁcation tool called Ninka. Ninka is open source licensed
under the General Public License version 31 . It consistsof approximately 1,500 lines of Perl, 82 ﬁltering keywords,
12 equivalence phrases, 427 sentence-token expressions, and
126 license rules. It is capable of identifying 112 licenses.

3. EVALUATION
We conducted a comparison experiment to evaluate Ninka
against other existing tools: FOSSology version 1.0.0[12],ohcount version 3.0.0rc and OSLC 3.0. FOSSology identiﬁes licenses using the Binary Symbolic Alignment Matrix(bSAM) pattern matching algorithm, matching the text ﬁlesagainst license templates contained in a database. FOSSology is able to detect a wide variety of speciﬁc licenses (version 1.1 is capable of recognizing 360 diﬀerent ones). Its
main disadvantage is its speed (it takes from few seconds
to few minutes to identify the license of a ﬁle). Ohcount2
is developed by Ohloh, an open source directory. Ohcountuses simple regular expressions to match licenses. OSLC3
ﬁnds exact or partial matches against the licenses stored inits database using an algorithm based on a technique forisolating textual diﬀerences [14].

3.1 Setting
1

Ninka is available at turingmachine.org/ninka.
http://ohcount.sourceforge.net/
3
http://forge.ow2.org/projects/oslcv3/
2

In order to guarantee fairness, the evaluation was performed by one of the authors independently from the maintainer of Ninka. We did not want our tool to be customized(consciously or unconsciously) to the ﬁles in this study andconsequently improve Ninka’s accuracy.
We selected 250 source code ﬁles. First, we randomly
selected 250 applications from Debian 5.0.2. We then randomly selected one ﬁle from each. These 250 ﬁles form theset N . Our goal was get as many diﬀerent types of licenses
and licensing statements as possible. If we consider that
our sample comes from 0.8 million source code ﬁles in Debian 5.0.2, our study will provide us with a 95% conﬁdence
level of an error of ±6.2% that we can correctly identify thelicenses in the source code ﬁles of Debian 5.0.2.
The evaluation was conducted using the following procedure: First, for each source ﬁle in N , its license (or licenses)
were manually identiﬁed. Second, each tool was used to
identify the licenses in each ﬁle. We used the following commands: for FOSSology, fosslic, for ohloh ohcount -l, andfor OSLC java -jar oslc.jar -d.
Each of these tools has a diﬀerent idiosyncrasy in the way
it reports its results. For example, the names used for eachof the licenses might be diﬀerent (this is particularly true
for by-inclusion licenses) hence we inspected the documentation of each tool trying to determine if the license nameit uses corresponds to the same license we found4 . OSLC
displays the percentage of match of a license; we disregard
this number and considered each of the licenses it outputs
as being identiﬁed.
Because ﬁles without a license are fairly common (28.4%
in our sample did not have a license) we assume that, if thetool does not output any license, the tool did not ﬁnd one,and will be considered correct if there is no license in thecorresponding ﬁle. Neither ohcount nor OSLC report when
they ﬁnd an unknown license. For FOSSology we consider
the output “Phrase” as an unknown license. Ninka explicitly
states if there is a license that it cannot recognize. The data
used in this experiment and the results of each tool canbe found at http://turingmachine.org/ninkaData/. We
divided the results of each tool into 3 sets:
C Correct license name and version. The tool correctly identiﬁes each of the licenses in the ﬁle, including
their version (where applicable, i.e. the oﬃcial nameof the license contains a version number, such as theGPL, or the CPL; we consider the BSD4, BSD3, BSD2
diﬀerent versions of the same family). If the ﬁle contains no license, the tool outputs nothing or that there
is NO license in the ﬁle. If the ﬁle contains more than
one license, each of them should be correctly identiﬁed.
I Incorrect. The tool identiﬁes a license but it is incorrect. We also consider it an incorrect identiﬁcation
when the tool outputs multiple licenses and at least
one is incorrect.
U Unknown. The tool explicitly states that it has founda license and it does not recognize it.
These sets are mutually disjoint, and N = C ∪ I ∪ U .
Finally, we calculate the recall and precision of the results
4
There is currently an on-going eﬀort—by several organizations and companies–to standardize licensing data thatcan be easily exchanged. This includes standardizing licenses names. One of the authors of this paper was invited to be part of the committee. For more information see
www.spdx.org.

of each tool as follows:|C||C| + |U |2 ∗ |C|F-measure =2 ∗ |C| + |I| + |U |Recall =P recision =|C||C| + |I|

Intuitively Recall measures how good is the tool at discovering that there is a license in the ﬁle. Because neither
ohcount nor OSLC support reporting unknown licenses theirrecall is 100%. In contrast, Ninka and FOSSology are capable of reporting when a license is found, but is not identiﬁed.
We believe this is an important feature. This information isvaluable to the person doing the license analysis: it is better to know that a ﬁle might contain an unidentiﬁed license,
rather than to think that it contains no license, or worse,
an incorrect one (i.e., if a ﬁle contains license A it is betterto say “I don’t know” than to err “the file has no license” or“the file has license B”).
P recision measures how good is the tool at identifying thecorrect license and version. Comparing each tool simply interms of their precision or recall is insuﬃcient. Therefore weuse the F-measure to provide a more balanced comparisonof the trade-oﬀ between precision and recall.

3.2 Results
Table 3 shows the recall, precision and F-measure of theresults of each of the tools in our study, and the time it tookeach to analyze the set of ﬁles.
Table 3: Results of the evaluation of the tool. Best
result in each category is depicted in bold.
Ninka FOSSo. ohcount
OSLC
|C|
200
137
83
57
|I|
7
112
167
193
|U |
43
1
0
0
Recall 82.3%
99.2% 100.0% 100.0%
P recision 96.6%
55.0%
33.2%
29.5%
F-measure 0.889
0.708
0.498
0.371
Execution Time
22s
923 s
27s
372s

To demonstrate the usefulness of Ninka we performed astudy of the licenses found in the ﬁles of a large open source
distribution (Debian 5.0.2). More speciﬁcally, we have performed an empirical study to answer the following researchquestions:
RQ1: What are the licenses used in FOSS? No empirical study has been performed to identify the licensesof source code ﬁles in a large collection of FOSS applications. Our goal is to identify what licenses are used andhow frequently.
RQ2: When present, what types of errors do licensestatements have? Intuitively we would expect licensestatements to contain errors. Our goal is to attempt toidentify them and explore how the occur.
To address RQ1, we identiﬁed the licenses of the source
ﬁles of Debian 5.0.2 using Ninka and evaluated a) how frequently each license is used; b) if there is a relationship between license and programming languages, and c) if smallerﬁles are more likely not to have a license.
For RQ2 we looked for inconsistencies in licenses. We
concentrated on applications where most of the ﬁles used
the same license, and only a handful had a diﬀerent one. We
then manually analyzed the diﬀerences, checked available
documentation for clariﬁcation, and contacted the authorsof the software to verify our ﬁndings.

4.1 Setting
We downloaded the source code of Debian 5.0.2 from Debian’s oﬃcial repository5 We analyzed all ﬁles written in
Java (.java), C (.c), C++ (.cpp, .cxx, and .cc), Lisp (.el and.jl), Perl (.pm and .pl), and Python (.py); according to [13]these are ﬁve of the six most frequently found programming
languages used in Debian—the other is shell programming.
In Debian 5.0.2 we analyzed 794,622 ﬁles from 11,101 applications (also known as source packages in Debian’s nomenclature). Ninka could not identify a license in 15.9% of ﬁles.
These numbers are consistent with our empirical evaluationof Ninka in Section 3.2. Ninka was able to identify the licenseof all ﬁles in 31.6% of all applications.

4.2
We can make several observations about the results. Ninka
sacriﬁces recall for the sake of precision. It prefers to report
the license as unknown rather than making a mistake. In
fact, of the 6 ﬁles incorrectly identiﬁed by Ninka, in three itcorrectly identiﬁed one of the licenses present in the ﬁle, but
not all of them; and in three it reported the ﬁle as having
no license when it did contain one. Ninka shows the highest
F-measure in these tools. This is reassuring: its low recall(Ninka’s recall is the lowest of the four) is oﬀset by its highprecision.
FOSSology and OSLC are signiﬁcantly slower than therest (30 and 10 times longer than ohcount or Ninka, respectively), and Ninka is slightly faster than ohcount. We believe
this is because Ninka only analyzes the ﬁrst lines of each ﬁle.
In conclusion, our study shows that we have achieved themain goals set for Ninka: it has the highest precision of all
the tools in the study, and it does it eﬃciently (it was thefastest tool in the study).

4. EMPIRICAL STUDY

RQ1: What are the licenses used in FOSS?

Due to space constraints we only present some results.
We invite the reader to download the list of ﬁles and theirlicenses from http://turingmachine.org/ninkaData/.

4.2.1

What licenses are used by software in Debian

Table 4 shows the most commonly found licenses in Debian 5.0.2 ﬁles. The ﬁles with no license statement are themost frequent (NONE). The GPL and LGPL licenses, inall their versions, appear prominently in the list: they arewidely used by many ﬁles, in many diﬀerent applications.
On the other hand, some licenses are used in few applications but these applications contain many ﬁles, e.g. thedisjunctive license “CDDLv1 or GPLv2” it is only used in
two applications (one of them netbeans with 28,523 ﬁles).
In comparison, Table 5 shows the number of applications inwhich a given license is present in at least one of its ﬁle. The
GPLv2+ is the most common in both tables.
With regard to the distribution of licenses per application, the number of licenses used in each application tends
5

ftp://ftp.debian.org/debian/dists/Debian5.0.2/

License
NONE
GPLv2+
LesserGPLv2.1+
CDDLv1orGPLv2
SeeFileApachev2
LibraryGPLv2+
GPLv2
GPLv2 or LGPLv2.1
MPLv1.1
GPLv3+BSD3
MITX11LesserGPLv2+
BoostV1
GPLv2+,LinkException
BSD2
LesserGPLv2.1
LibraryGPLv2
SameAsPerl
GPLnoVersion
MITX11 variant

or

Files
210147147535
42692
37623
31685
25023
23705
18930
18183

Perc.
31.5%
22.1%
6.4%
5.6%
4.7%
3.7%
3.6%
2.8%
2.7%

Aps.
8241
5486
767
2
1252
151
1150
582
30

16767
12394
10237
7783
7348
6029
3877
3496
3283
3275
3047
2521

2.5%
1.9%
1.5%
1.2%
1.1%
0.9%
0.6%
0.5%
0.5%
0.5%
0.5%
0.4%

224
646
601
470
13
11
255
108
100
791
334
57

Table 4: Most common licenses per number of ﬁles
where they occur in Debian 5.0.2. The last column isthe number of applications in which they are found.

to be very small. The median number of diﬀerent licenses
detected per project is 1. 5186 (47.2%) had only one detected license, and 1956 applications (17.6%) had two. The
maximum number of licenses in one application is large; e.g.,
40 diﬀerent licenses in linux, 31 in vnc4, and 26 in texlive.
These numbers could be skewed because Ninka did notdetect the licenses of all the ﬁles. To avoid this potential
problem we studied applications in which Ninka resolved alltheir ﬁles: 3506 (31.8% of the total) (i.e. for each ﬁle init, Ninka either identiﬁed its license or that it contained nolicense). 2183 of these applications used only one license.
Table 6 shows the distribution of licenses in these applications. Another 557 applications used two licenses only.
LicenseNONE
GPLv2+
SeeFileLibraryGPLv2+
SameAsPerl
LesserGPLv2.1+
MITX11
BSD3
GPLv2
LesserGPLv2+
GPLnoVersion
BSD2
publicDomain

Aps.
8241
5486
1252
1150
791
767
601
646
582
470
334
255
244

Prop
74.2%
49.4%
11.3%
10.4%
7.1%
6.9%
5.4%
5.8%
5.2%
4.2%
3.0%
2.3%
2.2%

Table 5: Most common licenses per number of applications in which they appear at least once in Debian
5.0.2.

LicenseGPLv2+SameAsPerl
MITX11
BSD3‘ SeeFile
Apachev2
LesserGPLv2.1+
GPLv2
BSD2
LibraryGPLv2+

Aps.
1265
369
86
83
63
55
44
38
24
16

Perc.
57.9%
16.9%
3.9%
3.8%
2.9%
2.5%
2.0%
1.7%
1.1%
0.7%

Table 6: Most common licenses used by applications
that used only one license, and every ﬁle was resolved (it either had no license or it was known)in Debian 5.0.2. There were 3506 such applications(31.8% of all applications).

4.2.2

Do different programming languages use different licenses?

Table 7 shows the distribution of licenses grouped by programming language (based upon the extension of the ﬁle).
This table shows the results for Java, C, C++, and Perl.
With respect to Java, as it can be observed, two applications (netbeans and glassfish) contribute all the ﬁles thatappear with the “CDDLv1 or GPLv2” (Java’s most used license). It is also signiﬁcant that other licenses appear before
the GPLv2+.
C programs, on the other hand, are more likely to use
the Free Software Foundation licenses. C++ programs were
found to frequently use the triple license GPLv2, LGPLv2.1
or MPLv1.1, promoted by the Mozilla Foundation; the large
number of ﬁles that compose Boost pushes the number ofﬁles under its license into this list.
Perl is peculiar because it uses an indirect license: “Same
License as Perl”. This is the default license statement included in the skeletons of Perl modules automatically created by Perl, and this is likely the reason behind its frequency6 . The table also shows Perl ﬁles are more likely not
to have a license (67%, more than twice of any of the otherthree languages).

4.2.3

Does size matter?

During the development of Ninka we analyzed various FOSS
applications to test the eﬃcacy of our tool. One of theseapplications had a signiﬁcant proportion of ﬁles without alicense. We contacted its main developer, informing him of
this. He replied that he did not think it was necessary toplace a license on very small ﬁles (usually test ﬁles).
Are smaller ﬁles more likely not to have a license? The
median size of ﬁles in Debian 5.0.2 is 4633 [2041,11863] bytes;
the median size of ﬁles without a license is 2137 [708,6857]
bytes, while the ones with a license is 5488 [2868,13217].
Considering that the median size of the license statement ofa ﬁle is 1005 bytes, the median size of ﬁles with a license
was still more than 2 kilobytes longer.A Mann-Whitney test
conﬁrms that these diﬀerences are signiﬁcant (p < 0.0001).
6This type of license makes it easy to relicense these modules
if and when Perl changes it license[10]. Perl is expected
to change its license to the Artistic v2 when version 6 isreleased; it is currently using the disjunctive license between
the Artistic v1 and the GPLv1+.

License

Files
Perc.
Java (.java)
CDDLv1 or GPLv2
37562 25.43%
NONE
25371 17.17%
LesserGPLv2.1+
22834 15.46%
Apachev221535 14.58%
GPLv2+
10679
7.23%
GPLv2+,LinkException
5888
3.99%
c (.c)
NONE
85261 32.25%
GPLv2+
66654 25.21%
LesserGPLv2.1+
14981
5.67%
SeeFile14926
5.65%
LibraryGPLv2+
12440
4.70%
GPLv3+
10191
3.85%
C++ (.cpp, .cxx, .cc, and c++)GPLv2+
47528 31.63%
NONE
36661 24.40%
GPLv2 or LGPLv2.1 or 12169
8.10%
MPLv1.1
SeeFile9704
6.46%
LibraryGPLv2+
8854
5.89%
6554
4.36%
boostV1
Perl (.pm and .pl)
NONE
18227 66.73%
3079 11.27%
GPLv2+SameAsPerl
2651
9.71%
LibraryGPLv2+
681
2.49%
SeeFile556
2.04%
GPLv2 or LGPLv2.1 or
293
1.07%
MPLv1.1

Aps.
2
344
61
100
72
8
3726
2718
513
357
795
133
999
1171
15
95
189
11
2200
383
584
233
180
9

Table 7: Most frequent licenses used by each programming language in Debian 5.0.2
However, we did not ﬁnd a correlation between the size ofthe ﬁle and the existence of a license in it (ρ = 0.1347).

4.3 RQ2: When present, what types of errors
do license statements have?
During the development and testing of Ninka we observed
several potential problems in the licensing of various applications that we analyzed. These are summarized below:
Application #1. Files without a license We contacted
the author of this application informing him that one of
its ﬁles did not contain a license (the rest contained the
GPLv3+). He acknowledged that this ﬁle should not havebeen distributed with the software and removed it.
Application #2. Cutting & pasting the wrong license statement In this application we discovered a license inconsistency. The application, according to its web
site, was licensed under the GPLv2. 169 of its ﬁles were licensed under the GPLv2+, 3 under the GPLv3+, one in the
public domain, and 26 didn’t have a license. The GPLv3+
ﬁles created a licensing conﬂict: a ﬁle licensed under the
GPLv3+ cannot be linked into a system under the GPLv2.
We emailed its mailing list asking for a clariﬁcation. The
project leader quickly replied: “Those files did not have a
copyright header and no license at all, I’ve copied a license
header into them, but did not see that it was the wrong one,sorry.” He also clariﬁed that ﬁles without a license statement are licensed under the GPLv2+.

Application #3. Inconsistent license clauses This application is licensed under an MIT-style license. 3 ﬁles outof 37 contained diﬀerent liability and warranty clauses than
the rest. When we contacted the author of the application,
he acknowledged that this was a problem and would be ﬁxed
in the next release.
Application #4. Incorrect name of the license According to the Web site of this application, it is licensed under the Lesser GPL v2.1. Its README.txt ﬁle asserts it islicensed under the Library GPLv2+. Ninka identiﬁed 8 ﬁlesunder the Lesser GPLv2+, but this license does not exist.
The successor of the Library GPL version 2 is the Lesser
GPL version 2.1 (there was never a version 2.0 of this license). The rest of the ﬁles correctly referred to the Library
GPLv2+. When we contacted the author of the application, he acknowledged the problem, claiming the licenses of
all ﬁles will be changed to Lesser GPLv 2.1.
Application #5. License statements can only beedited by their copyright owners This application included a ﬁle under the Lesser GPLv2+ (as mentioned above,
this version of the license does not exist). When we contacted the project leader he informed us that this was aknown problem, and there was a bug report already ﬁlled
about it. Unfortunately this ﬁle had come from a diﬀerent
application, and hence because they were not the copyrightowner they could not change its license statement; instead
they were trying to ﬁnd its copyright owner to perform suchchangeIn summary, these issues highlight the need for license
maintenance features in software development environmentsthat support:• Editing of the license statements.
• Verifying the validity of the license statements.
• Summarizing licenses in source code ﬁles.
• Tracking of copyright owners.

5.

THREATS TO VALIDITY

With respect to our evaluation of Ninka and the othertools, we addressed construction validity by randomly choosing ﬁles from many diﬀerent applications. We addressedconclusion validity by performing a statistical test that indicates the level of conﬁdence of the results.
Our study of licensing in FOSS is exploratory and its mainthreat to construction validity is how reliable our license detection is. Our empirical evaluation of Ninka has been design to quantify it. In this evaluation Ninka had a 96.6%
precision for ﬁles in which it identiﬁed a license, hence weare conﬁdent of the quality of our analysis of the complete
Debian distributions. There is, however, the risk that theunknown licences might change some of the results. Thispotential impact would be small because only 15.9% of ﬁlesin Debian 5.0.2 contained a license that was not identiﬁed.
We inspected many of these ﬁles and, in most cases, they
contained variants of other known licenses that were not recognizable by Ninka. Furthermore, we restricted some of ouranalysis to applications for which Ninka identiﬁed a license(or lack of one) in each of their ﬁles. With respect to external validity, we believe that our results are representative to
FOSS in general because a) we analyzed a very large number
of ﬁles and applications, and b) Debian serves as a proxy ofactive (or at least used) FOSS applications.
We have also contacted developers (where applicable) tomake sure that our interpretations were not erroneous.
[6] M. Di Penta, D. M. German, and G. Antoniol.
With respect to reliability validity, our study can be repliIdentifying Licensing of Jar Archives using acated: ﬁrst, we have used a well deﬁned collection of source
Code-Search Approach. In International Working
code ﬁles that is available to anybody (Debian distribuConference on Mining Software Repositories (MSR
tions); second, we are making Ninka available under an open
2010), pages 151–160, May 2010.
source license; and third, the data and results or our experi[7] M. Di Penta, D. M. German, Y.-G. Guéhéneuc, andments are available for others to study at http://turingmachine.
G. Antoniol. An exploratory study of the evolution oforg/ninkaData/.
software licensing. In Proc. of the 32rd Int. Conf. on
Software Engineering (ICSE 2010), pages 145–154,
2010.
6. CONCLUSIONS AND FUTURE WORK
[8]
Free
Software Foundation. Frequently Asked
In this paper we have presented a method of license idenQuestions about the GNU Licenses.
tiﬁcation for source code ﬁles. This method is based on
http://www.fsf.org/licensing/licenses/gpl-faq.html.
matching each of the sentences of the license statement ofAccessedFeb. 2009.
the ﬁle to the sentences of known licenses. Based on this[9] D. M. German, M. Di Penta, and J. Davis.
method we implemented Ninka. We empirically evaluatedUnderstanding and auditing the licensing of open
Ninka and other similar tools and found that Ninka is bettersource software distributions. In 18th Internationaland faster at identifying the license name and version thanConference on Program Comprehension (ICPC’2010),
these tools, at the cost of lower recall.
May 2010.
We have performed an empirical study of a large collec[10] D. M. German and A. E. Hassan. License integration
tion of free and open source applications. We discovered, forpatterns: Addressing license mismatches inexample, that the GPLv2+ is the most commonly used licomponent-based development. In Proc. 31st Int.
cense in terms of number of ﬁles and number of applications
Conf. on Soft. Eng., ICSE, pages 188–198, 2009.
that use it.
We also discovered that licensing statements are prone[11] D. M. German, M. D. Penta, Y. Gueheneuc, andto errors. The integration of license veriﬁcation tools into
G. Antoniol. Code siblings: Technical and legal
development environments will alleviate this problem.
implications of copying code between applications. In
With respect to future work, the identiﬁcation of licenses
Proceedings of the International Working Conferenceof ﬁles is only one step in licensing analysis of components.
in Mining Software Repositories, pages 81–90, 2009.
It is also necessary to analyze the interactions between dif[12] R. Gobeille. The FOSSology project. In MSR ’08:
ferent ﬁles of a system to determine the resulting license ofProceedings of the 2008 International Conference on
a component, and, at a higher level, how the interaction of
Mining Software Repositories, pages 47–50, 2008.
diﬀerent components aﬀect the overall license of a system[13] J. M. Gonzalez-Barahona, G. Robles, M. Michlmayr,that uses them.
J. J. Amor, and D. M. German. Macro-level software
evolution: a case study of a large software
Acknowledgementscompilation. Journal of Empirical Software
Engineering, 14(3):262–285, 2009 2009.
We would like the thank the reviewers of an early draft of[14] P. Heckel. A technique for isolating diﬀerences
this paper. This work has been supported by the Invitabetween ﬁles. Commun. ACM, 21(4):264–268, 1978.
tion Fellowship Program of the Japan Society for Promotion[15] J. Li, R. Conradi, C. Bunse, M. Torchiano,and Science, the Grant-in-Aid for Scientiﬁc Research (A)O. Slyngstad, and M. Morisio. Development with
(No.21240002), the Stage Project, the Development of Next
oﬀ-the-shelf components: 10 facts. Software, IEEE,
Generation IT Infrastructure of Mext Japan, and the Na26(2):80–87, 2009.
tional Science and Engineering Research Council of Canada.
[16] Nokia Corp. About PySide.
http://www.pyside.org/about/, 2009. Acc. Sept. 2009.
7. REFERENCES[17] L. Rosen. Open Source Licensing: Software Freedom[1] T. A. Alspaugh, H. U. Asuncion, and W. Scacchi.
and Intellectual Property Law. Prentice Hall, 2004.
Analyzing software licenses in open architecture
software systems. In FLOSS ’09: Proc. Workshop on[18] C. Ruﬃn and C. Ebert. Using open source software in
Emerging Trends in Free/Libre/Open Source Software
product development: a primer. IEEE Software,
Research and Development, pages 54–57, 2009.
21(1):82–86, 2004.
[2] A. Capiluppi, P. Lago, and M. Morisio. Characteristics[19] W. Scacchi. Free/open source software development.
of open source projects. Software Maintenance andIn ESEC-FSE ’07: Proceedings of the the 6th joint
Reengineering, European Conference on, 0:317, 2003.
meeting of the European Software Engineering
Conference and the ACM SIGSOFT Symposium on[3] P. Claugh. A Perl program for sentence splitting using
The Foundations of Software Engineering, pages
rules. http://ir.shef.ac.uk/cloughie/software.html,
459–468, New York, NY, USA, 2007. ACM.
April 2001.
[20] C. Subramaniam, R. Sen, and M. L. Nelson.
[4] J. Colazo and Y. Fang. Impact of license choice on
Determinants of open source software project success:open source software development activity. J. Am.
A longitudinal study. Decision Support Systems,
Soc. Inf. Sci. Technol., 60(5):997–1011, 2009.
46(2):576–585, 2009.
[5] M. Di Penta and D. M. German. Who are source code[21] T. Tuunanen, J. Koskinen, and T. Kärkkäinen.
contributors and how do they change? In ”Proc. 16th
Automated software license analysis. AutomatedWorking Conference on Reverse Engineering
Software Engg., 16(3-4):455–490, 2009.
WCRE’09”, pages 11–20, Oct 2009.