Detecting License Inconsistencies Based on Token Size
in Open Source Software
Daniel Kim
University of California, Berkeley
Software Engineering Laboratory, Professor Katsuro Inoue
Graduate School of Information Science and Technology
Abstract
Free open source software (FOSS) is an integral part of modern day software engineering. It allows
for the reuse of source code in other pieces of software. To facilitate and stipulate the conditions ofreuse of the source code, such code usually have one or more software licenses, found in a license
file or in the header of the source file. During software reuse, developers and authors of the sourcecode may add, alter, or remove licenses from the source code, creating inconsistencies in licenses
between new and old versions of source code. The purpose of this research is to validate previous
research conducted by the Software Engineering Laboratory and to explore the relationships
between minimum token size for code clone detection, detection of license inconsistencies, andtypes of license inconsistencies. The main target of the research is the source files found in Debian
8.2. Python 2.7 was used to run scripts that analyzed the source code using CCFX, a code clone
detector, Ninka, a license detector, and SQLite3, a lightweight database management system. In
addition, manual inspection was used to verify if detected code clones are actual clones instead ofchance resemblances. Results were largely predictable, that is, that as minimum token size
increased, detected license inconsistencies decreased. However, results also showed that the average
number of snippets found in a given clonesets decreased very slightly as token size increased
heavily, implying that a large number of detected clones are chance resemblances, further reinforcedby manual inspection. The most common type of license inconsistency, license change, also drops
rapidly as token size increases. In conclusion, token size does influence the detection of license
inconsistencies and type of license inconsistency.
1 Introduction
Free open source software (hereon on referred to as FOSS) has become an essential component ofsoftware development. It allows for the free reuse and alteration of software components and inorder to regulate its usage based on the original developer’s wishes, licenses naturally followed.
Throughout the lifetime of such software, these licenses may change due to either the developer orthe author’s wishes, creating license inconsistencies. That is, source files from the same or different
packages that contain the same code but different licenses.
These license inconsistencies, if legally invalid, could pose as license violations and should bechanged promptly. Due to the prevalence of software reuse and difficulties of maintaining different
versions of software, there are likely many license inconsistencies and possibly license violations.
2 Related WorkWork exploring the existence and classification of license inconsistencies has been conducted inlarge part by the Software Engineering Laboratory at Osaka University. [1] Their research has
shown the license inconsistencies found in the source files for Debian 7.5 and several large projects
written in Java on Github.

Motivation for this research comes in part from their research in part to validate previous research
as well as to explore the relationship between token size and both the amount and types of license
inconsistencies found.
3 Methodology
The target of this research is the code base for Debian 8.2. Unfortunately, due to time constraints, afull-scale analysis of the entire code base has proved infeasible and instead this research will focus
on a small subset of the code base. The files in question are written in C/C++ and Java.
In order to detect source code where reuse has occurred, this research will be using a tool called
CCFinderX (CCFX). This tool detects both Type 1 and Type 2 code clones and analyzed the target.
The output of CCFX was then analyzed with a script written in the Python language and theappropriate data stored in a SQLite3 database.
During this procedure, another tool developed by the Software Engineering Laboratory at OsakaUniversity, called Ninka, was used to identify the license of a source code file. Lastly, all files thatwere determined to be code clones according to CCFX but with different licenses were compiled. A
few code clones were also randomly chosen for manual inspection. The results are as follows.
4 Results
Type of File

Number of Files

C/C++

6109

Java439

The above table describes the number of files found in the target based on file type. The followinggraphs illustrate the resulting data based on token size. Nothing is shown for Java files as there wereno license inconsistencies found.

Clonesets Per Token Size
CPP

Number of Clonesets

25000
20000
15000
10000
5000
03040506080100

125

150200Token Size

As seen in the first graph, as token size increases, the number of clonesets, that is, the number ofsets of code clones as determined by CCFX decreases. This is expected, as the threshold for what is
considered to be a code clone is increased.

Mean Number of Snippets in Cloneset Per Token Size

Mean Number of Snippets in Cloneset

CPP3.532.521.5
10.503040506080

100

125150200

Token Size

In the second graph, as token size increases, the mean number of snippets in cloneset decreases.
Interestingly, the decrease is relatively small, given that the average number of snippets perclonesets decreases from about 3 to about 2.5.

Mean Length of Snippets Per Token Size

Mean Length of Snippets

CPP
500
450
400
350
300
250
200
150
100
50030

4050

60

80

100

125

150

200

Token Size

In the third graph, as token size increases, the mean length of snippets increases as well. This is
expected, as the minimum threshold for what can be considered a code clone increases and thus thelength of each snippet increases.

Number of License Inconsistencies Per Token Size

Number of License Inconsistencies

CPP
9000
8000
7000
6000
5000
4000
3000
2000
1000
030

4050

60

80

100

125

150

200

Token Size

As seen in the fourth graph, the number of license inconsistencies decreases dramatically as token
size increases. This result is surprising, as this implies that a large amount of license inconsistencies
are found as token size decreases. To further elaborate on these detected license inconsistencies,
they were classified by previous research [1] as follows.
1. License Addition: The source file was without a license, and a license is added in at a later time.
2. License Removal: The source file was under a certain license, and the license is removed at alater time.
3. License Upgrade: The source file was under a certain version of the GPL license, a license thatallows an upgrade, and it is upgraded to a newer version of the license.
4. License Downgrade: The source file was under a certain version of a license and has been
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.

Types of License Inconsistencies
Number of License Inconsistencies

3000
2500
2000

License Change
License Downgrade
License Upgrade
License Removal
License Addition

1500
1000
500
040

50

60

80

100

Token Size

125

150200In the fifth and last graph, we see that a large portion of these license inconsistencies are licensechanges for smaller token sizes. However, they dramatically decrease in number as token size
increases. Also interestingly, the number of instances of license removal and addition also appear toreduce to a very small percentage of total license inconsistencies as token size increases.
5 Conclusion
In conclusion, it appears that smaller token sizes seem to include a large portion of false positives.
Upon manual inspection of several snippets of shorter lengths, they were appeared to be clones thatwere similar by chance instead of intentional reuse of software. Based on the results as seen in therelatively stable mean number of snippets per cloneset and the dramatic decrease in detected license
inconsistencies as token size increases, it can be safely concluded that a token size of 30 does notadequately detect license inconsistencies.
However, specifically which token size is optimal for detecting license inconsistencies was unable
to be determined from this research. Statistical analysis of each token size would be required to see
clearly which token size excludes the most false positives while including the most true positives.
6 Further Research
There is room for much future research. Given the time constraints of this research term, a futurefull-scale analysis of the entire code base of Debian 8.2 would prove useful. In addition, analyzing
different versions of Debian and tracking changes in the code base over time may provide
interesting results.
There also can be analysis of which sorts of licenses experience which type of license inconsistency.
Further research can analyze the relationship between token size and the prevalence of different
types of license inconsistencies for specific types of licenses.
Lastly, there could be further research conducted on determining the optimal token size fordetecting license inconsistencies.
Acknowledgement
This work is supported by the Graduate School of Information Science and Technology at OsakaUniversity.
References[1] Y. Wu, Y. Manabe, T. Kanda, D. German, K. Inoue. Analysis of License Inconsistency in Large
Collections of Open Source Projects. 2015. Retrieved June 21, 2017 from http://sel.ist.osakau.ac.jp/lab-db/betuzuri/archive/1059/1059.pdf.