Noname manuscript No.
(will be inserted by the editor)

Analysis of License Inconsistency in Large
Collections of Open Source Projects
Yuhao Wu · Yuki Manabe · Tetsuya
Kanda · Daniel M. German · Katsuro
Inoue

Received: date / Accepted: date

Abstract Free and open source software (FOSS) plays an important role insource code reuse practice. They usually come with one or more software licenses written in the header part of source files, stating the requirements andconditions which should be followed when been reused. Removing or modifying the license statement by re-distributors will result in the inconsistency oflicense with its ancestor, and may potentially cause license infringement. In
this paper, we describe and categorize different types of license inconsistencies and propose a method to detect them. Then we applied this method to
Debian 7.5 and a collection of 10,514 Java projects on GitHub and present
the license inconsistency cases found in these systems. With a manual analysis, we summarized various reasons behind these license inconsistency cases,
some of which imply potential license infringement and require attention fromthe developers. This analysis also exposes the difficulty to discover license infringements, highlighting the usefulness of finding and maintaining source code
provenance.
Keywords Software license · Code clone · License inconsistency
Yuhao Wu (B) · Katsuro Inoue
Graduate School of Information Science and Technology, Osaka University, Japan
E-mail: wuyuhao@ist.osaka-u.ac.jp
Katsuro Inoue
E-mail: inoue@ist.osaka-u.ac.jp
Yuki Manabe
Graduate school of Science and Technology, Kumamoto University, Japan
E-mail: y-manabe@cs.kumamoto-u.ac.jp
Tetsuya Kanda
Graduate School of Information Science, Nara Institute of Science and Technology, Japan
E-mail: t-kanda@is.naist.jp
Daniel M. German
Department of Computer Science, University of Victoria, Canada
E-mail: dmg@uvic.ca

2

Yuhao Wu et al.

1 Introduction
Software reuse has long been advocated as a good practice to reduce development time and increase product quality (McIlroy et al., 1968; Standish, 1984;
Boehm, 1987). The popularity of Free and Open Source Software (FOSS) has
made software reuse a common practice. FOSS software can be defined assoftware that is licensed under a free or open source license. In a nutshell,a free and open source license allows the software to be freely used (as in
freedom), modified, and redistributed (in modified or unmodified form) byanyone, as long as the conditions of its license are satisfied. The Open Source
Initiative (OSI) has defined a set of characteristics that an open source license
should have, and published a list of approved Open Source licenses1 . The Free
Software Foundation2 defines a set of similar conditions that a license should
satisfy in order to be considered a free software license.
Developers who reuse FOSS should pay special attention to the licenseunder which a source file is made available, and make sure that they satisfy
the conditions and limitations of its license. Otherwise they risk losing theright to reuse the software. Typically, the license of a file is located in the top
part of the file. We will refer to this area of the file as the license statement of
the file.
The license of a file can only be changed by its copyright owner. In somespecial cases, the license terms allow others to change the license of the file.
Otherwise, if the license is changed there is the potential for copyright infringement. For example in a case of XimpleWare Corp v. Versata Software Inc. et
al3 , Versata was sued for including GPL-licensed code into one of its products
but removing the copyright and use notices required by GPL. This case wassettled out of court in favor of XimpleWare.
For the purpose of this paper, we are interested in the situation where a
copy of a file has a different license than the original file. If the new license has
not been approved by the copyright owner we are confronted with a potential
license violation. However, in many cases it is not clear whether the change inlicense has been approved by the copyright owner. For example, the copyrightowner might have approved, via direct communication, a change in license.
Under this scenario, the copy has a different license than the original, but it
is not a license violation. For this reason, when a copy of a file has a different
license than the original, we say that there is a license inconsistency between
the licenses of the two files. Some license inconsistency cases might turn out
to be license violations.
Anybody who wants to reuse FOSS software should be concerned thatthe software being reused is properly licensed. If the reused software contains
files that have been copied from other sources, and these files have license
inconsistencies, then it is important to resolve these inconsistencies. Otherwise1

http://opensource.org
http://www.fsf.org
3 http://www.ifross.org/en/artikel/versata-saga-settled-prejudice-1
2

Analysis of License Inconsistency in Large Collections of Open Source Projects

3

the reuser of these files might be involved in legal disputes with the original
copyright owner.
Previous study by Li et al. (2009) shows that 36% of the developers whoreused the OSS components changed the source code, but they did not pointout whether these changes involve the license statement. In our study, we
focus on the license statement changes and the license inconsistency introduced
between the different copies of the files.
To the best of our knowledge, no research has been done to discover andstudy the characteristics of license inconsistency in software reuse. For example, how many types of license inconsistencies are there? Do they exist inopen source projects? If so, what is the proportion of each type? What caused
license inconsistency?
Based on these questions, we set our research question as follows:– RQ1 How can we categorize a license inconsistency?
– RQ2 Do license inconsistencies exist in open source projects?
– RQ3 What is the proportion of each type of license inconsistency?
– RQ4 What caused license inconsistencies? Are they legally safe?
The contributions of this paper are:1) We describe and categorize different types of license inconsistencies.
2) Based on existing tools for license identification and clone detection, we
have developed a method to detect license inconsistencies. We perform
an empirical study with this method using two sets of FOSS projects.
This study reveals that license inconsistencies exist. It also proved thefeasibility of our method.
3) We perform a manual analysis of some license inconsistency cases to understand the reasons behind them. We then summarized these reasons
into 4 categories. Among them, two categories indicate license problems
and require developers’ attention.
This paper is organized as follows. Section 2 describes background on FOSS
licenses and license inconsistencies. Section 3 introduces our research method.
Our empirical study that uses this method is described in Section 4, followed
by Section 5 with a discussion of the results. Section 6 describes threats tovalidity. After a description of related work in Section 7, Section 8 concludes
this paper and points out the future direction.

2 License Inconsistencies
A software license is a permission to reproduce, modify and redistribute a
software, usually granted under certain conditions. An open source license isa software license that follows Open Source Definition4 and is approved by
the Open Source Initiative. As of today, only 70 licenses have been approved4

http://opensource.org/definition

4

Yuhao Wu et al.

as Open Source License. However Black Duck Software claims that the Black
Duck Knowledge Base includes over 2200 licenses5 . Some licenses have beengrouped under the same name as different versions. For example, the General
Public License (GPL) has versions 1, 2 and 3. Each version is, in legal terms,
a totally independent license.
To reuse OSS source code files, developers must identify the license underwhich the files are made available, understand their terms, and satisfy theirrequirements. This is not a trivial task because some open source licenses do
not usually allow easy integration with software under another license (seeGerman and Hassan (2009) for a detailed discussion on this issue). For example, software under the Apache Public License version 2 (APL-2.0)6 canbe reused and integrated into software licensed under the GPL-3.0. On theother hand, software under the GPL-2.0 cannot be combined with software
under the GPL-3.0 (however software under the GPL-2.0+, that is version 2or any later version of the GPL, can be). Therefore, developers must know thelicenses of files they reuse in order to avoid license violations.
It is also known that frequently, the source code files in an application are
under different licenses (Manabe et al., 2010, 2014). In addition, copies of thesame file might have different licenses because the copyright owner has licensed
the file accordingly. For example, the copyright owner has decided to change
the license from one version of the software to the other (even if the software
did not have any changes).
Confusion can arise when a developer wishing to reuse a given file findsthat two or more copies of it have different licenses. Let us assume that adeveloper wants to reuse two copies of the same file (not necessarily identical,
due to their own evolution). The first copy, copy A, has license LA , and copy B
has license LB . If the files both came directly from the copyright owner, thenit can be assumed that both files have valid licenses; but if the files came fromthird parties, one has to question if such parties have modified the licenses
without the approval of the copyright owner (resulting in a potential license
violation).
Usually, the license of an open source file is indicated in its license statement, found in the first comments of each source file. Here is an example ofa license statement taken from getopt.c file in GNU library, which states thatthe file is under the GPL-3.0+:/* Getopt for GNU.
* NOTE: getopt is part of the C library, so if you don’t* know what "Keep this file name-space clean" means, talk* to drepper@gnu.org before changing it!
* Copyright (C) 1987-1996, 1998-2004, 2006, 2008-2012 Free
* Software Foundation, Inc.
* This file is part of the GNU C Library.
** This program is free software: you can redistribute it5

http://www.blackducksoftware.com/products/knowledgebase
In this paper we will use the abbreviations of FOSS licenses of the Software Package
Data Exchange (SPDX), found at http://spdx.org/licenses/.
6

Analysis of License Inconsistency in Large Collections of Open Source Projects

5* and/or modify it under the terms of the GNU General Public* License as published by the Free Software Foundation;* either version 3 of the License, or (at your option) any* later version.
** This program is distributed in the hope that it will be* useful, but WITHOUT ANY WARRANTY; without even the implied* warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR* PURPOSE. See the GNU General Public License for more
* details.
** You should have received a copy of the GNU General Public* License along with this program.
* If not, see <http://www.gnu.org/licenses/>.
*/

Generally, the license statement of a source file can only be modified by its
copyright owner. Reusers shall never modify the license statement unless it isunder the permission of the copyright owner or allowed by the terms of thelicense.7 Otherwise, the reusers may incur a license violation.
In order to identify potential license violations, the first step is to identify license inconsistencies between files of different projects. In the following
subsections, we introduce our definition of license inconsistency and give an
example of a license inconsistency we have found in Debian 7.5. Finally wecategorize them based on our analysis of our two target datasets.

2.1 Definition
For the purpose of this research, a license inconsistency refers to the situation
when two source files that have evolved from the same original code havelicense statements which include different licenses.

2.2 Example
In the Debian 7.5 Linux distribution, two packages, dpkg and anubis, contain a file named obstack.c. Except for the license statement, these two files
are identical. For this reason we assume that these two files share the same
provenance.
From package dpkg, the license of this file is GPL-2.0+:[...]
This program is free software; you can redistribute it
and/or modify it under the terms of the GNU General Public
License as published by the Free Software Foundation; either
7 Some licenses, such as the Mozilla tri-license (which allowed the reuse of the file undereither the MPL-1.0, the GPL-2.0+ or the LGPL-2.1) allow the user to remove one or two
licenses. Similarly, files are frequently licensed with the ability to use newer versions of thelicense (corresponding to the + sign in the SPDX abbreviations of license names, such as
GPL-2.0+).

6

Yuhao Wu et al.

version 2, or (at your option) any later version.
[...]

While from package anubis the license is GPL-3.0+:[...]
This program is free software: you can redistribute it
and/or modify it under the terms of the GNU General Public
License as published by the Free Software Foundation; either
version 3 of the License, or (at your option) any
later version.
[...]

As we can see, the licenses of the two files are different: GPL-2.0+ andGPL-3.0+. The first file can be combined with software under the GPL-2.0,
but the second cannot (the GPL-2.0 is incompatible with the GPL-3.0). Basedon our definition, this is a case of license inconsistency. Without tracing thehistory of each of these files, it is not possible to determine if both licenses
are valid (i.e. if the copyright owner of made the file available under bothlicenses). The following are three of many potential scenarios that lead to thisinconsistency:
1) The first file is the original one and was copied to the second project,
where the license was changed from GPL-2.0+ to GPL-3.0+. In this case,because the original license allows to use newer versions of the license, thechange can be done by anybody, and it is not a potential license violation.
2) The second file is the original one and was copied to the first project.
The license version was changed from GPL-3.0+ to GPL-2.0+ in thefirst project. This could be a potential violation if the change was madewithout the approval of the copyright owner of the file.
3) Both of the files are copied from the same third-party project (who created the file). Each project made the copy at different times, one before,
and one after the license of the file was changed by the original project
copyright owner. In this case, there is no potential license violation.
To determine which one is the actual reason of the inconsistency, we needto examine the repository history of these two projects and try to determine
the true origin and if possible, identify the rational for this modification oflicense. This topic will be discussed in Section 4.1.1.

2.3 Categorization
Based on the analysis of our two datasets, we observed 5 types of license
evolution. They are either executed by the original author or reuser:
1) License Addition: The source file was without a license, and a license
is added in a later time.
2) License Removal: The source file was under a certain license, and thelicense is removed in a later time.

Analysis of License Inconsistency in Large Collections of Open Source Projects

73) License Upgrade: The source file was under a certain version of the
GPL license—a license that allows an upgrade (such as the GPL-2.0+
and GPL-3.0+)—and it is upgraded to a newer version of the license.
4) License Downgrade: The source file was under a certain version of alicense, and it is downgraded to an older version of the same license.
5) License Change: The source file was under a certain license, and it
is changed to another license (except for License Upgrade and License
Downgrade).
Note that, in the context of this paper in the case of license upgrade anddowngrade, we only consider the GPL license family. This is because currently
only the GPL licenses have a “or later” option (e.g. GPL-2.0+, LGPL-2.1+)
which allows the reuser to choose a later version of GPL when reusing thesoftware (i.e. to upgrade to a newer version). Although some other licenses,
such as the Apache license, may have different versions, reusers are not allowed
to choose an arbitrary version of the license. Thus it is reasonable to treat
various versions of these licenses as completely different licenses. For suchreason we treat the license evolution between different versions of licenses
other than GPL as license change in this paper.
License inconsistencies are naturally caused by changes in the license of
the files. We use the following types to denote different types of license inconsistencies between two files:
LAR License Addition or Removal. One of the two files contains a license
while the other file contains no license. This type of license inconsistency isusually caused by either a license addition or a license removal. We consider
both addition or removal in this inconsistency because until the provenanceanalysis is done, we do not know if the license was added or removed by
the third party.
LUD License Upgrade or Downgrade. One of the two files contains a certain
version of a license while the other file contains a different version of thesame license. This type of license inconsistency is caused by either upgrading or downgrading the license of the file.
LC License Change. Two files contain different licenses (excluding LUD cases).
This type of license inconsistency is usually caused because the license of
the file was changed.

3 Method to Detect License Inconsistencies
In our previous work (Wu et al., 2015), we have proposed a method thatcan efficiently detect license inconsistencies. However, a major issue with thatmethod is that it only considers license inconsistencies among files that havethe same file name (in order to achieve a fast performance). Thus if files arerenamed during the process of copy-and-own reuse, a license inconsistency
will not be detected. To solve this problem and make our result cover more8

Yuhao Wu et al.

license inconsistency cases, we propose a new method in this paper. A detailed
comparison of these two methods will be discussed in Section 5.1.
In our new approach, we focus on detecting license inconsistencies among
file clones. In the scenario of source code reuse where source files are imported
from an upstream project, the contents of reused source files remain almost thesame, sometimes with small changes (such as modifying comments, renaming
identifiers etc.) (Sasaki et al., 2010).
To decide whether source files are copies of each other—or in other words
whether they share the same provenance—we compare their normalized token
sequences (Roy et al., 2009). Normalized token sequences are generated fromthe source file by removing the comments, redundant white spaces, new lines,
carriage returns and then converting identifiers to normalized tokens. If two
files have the same normalized token sequences, then it is likely that they are
copies of each other and we call them file clones, which are actually Type-2
code clones (Roy et al., 2009; Sasaki et al., 2010). We use CCFinder (Kamiya
et al., 2002), a code clone detection tool, to analyze and determine if files
are file clones. CCFinder will generate a pre-process file which contains thenormalized token sequences of the source file. For those file clones with thesame normalized token sequences, we assume that they come from the same
origin, and then gather them into the same file group. Files in the same filegroup might have different file names but similar program statements, possiblywith different comments including license statement.
Once that we group these similar files, we identify the license of the files
in each group. In our approach we used Ninka to detect the license of source
files, since Ninka is reported to have the highest precision of all the license
detection tools including FOSSology, ohcount and OSLC in the research by
German et al. (2010b). Ninka is a sentence-based license detection tool which
can identify 110 different licenses with 93% accuracy, and it can handle morethan 600 files per minute. There are two special results from Ninka: one is
UNKNOWN, which represents that Ninka has found a license but does notrecognize it. The other one is None, which states that the source file has nolicense.
We then compare the licenses of each file in the license list of each group.
If all the files have no license, or all of them have the same license, then there
is no license inconsistency. Otherwise, the group is likely to contain one ormore types of license inconsistencies. And then, based on the relation between
licenses, our approach identifies the type of license inconsistency. Note thata group may have multiple types of license inconsistencies. For example, if agroup consists of a file under GPL-2.0+, a file under GPL-3.0+ and anotherfile under Apache-2.0, then the group has two types of license inconsistencies:
LUD between GPL-2.0+ and GPL-3.0+, LC between GPL-2.0+/GPL-3.0+ andApache-2.0. For such reason, we calculate License Inconsistency Metrics foreach of these groups, from which we can measure what type of license inconsistency and how many of each type exist in the groups.

Analysis of License Inconsistency in Large Collections of Open Source Projects

9

Table 1 Strategies to decide whether a certain type of license inconsistency exists in agroup.
Inconsistency Type

Strategy

LAR
LUD
LC

#None > 0 and #Lic > 0#GPL ≥ 2#GPL ≤ 1 and #Lic ≥ 2

3.1 License Inconsistency Metrics
The following 5 metrics are introduced to help measure the license inconsistencies for a file group:#File: Number of files in this group.
#Lic: Number of different licenses in this group. If there are two or morelicenses found, then it is likely that there is a license inconsistency. If nolicense, or only one license is found, then all the files are either without
license, or they have the same license.
#Unknown: Number of files with an unknown license in this group. For
our purposes we consider all the files with unknown licenses as if they
have the same license (this might under-estimate the number of license
inconsistencies).
#None: Number of files without any license in this group. If #None > 0
and #Lic > 0 then it is possible that at least one file in the group had its
license added or removed (i.e. LAR inconsistency).
#GPL: Number of licenses in GPL family (any version of the LGPL, GPL
or AGPL licenses). This metric allows us to identify LUD in the GPL family.
These metrics are calculated for each file group based on their license lists.
The strategies shown in Table 1 enable us to decide whether a certain type of
license inconsistency exists in this group.
Specifically, if we query the metrics result for each group based on theconditions of #None > 0 and #Lic > 0, which mean respectively that there
is one or more files with no license(s), and that there is one or more files witha license, we get what we define as LAR (a license addition or removal); if wequery for those whose #GPL ≥ 2, a condition which means that there are two
or more different licenses in the GPL family (such as GPL-2.0+ and GPL3.0+), we get LUD (a license upgrade or downgrade); and if we query for those
based on #GPL ≤ 1 and #Lic ≥ 2, which mean respectively that there are
more than two licenses in this group and that there is no more than one GPL
license (excluding LUD cases), we get LC (a license change) where one license
is changed to another one.

3.2 Method of Detecting License Inconsistencies
As a summary, our method is divided into 3 steps:

10

Yuhao Wu et al.

1. Create groups of file clones: For all the source files in the target
projects, we apply CCFinder to extract the normalized token sequencesof each file. Note that, although CCFinder itself is a clone detection tool,
we do not utilize the full functionality of CCFinder and we only use it
to generate the normalized token sequences of source files. By computing
and categorizing the hash value of these token sequences, we then create agroup for files that have the same normalized token sequences. Each groupcontains at least two different files; i.e., a unique file is not contained inany group.
2. Identify licenses for files in each group: For each group of file clones,
Ninka is used to identify the license(s) of each file. The result is a list of
licenses for each file group.
3. Report groups that contain a license inconsistency and calculate the inconsistency metrics: We compare the license list of each filegroup. File groups are reported to have license inconsistencies unless all thelicenses on the list are exactly the same. The result is a list of file groups
that contain one or more types of license inconsistencies.

3.3 Example
We illustrate our method with a project shown in Figure 1. This project consists of 4 packages. The source code of foo.c file in Pkg2 is exactly the samewith the one in Pkg1, but the license statement is changed from GPL-2.0+ to
GPL-3.0+; The source code of foo.c in Pkg3 is different from the one in Pkg1,
i.e. they happen to have the same file name. It is reused in Pkg4 with its namechanged to foo100.c and license statement removed.
1. Create groups of file clones: In this step, we use CCFinder to generate
token files for each source file. Since the foo.c file from Pkg1 and Pkg2 have

Proj

Project Root

Pkg2

Pkg1

Packages

Pkg3

Pkg4

Files

foo.c

bar.cppfoo.c

bar.java

foo.c

foo100.c

LicenseGPL-2.0+

LGPL

GPL-3.0+

ApacheBSD-3-Clause

NONE

Fig. 1 Hierarchy of a project and the license of each source file. Note that the foo.c filein Pkg1 was imported to Pkg2 with the license changed to GPL-3.0+; The foo.c in Pkg3
contains totally different source code than the one in Pkg1, and was imported to Pkg4 with
its name changed to foo100.c and license removed.

Analysis of License Inconsistency in Large Collections of Open Source Projects

Root

Directory

Group2

Group1

Directory

Files

11

foo Pkg1.c foo Pkg2.c foo Pkg3.c foo100 Pkg4.c

Fig. 2 Hierarchy of the grouped files.
Table 2 License list of the selected files from the example project.
File nameGroupID

Package name

License

foo.c
foo.c
foo.c
foo100.c

1
1
2
2

Pkg1
Pkg2
Pkg3
Pkg4

GPL-2.0+
GPL-3.0+
BSD-3-Clause
NONE

Table 3 List of the license inconsistency metrics for each file group in the example project.
GroupID

#File

#Lic

#None

#Unknown

#GPL

1
2

2
2

2
1

0
1

0
0

2
0

the same source code (except for their code comments which include licensestatement), CCFinder treats them the same, and generate the same token
file. This also applies to foo.c file from Pkg3 and foo100.c from Pkg4. Thus
we can compare the hash value of the token files and group them into twogroups, as shown in Figure 2.
2. Identify licenses for files in each group: For each file in the group, we
use Ninka to detect their licenses and make a list of the file name, groupindex and the licenses, as shown in Table 2. File name is the name of thesource file. GroupID indicates the index we use to identify file groups.
3. Report groups that contain license inconsistencies and calculate
inconsistency metrics: We examine the licenses of each group and foundthat both of these groups contain license inconsistencies. Thus we report
both of these groups and compute the inconsistency metrics for each ofthem, as shown in Table 3.
According to our rule, #GPL ≥ 2 in Group 1 indicates a case of LUD inthis group, while #None > 0 and #Lic > 0 in Group 2 indicates a case of
LAR in this group. This conclusion is consistent to the scenario in our example
project, since the two foo.c files in Pkg1 and Pkg2 contain GPL-2.0+ and GPL3.0+ respectively which is LUD, and the file foo.c in Pkg3 and foo100.c in Pkg4
contain BSD-3-Clause and no license respectively which is LAR.

12

Yuhao Wu et al.

Table 4 Main characteristics of Debian 7.5.
Characteristics
Source Packages
Total files.c files.cpp files.java files

Number17,1606,136,637
472,861
224,267
365,213

4 Empirical Study
We have selected two target datasets for analysis: Debian 7.5 Linux distribution8 and 10,514 Java projects randomly downloaded from GitHub9 . We thenconducted our method on both datasets respectively. Since it is hardly feasible
to determine how many and what types of license inconsistencies are there in
the target projects, it is difficult to get an oracle data set and to perform aquantitative evaluation of our method, specially regarding its recall, which wewill talked more about in Section 5.4. However, a qualitative evaluation of thismethod is discussed in Section 5.
The following subsections will present the results obtained from the twodatasets, respectively.

4.1 Empirical Study on Debian 7.5
We conducted our study using a large open source Linux distribution, Debian
7.5. The source code was downloaded from its official site and its main characteristics are shown in Table 4. Only .cpp, .c and .java files are used, since
they account for the majority of source code in the Debian distributions andare the file formats supported by CCFinder.
4.1.1 Results
In the first step, we grouped the files under each set by their normalized token
sequences and resulted in 125,092 groups in total. The number of files within
one group ranges from 2 to 160, and the average number of files per groupis 2.8 with a median value of 2. The breakdown of each file type is shown in
Table 5.
Completing the following two steps, 6,763 groups were reported to have atleast one type of license inconsistency, which is 5.4% of the 125,092 groups intotal. For the sake of space, we show only three of them in Table 6, representing
each of the three types of license inconsistencies, which will be discussed in
the rest of this section.
89https://www.debian.org/
https://github.com/

Analysis of License Inconsistency in Large Collections of Open Source Projects

13

Table 5 Breakdown of number of groups and files for each type in analyzing Debian 7.5.
File typeGroup countFile count#Files(mean)#Files(median)

.c
.cpp
.java
Total

68,568
16,20240,322125,092

207,620
38,617
108,868
355,105

3.0
2.4
2.7
2.8

2
2
2
2

Table 6 Partial list of the license inconsistency metrics for each file group in detecting
Debian 7.5.
File name*GroupID

#File

#Lic

#None

#Unknown#GPLobstack.c
getopt.c**
getopt.c**
...

6645
46474
52662
...

19
6
9
...

2
2
2
...

0
3
1
...

0
0
7
...

2
0
1
...

* Each group may contain files with different file names. In this case we choose themajority file name to represent that group.
** These two groups both contain files named getopt.c, but the source code between

these two groups are totally different.
Table 7 Number of different types of license inconsistencies and their proportion in Debian
7.5. Note that one group may contain more than one inconsistency types, so that the total
percentage can exceed 100%.
Inconsistency type

Frequency

Perc.

4,562
2,137
883

67.5%
31.6%
13.1%

LC
LUD
LAR

Table 8 Example of LAR inconsistency, in getopt.c
Package name

Licenseicedove
iceweasel

NONE
MPL-2.0

Then we calculate the number of each type of license inconsistency andtheir proportion. The result is shown in Table 7. From this table, we can seethat from the total of 6,763 groups that contain one or more license inconsistency cases, 67.5% of them contain LC, followed by LUD and then LAR. Further
study is needed to investigate the legality of these modifications.
In the following paragraphs, we show examples for each type of license
inconsistency.
– LAR :
Examining the getopt.c in the second line from the inconsistency result listin Table 6, we get the license list of that group in Table 8. The remaining files
that contain the same licenses are omitted from this list.

14

Yuhao Wu et al.

We can see that the license of the getopt.c file from the iceweasel package
has an MPL-2.0 license while the one from package icedove has no license(marked as NONE). The contents of each file is as follows.
getopt.c from icedove package:#include <stdio.h>#include <string.h>[...]
int main(int argc, char **argv){
PLOptState *opt;
PLOptStatus ostat;[...]
return 0;}

getopt.c from iceweasel package:/* This Source Code Form is subject to the terms of the* Mozilla Public License, v. 2.0. If a copy of the MPL* was not distributed with this file, You can obtain one* at http://mozilla.org/MPL/2.0/.
*/#include <stdio.h>#include <string.h>[...]
int main(int argc, char **argv){
PLOptState *opt;
PLOptStatus ostat;[...]
return 0;}

As we can see in the file from icedove package, there is no license statement
at all, while the file getopt.c from iceweasel package contains a MPL-2.0
license. Meanwhile, the other parts of these two files are exactly the same,hence we consider it safe to assume that the origin of both files is the same.
There are several possible explanations to this case of license inconsistency:
1. The file from icedove package is the original one, and the developers of
iceweasel project reused the file and added a license to it.
2. The file from iceweasel package is the original, and developers of icedove
project reused this file and removed the license statement.
3. Both of the files in these two projects reused different versions of this filefrom another project (where the license was added or removed).
One way to try to discover which one is the true explanation is to lookat the history of the files in their corresponding version control repositories.
By tracing the revision history of both files, we found that the actual history
reflects the third possible explanation: the files in these two projects were imported from a third project named nspr, where the getopt.c file was created
without a license in version 4.7.1, and, for version 4.9.1 the license was changedAnalysis of License Inconsistency in Large Collections of Open Source Projects

15

Table 9 License list of group 6645 of obstack.c where LUD exists.
Package namedpkg
anubisLicenseGPL-2.0+
GPL-3.0+

Table 10 License list of group 52662 of getopt.c where LC and LAR exist.
Package name
p0f
snort
sofia-sipLicenseNONE
GPL-2.0
UNKNOWN (IBM)to the MPL-2.0. It seems that icedove reused this file before the license statement was added, while iceweasel imported the version after the license wasadded, thus caused the inconsistency of license.
– LUD:To exemplify this type of license inconsistency, we will use obstack.c, whichis in the first line in Table 6. Table 9 shows two packages that reuse this file.
As we can see from this table, the first file is licensed under GPL-2.0+ while
the second one is under GPL-3.0+.
The license statements of the files from dpkg and anubis package werelisted in Section 2.2. Both of these files contain more than 400 lines of code,and they are exactly the same except for their license statements. Tracing
the file history in both projects we found that this file was originally createdin gnulib. The license of this file was upgraded in gnulib from GPL-2.0+ to
GPL-3.0+. By examining the commit log of dpkg, we found that the developersof dpkg intentionally reused the older version of the file from gnulib project(they wanted the file to be licensed GPL-2.0+, not GPL-3.0+), which caused
the license inconsistency.
– LC:
We demonstrate this type of license inconsistency using getopt.c in thethird line from the Table 6.
As shown in Table 10, getopt.c from snort package contains GPL-2.0 while
the license of the one from sofia-sip could not be recognized.
The contents of these files are as follows.
getopt.c file from snort package:[...]** it under the terms of the GNU General Public License** Version 2 as published by the Free Software Foundation.
** You may not use, modify or[...]

getopt.c file from sofia-sip package:

16

Yuhao Wu et al.

[...]* COPYRIGHTS:*This module contains code made available by IBM*Corporation on an AS IS basis. Any one receiving the*module is considered to be licensed under IBM copyrights*to use the IBM-provided source code in any way he or she*deems fit, including copying it, compiling it, modifying[...]

From the header we know that the second file is licensed under IBM copyrights, but this is not a standard version of IBM Public License, thus Ninka
reported it as UNKNOWN. Since both these files contain the same programcode, we may assume that someone changed the license from one to the other.
We tried to find out the direction of this change, but due to lack of history it
was not possible to do so. This shows that determining the true provenanceof a file is difficult in general.
4.1.2 Manual Analysis
To decide whether these license inconsistency cases may indicate legal problems or not, we have conducted a manual analysis on the history of a subsetof the files.
We randomly chose the samples. To be precise, first we randomly selected acase of license inconsistency and investigated the reason that this case occurs,
then we randomly selected the next case and repeated the process. The timeneeded to investigate each case varies from several minutes to several hours,
depending on how well the related project is documented. Due to the difficulties and the time invested, we stopped investigating cases when the reasons are
saturated, that is, when same reasons of license inconsistency kept coming up
as we investigate new cases. Based on this policy, we have investigated 25 cases
in total. Then we tried to categorize them according to the reason that causedsuch inconsistencies. They are divided into three categories: safe changes (noviolation is found), unsafe changes (given all information available, it appears
to be a violation) and uncertain (it was not possible to determine whether
it was safe or unsafe). The results are shown in Table 11, and the a detailed
explanation of each category is as follows:– Safe Changes: In this category, either the original author or the developers
who reused the file changed the license statement, but the change they made isbased on the terms described in the license thus we classify it as a safe change.
They are further divided into 2 groups:
1) Original author modified/upgraded the license. In this case, the author ofthat file modified the license statement (either by upgrading or totally changing
it to another license), while the reusers still use the old version of the file (either
intentionally or unintentionally).
For example, as mentioned above we examined a file named obstack.c in our
inconsistency result. This file originates from gnulib project, and its licenseAnalysis of License Inconsistency in Large Collections of Open Source Projects

17

Table 11 The count and percentage of each category for the 25 investigated license inconsistency cases.
Category#

Perc.

Safe changes

14

56%

Unsafe changes

6

24%

Uncertain cases

5

20%

Total

25

Sub-category

#

Perc.

Original author changed the license.
Reuser chose a license from a multilicense.
Reuser changed the license.
Reuser added one or more licenses.
Source files are too small to be considered as clones.
Source files cannot be found in the upstream repositories.
Repositories are not available.

10
4

40%
16%

5
1
2

20%
4%
8%

1

4%

2

8%

25

is upgraded from GPL-2.0+ to GPL-3.0+ in a commit on 10/7/2007. This file
was reused in the dpkg project but with a GPL-2.0+ license, and in the lastcommit on 9/25/2011 the log is as follows:
libcompat: Update obstack module from gnulib. The version taken is the one
before the switch to GPL-3.0+. With a slight code revert to not have to include
exitfail.c and exitfail.h.
[...]

We can see that in this case, the reuser intentionally takes an older version
from the original project, which caused the inconsistency of license.
In another example, there is a file named paintwidget.cpp, which originatesfrom Qt project with BSD-3-Clause license. In another project called PySide,
this same file is licensed under LGPL-2.1/GPL-3.0 dual license. Since thesetwo projects both belong to Digia plc, which were acquired from Nokia, thisshall be a legal license modification.
2) The file was originally multi-licensed and reusers chose either one. The
author of the file licensed the file under two or more licenses, and the reusers
can choose either one of them.
There is a file named SimpleXMLParser.java which originates from iText
project and was under the Mozilla MPL-1.1/LGPL-2.0+ dual license. Thislicense allows the removal of one license. Developers in pdftk project reused
this file removing the MPL-1.1 license and chose LGPL-2.0+ as its license.
– Unsafe Changes: Under this category, developers who reused the source
file seemed to have modified the license statement which is not allowed by theoriginal license terms. This change may lead to legal disputes, thus we say it
is an unsafe change. We should clarify that we have reached this conclusion
based on the historical evidence available. The consequence is that anybody
who would like to reuse these files should pay special attention to these cases,
and do due diligence to determine what is the appropriate licensing of the file,and if it indeed poses a legal risk.

18

Yuhao Wu et al.

1) Reuser replaced the original license, and changed the copyright owner. The
file is under a certain license in the original project and developers who reused
the file changed the license statement and the copyright owner.
From our inconsistency list, we examined a file named X. (Because we do
not have certainty regarding our conclusion, we have declared not to include
the names of the projects and files.) According to the copyright year of X,
company Y is the copyright owner, and licensed the file under BSD-3-Clause.
When reused in a project named Z, developers changed the license to GPL2.0+ and the copyright header, which is not allowed in BSD-3-Clause. Thiskind of changes to the license statement by the reuser may lead to license
infringement, and may involve the reuser into legal disputes.
2) Reuser added one or more licenses. The original file is under some licenses,
and the reuser added one or more licenses to it while retaining the original
license.
From the result we examined a file named DOMException.java. This author of this file is World Wide Web Consortium (W3C), and was licensed
under W3C Software License. When developers reused this source file in ikvm
project, they added a GPL-2.0 License to it resulting a composition of these
two licenses. Meanwhile, the program code of this file was not changed at all.
We consider this case as unsafe, since this type of license modification makes
it unclear which part contains the original license and which part contains
the new license, since they added the license without adding any source codechanges to the file.
– Uncertain Cases: This category contains the license inconsistency cases
which are difficult to determine whether they are legally safe or not due toseveral reasons:
1) Source files are too small. Some files contain the same source code, but due
to their small size it is difficult to decide whether one is reused by the other orthey just happen to be the same. A more detailed case is discussed in Section
5.2.
2) Files cannot be found in the upstream repositories. We found many casesof license inconsistencies in the projects in Debian 7.5 that, when investigated
the upstream project’s repository, the file no longer existed.
For example, our method reported a file named jim-win32.c in jimtlc package with BSD-2-Clause license and in openocd package with Apache-2.0 license. When we tried to look for this file in the repository of openocd project,
it was not found. One explanation is that the file was removed in the project,
but was not yet updated in Debian 7.5.
3) Project repository not available. Some project repositories could not befound due to lack of documentation, while some could not be accessed due toserver error.

Analysis of License Inconsistency in Large Collections of Open Source Projects

19

Table 12 Main characteristics of Java projects cloned from GitHub.
Characteristics
Projects
Total files.c files.cpp files.java files

Number10,514
3,374,164
15,627
21,176
3,337,361

Table 13 Number of groups and files in each group in analyzing Java projects.
File typeGroup countFile count#Files(mean)#Files(median).java

199,284

769,220

3.9

2

One example is, when we tried to checkout the source code of axis projectusing the SVN command found on its official website10 , the command returned
an error that the URL does not exist.

4.2 Empirical Study on Java Projects
The other data set we studied is a collection of 10,514 Java projects randomly
cloned from GitHub. The snapshot was taken in Mar. 2015, and only thoseprojects that consist of at least 100 commits are selected. Table 12 shows thecharacteristics of these projects. Since .java files are 98.9% of all the files, wewill focus our following analysis on them only.
4.2.1 Results
In the first step, source files are grouped by their normalized token sequences.
The result was 199,284 groups. The number of files within each group ranges
from 2 to 1514, and the average number is 3.9 with a median value of 2, asshown in Table 13.
With the following steps being done, 13,916 groups are reported to containone or more license inconsistencies, which is 7.0% of the 199,284 groups intotal.
Furthermore, the number and proportion of each type of license inconsistency is shown in Table 14.
4.2.2 Manual Analysis
As we did in the Debian study, we examined a random sample of the inconsistent groups. We sampled 17 cases, and tried to categorize them according
to the reason that caused such inconsistencies. As described before, they are10

https://axis.apache.org/axis/cvs.html (Last access: Oct. 2nd, 2015)

20

Yuhao Wu et al.

Table 14 Number of different types of license inconsistencies and their proportion in Javaprojects.
Inconsistency type
LC
LAR
LUD

NumberPerc.

12,653
6,179
1,316

90.9%
44.4%
9.5%

Table 15 The count and percentage of each category for the 17 investigated license inconsistency cases in the Java projects.
Category#

Perc.

Safe changes

11

65%

Unsafe changes

1

6%

Uncertain cases

5

29%

Total

17

Sub-category

#

Perc.

Source files are in the same project butwith different licenses.
Duplicated projects are not up-to-date.
Reuser added a same license to thesource file.
Reuser modified the license terms.
Licenses are modified outside the scopeof their repositories.
Source files are too small.

8

47%

2
1

12%
6%

1
1

6%
6%

4

24%

17

divided into three categories, the percentage of each category is shown in Table
15, and the explanation to each category is as follows:– Safe Changes:
1) Source files are in the same project but with different licenses. Some projects
were imported from other version control systems, such as SVN, where branching and tagging makes copies of the whole project. When the license of source
files in the main branch (trunk) changes, license inconsistency occurs among
these branches.
For example, there is a project named weka which was imported from
SVN. In this project, files were originally licensed under GPL-2.0+ and thenupgraded to GPL-3.0+. Developers made a series of tags in the SVN repository,
leaving several copies of the whole project. Thus license inconsistencies exists
between the files under the tags which were made before the license upgrade
and those in the trunk.
Some other cases are, the source files are in the same project but exist
under different directories with different licenses.
2) Duplicated projects are not up-to-date. Some entire GitHub projects (orsubdirectories in other cases) are a copy (clone) of another project, and theirlicense of source code is not updated while the original project changed its
license.

Analysis of License Inconsistency in Large Collections of Open Source Projects

21

We examined two projects: JCrypTool11 and JCT-CA12 . A file named ResizeHelper.java exists in both projects with the same normalized token sequences. The one in JCT-CA is without a license, while the one in JCrypTool
was originally with no license but then added with a EPL-1.0. The readme filefrom JCT-CA states:
JCT-CA is going to be a plugin for the JCrypTool regarding Public
Key Infrastructure. Main development is done in the master branch,others (if any) are just for backing up older parts of the project
and keeping master clean.

From this notice we can see that, this project is a partial backup of the
JCrypTool project, but its license is not up-to-date when the original copy
has changed, resulting in a license inconsistency.
3) Reuser added a same license to the source file. One rare case we found is, thedevelopers of a reused source file, which is under Apache-2.0, added anotherexactly same Apache-2.0 license description in the header. One explanationis that the developers are using automated tools to manage the licenses, but
did not check whether the file already contains a license. Though it does notconflict with the license terms, we consider it as a bad smell.
– Unsafe Changes:
1) Reusers modified the license terms. Some developers reused the code fromother projects but made some modifications to the license terms. In this case,
if it is not with the permission from the original author, these modifications
are unsafe.
There are two files, both named F, in project M and N. These files are
originally from project O, and M is a fork of the this project. The license ofthis file in O is MIT, while the one in N was changed to GPL-2.0+ with link
exception.
– Uncertain Cases:
1) Licenses are modified outside the scope of their repositories. There are cases
that, the source files in different projects are with different licenses, but theirlicense statements have never changed since they were imported into these
repositories. Another alternate explanation is that developers downloaded thesoftware and modified the license before the first commit into the new repository, making it impossible to track the point where the license was changed.
2) Source files are too small. This case is same as the one in Debian data set.
This issue will be discussed in Section 6.
For example, a file named ReaderInputStream.java was found in bingo-coreproject with an Apache-2.0 license and in hibernate-orm project with an
1112

https://github.com/jcryptool/crypto
https://github.com/Kalliope/minica

22

Yuhao Wu et al.

LGPL license. However, the source code contents of these files are quite small,which merely contains two empty constructor methods. The source code partexcluding the comments is shown as following:[...]
import java.io.IOException;
import java.io.InputStream;
import java.io.Reader;public class ReaderInputStream extends InputStream {private final Reader reader;public ReaderInputStream(Reader reader){this.reader = reader;}@Override
public int read() throws IOException {return reader.read();}}

It is possible that different developers wrote the same code like this fromscratch, thus it is difficult to judge whether these files are copies of each other.

4.3 Discussion of the Results
From these results we can see that license inconsistencies are not uncommon: in
Debian 7.5, out of 125,092 file groups, 6,763 (5.4%) of them contain one or morelicense inconsistency cases: LC has the highest proportion with 67.5%, followed
by LUD with 31.6%, LAR comes next with 13.1%. While in Java projects, outof 199,284 file groups, 13,916 (7.0%) of them contain one or more license
inconsistency cases: LC has the highest proportion with 90.9%, followed by
LUD with 44.4%, LAR comes next with 9.5%.
The manual analysis of several cases of license inconsistencies gives us arough understanding of how many of these cases are safe or not. From Table 11
and Table 15 we can see that, both in Debian 7.5 and Java projects we selected,
unsafe and uncertain cases take up 44% and 35% respectively. This shows that
it is not uncommon that license inconsistencies might lead to potential license
violation problems.
During this process of the analysis, we also found several challenges thatprevent us from automatically analyzing the history of files.
Many files in an open source project are frequently imported from otherprojects. It is not a trivial task to find the repositories of these upstream
projects. Take the Debian distribution as an example: some of the packages
contain a file indicating the repository URL of that package, but some do not.
For such packages, we needed to search for the official site of the upstream
project and try to find its repository URL. There are packages that appear
not to use version control systems. They simply provide source code tarballsfor each version on their server. In this case, we have to download each tarballand track the license change manually. This makes provenance tracing moredifficult.

Analysis of License Inconsistency in Large Collections of Open Source Projects

23

In some cases the change of the license statement is not recorded in therevision history because the license statement is changed (we presume) before
the file is added to the repository’s project. In this case, we have to check otherinformation (e.g. on the official site of the project or in the commit comment
where the file was added) to find out the reason why developers changed thelicense. Our results are consistent with Vendome et al. (2015a), who found alack of traceability for license changes.
Also, after we found out that the files with the same normalized token
sequences in different packages contain different licenses, we have to determine
where the file comes from, i.e. the original project of that file, in order todecide the direction of the license change. But to the best of our knowledge,
there is no good way to find the true origin of a certain file. We address thisproblem by using the date of the first commit of that file as a reference. When
we have two copies in different repositories, we assume that the file with theoldest commit is the original, and files with newer dates are copies of it. If thecommit date is not available, e.g. when not using a version control system, we
have to manually check the comments of the source file to see if it contains
information about its true origin or its license. If not, then we are not able todecide which file comes first.

4.4 Answering RQs
Revisiting the research questions:– RQ1: How can we categorize a license inconsistency? We categorize license
inconsistencies into these 3 types: i) LAR, which is typically caused bylicense addition or removal; ii) LUD, which is related to license upgrade or
downgrade in the GPL family; iii) LC, which is usually caused by licensechange in the process of license evolution.
– RQ2: Do license inconsistencies exist in open source projects? Yes, license
inconsistencies exist in open source projects. As we have shown in ourempirical studies of Debian 7.5 and a large collection of Java projects on
GitHub, various types of license inconsistencies were detected.
– RQ3: What is the proportion of each type of license inconsistency? In thecase study of Debian 7.5, out of 125,092 file groups, 5.4% of them containone or more license inconsistency cases. The proportion of each type is: LAR(13.1%), LUD (31.6%) and LC (67.5%). In the case study of Java projects,
out of 199,284 file groups we selected, 7.0% of them contain one or morelicense inconsistency cases. The proportion of each type is: LAR (9.5%), LUD(44.4%) and LC (90.9%).
– RQ4: What caused license inconsistencies? Are they legally safe? The
reasons that caused license inconsistencies can be summarized into thesegroups according to our observation:i) Original author modified/upgraded the license.
ii) The file was originally multi-licensed and reusers chose either one.

24

Yuhao Wu et al.

iii) Reuser added one or more licenses.
iv) Reuser appears to have replaced the original license, and changed the
copyright owner.
We consider the last two types of modification as unsafe, which would
require further analysis to determine the legal risk associated with usingthem.

5 Discussion
In this section, we show the improvement we made to the research method witha comparison between these two methods, followed by a survey on developers
involved in license inconsistencies.

5.1 Improvement of the Method
As described in Section 3, our previous method (Wu et al., 2015) omits thecases if the files are renamed during the process of copy-and-paste reuse toachieve higher performance.
In the previous method, we assume that many copy-and-paste reuse areconducted without renaming the source files. Thus we first create file sets
where each set contains source files with the same file name. And then, undereach file set, we then group the files by their normalized token sequences.
Finally, we identify the licenses for each file in every file group and calculate
the license inconsistency metrics.
In this paper, however, the new method treats all the source files as awhole set, and groups them by their normalized token sequences. Thus itshould obtain a more comprehensive result of license inconsistencies.
The following two subsections compare the two methods on the two data
sets we used, respectively.
5.1.1 Debian 7.5
Table 16 shows the comparison of results obtained by the two methods, for
Debian 7.5.
As we can see from the table, the new method covers all the groups thatthe previous method reported. Besides, it also reported 1419 (21.0%) morelicense inconsistency groups. As a conclusion: the result from the new method
is a superset of the one from the previous method, which is consistent with
our expectation.
5.1.2 Java Projects
Table 17 shows the comparison of results obtained by the two methods whenapplied to the Java projects in GitHub.

Analysis of License Inconsistency in Large Collections of Open Source Projects

25

Table 16 Comparison of two methods on Debian 7.5.
Number of groups

New method

Previous method

Total
Intersectioni
Relative complementii

6763
5344
1419

5344
5344
0

i Intersection indicates the groups both method reported.
ii Relativecomplement indicates the groups reported in one
method but not the other.

Table 17 Comparison of two methods on Java projects.
Number of groups

New method

Previous method

Total
Intersection
Relative complement

13,916
13,89422

13,894
13,8940Again we can see from this table, the new method covers all the groups
that the previous method reported. However, there are merely 22 more groups
reported by the new method, from which we can infer that the renaming
operations are not frequently conducted in the process of copy-and-paste code
reuse in these Java projects. This also proves that our previous method is able
to produce a good result in detecting license inconsistencies where rename
operation are not often conducted during the process of code reuse.

5.2 What Appears to Be a Copy Might Not Be a Copy
We sent emails to the 3 development teams of the projects where unsafe licensemodification were found, to understand why they modified the license andwhether they consider it as an illegal modification and two of them replied us.
One of them claimed that they wrote the source code all from scratch, anddenied that this source file was copied from somewhere else. This source file
was so small which contains merely two empty constructors, thus we believe
it is possible that different developers happen to create the same file. Note
that, this is not a false positive case of our method, since our method isdesigned to detect license inconsistency cases in the target projects, not thelicense violation cases. However, it stresses the need to consider a minimum
size threshold, in order for these small files not be considered in the analysis.

5.3 Changes Were Made Under the Permission of Copyright Owner
In another case, we found that Glassfish project included some copies of
Apache code. However, in Glassfish project, the license of these files are changed
from Apache-2.0 to CDDL and then to a combined license: CDDL, GPL-2.0
or Apache-2.0. The reply from the Glassfish team is that, they are using an

26

Yuhao Wu et al.

automatic tool for license maintenance, and this tool mistakenly replaced theApache-2.0 license with CDDL. This change was reported to them, and thenthey discussed with people at Apache and reached an agreement that thesefiles should be updated with the combined license mentioned above. In thiscase, although license inconsistency exists, the change of license is under thepermission of the copyright owner, thus we consider it legally safe.

5.4 An Attempt in Measuring the Recall
We have attempted to search on Google with keywords “site:bugs.debian.org
license” in expectation of getting a list of bug reports in Debian project thatare related to license inconsistency issues, so that we can use them as groundtruth to measure the recall of our method. However, with a manual inspection
on the top 10 results returned by Google, none of these bug reports are related
to the license inconsistency issues discussed in this paper. For example, some
bug reports are discussing the issue that the license is missing from some source
files, which can hardly be utilized in this research. Therefore, it is difficult tobuild a ground truth for us to measure the recall of our method.
Nevertheless, although bug reports about license inconsistency are notfound in the results of Google search, license inconsistency cases do exist in
reality as shown in the previous sections. Thus we believe our method is still
useful in discovering potential license issues related to license inconsistency
problems.

6 Threats to Validity
In our approach, CCFinder was used to obtain the normalized token sequencesof the source files. We then put files into the same clone group if they havethe same hash value of normalized token sequences. Although CCFinder itself
is a clone detection tool, we do not utilize the full functionality of it, thus theaccuracy of CCFinder is not directly related to the accuracy of our method.
Meanwhile, source code files are evolving: those that come from the same
provenance may differ from each other dramatically after being modified bydevelopers, resulting in different normalized token sequences. A possible solution to this problem might be using pairwise checking method instead, e.g.
detect clones based on the similarity of each pair of source files. However, ina conventional pairwise checking method, n2 pairs of source files need to beprocessed when there are n source files in total. In our approach, we only needto calculate the hash value of the normalized token sequences of each file, andthe files that have the same hash value would be naturally put into the sameclone group. Thus the time complexity of our approach would be O(n) insteadof O(n2 ) in the pairwise checking method. Due to this performance reason, we
chose to use hash approach instead of pairwise checking method in this paper.
And since we can still get large numbers of file groups that contain licenseAnalysis of License Inconsistency in Large Collections of Open Source Projects

27

inconsistencies using this method, we believe that it is good enough for this
exploratory study.
On the other hand, during our manual analysis we found file clones that
contain the same normalized token sequences, but due to their small size andsimplicity, it is difficult to decide whether they are copies of each other or they
were written from scratch by independent developers. If the later one is theactual case, then it would be a false positive of our result. But we believe it
might be good practice to report these cases, have a manual investigation onthem and ask the developers directly.
One aspect that is important to highlight is that our method relies on theability to detect copies of files. In our previous paper (Wu et al., 2015), we
found copies of files by analyzing files with the same name. In this paper wecompared the normalized token sequences of files. We could also do full clone
detection and consider two files to be copies of each other only if they wereabove certain threshold. This process would have been significantly more time
consuming. Ultimately, detecting license inconsistencies is a balance between
performance of the detection vs. recall. If necessary, step one of our method
can be replaced with other methods that provide better recall, at the expenseof being slower, and potentially require more manual analysis to filter out false
positives.
It is also important to highlight that the ability to detect license inconsistencies relies heavily on having a comprehensive corpus to compare against.
In this study we have used two collections of source code: Debian 7.5 and Java
GitHub projects. License inconsistencies in the source code can only be found
if the original code is in the corpus that is being compared against.
In the process of license identification, as we used Ninka to identify thelicense of source files, its accuracy should also be considered. German et al.
reported that the accuracy of Ninka is 93% (German et al., 2010b). We believe
this is sufficiently high, so that the license detection result is good enoughto support our analysis. In addition, we regard UNKNOWN licenses as thesame license within each group, different from any other licenses. If these
UNKNOWN licenses in a same group are actually different from each other, we
may underestimate the number of license inconsistency cases. But this concern
is mitigated according to our observation to these UNKNOWN licenses: mostof those in the same group actually contain the same license statement, eithera license that is not approved by OSI or a user modified version of an OSIapproved license. On the other hand, if these UNKNOWN licenses are actually
the same as those recognized ones (e.g. GPL-2.0, BSD-3-Clause etc.) in thesame group, this could be considered as a false positive. In this case, these
UNKNOWN licenses are not exactly the same as the original license, meaningthat someone must have modified the license statement (making Ninka notable to recognize the license). We believe that it is necessary to check whether
these changes are legal or not. Thus it is reasonable to treat them as licensemodifications, which is consistent with our assumption. To obtain more precise
results, it is necessary to improve the accuracy of license identification.

28

Yuhao Wu et al.

7 Related Work
Many studies address inconsistent changes among code clones. Krinke (2007)
studied on changes applied to code clones in open source software systems andshowed that half of the changes to code clone groups are inconsistent changes
and these changes are not solved if they occurred in a near version. Göde andHarder (2011) studied patterns of consecutive changes to code clone in real
software systems. Some approach to find inconsistent changes are proposed(Gabel et al., 2010; Higo and Kusumoto, 2014). On the other hand, Bettenburg
et al. (2009) showed that only 1% ∼ 4% of inconsistent changes to code clone
introduce software defects. In addition, Göde and Koschke (2011) showed thatmost code clones do not evolve and the number of inconsistent changes issmall. Our work does not address inconsistency in changes to code clones but
inconsistency among licenses under which source files including code clones
are distributed.
In addition, many studies in software engineering investigated software
license. Some approaches for software license identification are proposed (German et al., 2010b; Gobeille, 2008; Tuunanen et al., 2009). Using these approaches, some researches analyzed software licenses in open source projects
and revealed some license issues. Di Penta et al. (2010) provided an automatic
method to track changes occurring in the licensing terms of a system and did
an exploratory study on license evolution in six open source systems and explained the impact of such evolution on the projects. German et al. (2010a)
proposed a method to understand licensing compatibility issues in software
packages. They mainly focused on the compatibility between license declaredin packages and those in source files. In another research by German et al.
(2009), they analyzed license inconsistencies of code siblings (a code clonethat evolves in a different system than the code from which it originates) between Linux, FreeBSD and OpenBSD, but they did not explain the reasons
underlying these inconsistencies. Alspaugh et al. (2009) proposed an approachfor calculating conflicts between licenses in terms of their conditions. However,
our work proposed an approach to find license inconsistencies in similar files.
By investigating the revision history of these files, we summarized the factorsthat caused these license inconsistency cases and tried to decide whether they
are legally safe or not. Zhang et al. (2010) proposed an automatic method tocheck license compliance problems caused by ignorance or carelessness. Theyuse Google Code Search to discover file clones with different licenses, while ourmethod detect file clones within our target data sets. Recently Vendome et al.
(2015a) performed a large empirical study of Java applications and found thatchanging license is a common event and a lack of traceability between when
and why the license of a system changes. In their following research, Vendome et al. (2015b) investigated the reasons on when and why developers
adopt and change licenses during evolution of FOSS Java projects on GitHubby conducting a survey with the relevant developers. They concluded thatdevelopers consider licensing as an important task in software development.
However, license implications or compatibility are not always clear and so they

Analysis of License Inconsistency in Large Collections of Open Source Projects

29

can lead to changes. In addition, other external factors, such as community,
purpose of usage and use of third-party libraries also influence the projects’
licensing.

8 Conclusion and Future Work
This paper describes and categorizes different types of license inconsistencies,
some of which might lead to potential license violations. We also proposed amethod to identify files that might have license inconsistencies. With the proposed method, we managed to detect all these types of license inconsistencies
from two data sets of open source projects: a Linux distribution Debian 7.5
and Java projects selected from GitHub. These results show the existence of
license inconsistencies in open source projects and prove the feasibility of our
method.
With a manual analysis on some license inconsistency cases, we discoveredthat there are several reasons behind them: in some cases the copyright ownerchanged the license statement; sometimes reusers exercised the permission thatthe file license gave them to remove one or more licenses from the file; in othercases, reusers added another license to the file; and finally, reusers modified
the license. Among them, the last two categories are potentially unsafe andrequire further investigation.
Although the time needed for manual analysis on each case is relatively
long, for developers who use our method, they only need to focus on the
projects they are interested in (e.g. the projects they are maintaining). Thus
the files they need to check are merely a small portion of the whole population.
And we consider it feasible for developers to make sure their project involves
no license violations using this proposed method.
In the process of our manual analysis, we came across a great difficulty tofind out the reason behind each license inconsistency case. On one hand, it isdifficult to find out from where a certain file in a project is imported when
lacking enough information. On the other hand, it is also not a trivial task to
decide which file is the original work when they are found in multiple projects.
We tried to utilize creation date of the source files as the metric to decide
which one is the original one. However, different ways of duplicating files havedifferent influences on the creation date of that duplicated file. Pulling from a
git repository or simply copy-and-pasting a file will override the creation date;extracting files from an archive file (such as a zip file) will not override thecreation date. Thus we consider it not sufficient to decide the provenance ofa file using the creation date only. These problems highlight the need for amethod to find and maintain the provenance between applications.
For future work, we will apply our tool to more open source projects andexamine the proportion of each type of license inconsistency. With the increased number of projects, we believe that many more license inconsistencycases will be found. And we will try to make a quantitative evaluation of thistool. Furthermore, we will try to develop a method to help us analyze the30

Yuhao Wu et al.

history of each file, so that we can decide the safety of these inconsistencies
efficiently.
Acknowledgements This work is supported by Japan Society for the Promotion of Science, Grant-in-Aid for Scientific Research (S) “Collecting, Analyzing, and Evaluating Software Assets for Effective Reuse”(No.25220003) and Osaka University Program for Promoting
International Joint Research, “Software License Evolution Analysis”.

References
Alspaugh T, Asuncion H, Scacchi W (2009) Intellectual property rights requirements for heterogeneously-licensed systems. In: Proceedings of the 17th
International Requirements Engineering Conference (RE2009), pp 24–33,
DOI 10.1109/RE.2009.22
Bettenburg N, Shang W, Ibrahim W, Adams B, Zou Y, Hassan A (2009)
An empirical study on inconsistent changes to code clones at release level.
In: Proceedings of the 16th Working Conference on Reverse Engineering(WCRE2009), pp 85–94, DOI 10.1109/WCRE.2009.51
Boehm BW (1987) Improving software productivity. Computer 20(9):43–57,
DOI 10.1109/MC.1987.1663694
Burd E, Bailey J (2002) Evaluating clone detection tools for use during preventative maintenance. In: Source Code Analysis and Manipulation, 2002.
Proceedings. Second IEEE International Workshop on, IEEE, pp 36–43
Di Penta M, German DM, Guéhéneuc YG, Antoniol G (2010) An exploratory
study of the evolution of software licensing. In: Proceedings of the 32nd
International Conference on Software Engineering (ICSE2010), pp 145–154
Gabel M, Yang J, Yu Y, Goldszmidt M, Su Z (2010) Scalable and systematic
detection of buggy inconsistencies in source code. In: Proceedings of the25th International Conference on Object-Oriented Programming, Systems,
Languages, and Applications (OOPSLA2010), pp 175–190
German D, Di Penta M, Gueheneuc YG, Antoniol G (2009) Code siblings:
Technical and legal implications of copying code between applications. In:
Proceedings of the 6th Working Conference on Mining Software Repositories(MSR2009), pp 81–90, DOI 10.1109/MSR.2009.5069483
German D, Di Penta M, Davies J (2010a) Understanding and auditing thelicensing of open source software distributions. In: Proceedings of the 18th
International Conference on Program Comprehension (ICPC2010), pp 84–
93, DOI 10.1109/ICPC.2010.48
German DM, Hassan AE (2009) License integration patterns: Addressing license mismatches in component-based development. In: Software Engineering, 2009. ICSE 2009. IEEE 31st International Conference on, IEEE, pp
188–198
German DM, Manabe Y, Inoue K (2010b) A sentence-matching method for automatic license identification of source code files. In: Proceedings of the 25th
International Conference on Automated Software Engineering (ASE2010),
pp 437–446

Analysis of License Inconsistency in Large Collections of Open Source Projects

31

Gobeille R (2008) The FOSSology project. In: Proceedings of the 5th Working
Conference on Mining Software Repositories (MSR2008), pp 47–50
Göde N, Harder J (2011) Oops! . . . I changed it again. In: Proceedings of the
5th International Workshop on Software Clones (IWSC2011), pp 14–20
Göde N, Koschke R (2011) Frequency and risks of changes to clones. In:
Proceedings of the 33rd International Conference on Software Engineering(ICSE2011), pp 311–320, DOI 10.1145/1985793.1985836
Higo Y, Kusumoto S (2014) MPAnalyzer: A tool for finding unintended inconsistencies in program source code. In: Proceedings of the 29th International
Conference on Automated Software Engineering (ASE2014), pp 843–846
Kamiya T, Kusumoto S, Inoue K (2002) CCFinder: A multilinguistic tokenbased code clone detection system for large scale source code. IEEE Transactions on Software Engineering 28(7):654–670
Krinke J (2007) A study of consistent and inconsistent changes to code clones.
In: Proceedings of the 14th Working Conference on Reverse Engineering(WCRE2007), pp 170–178, DOI 10.1109/WCRE.2007.7
Li J, Conradi R, Bunse C, Torchiano M, Slyngstad O, Morisio M (2009) Development with off-the-shelf components: 10 facts. IEEE Software 26(2):80–87,
DOI 10.1109/MS.2009.33
Manabe Y, Hayase Y, Inoue K (2010) Evolutional analysis of licenses in
FOSS. In: Proceedings of the Joint ERCIM Workshop on Software Evolution
and International Workshop on Principles of Software Evolution (IWPSEEVOL2010), pp 83–87, DOI 10.1145/1862372.1862391
Manabe Y, German D, Inoue K (2014) Analyzing the relationship between
the license of packages and their files in free and open source software. In:
Proceedings of the 10th International Conference on Open Source Systems(OSS2014), pp 51–60, DOI 10.1007/978-3-642-55128-4 6
McIlroy MD, Buxton J, Naur P, Randell B (1968) Mass-produced software
components. In: Proceedings of the 1st International Conference on Software
Engineering (ICSE1968), pp 88–98
Roy CK, Cordy JR, Koschke R (2009) Comparison and evaluation of code
clone detection techniques and tools: A qualitative approach. Science ofComputer Programming 74(7):470–495
Sasaki Y, Yamamoto T, Hayase Y, Inoue K (2010) Finding file clones in
FreeBSD ports collection. In: Proceedings of the 7th Working Conferenceon Mining Software Repositories (MSR2010), IEEE, pp 102–105
Standish TA (1984) An essay on software reuse. IEEE Transactions on Software Engineering SE-10(5):494–497, DOI 10.1109/TSE.1984.5010272
Tuunanen T, Koskinen J, Kärkkäinen T (2009) Automated software license
analysis. Automated Software Engineering 16(3-4):455–490, DOI 10.1007/
s10515-009-0054-z
Vendome C, Linares-Vásquez M, Bavota G, Di Penta M, Germán DM, Poshyvanyk D (2015a) License usage and changes: A large-scale study of java
projects on github. In: The 23rd IEEE International Conference on Program Comprehension, ICPC 2015

32

Yuhao Wu et al.

Vendome C, Linares-Vásquez M, Bavota G, Di Penta M, German DM, Poshyvanyk D (2015b) When and why developers adopt and change software
licenses. In: Software Maintenance and Evolution (ICSME), 2015 IEEE International Conference on, IEEE, pp 31–40
Wu Y, Manabe Y, Kanda T, German DM, Inoue K (2015) A method to detect
license inconsistencies in large-scale open source projects. In: Proceedings ofthe 12th Working Conference on Mining Software Repositories (MSR2015),
pp 324–333
Zhang H, Shi B, Zhan L (2010) Automatic checking of license compliance.
In: Software Maintenance (ICSM), 2010 IEEE International Conference on,IEEE, pp 1–3