Evolutional Analysis of Licenses in FOSS
Yuki Manabe

Yasuhiro Hayase

Katuro Inoue

Osaka University
Osaka, Japan

Toyo University
Saitama, Japan

Osaka University
Osaka, Japany-manabe@ist.osakau.ac.jp

hayase@toyo.jp

inoue@ist.osaka-u.ac.jp

ABSTRACT

is to integrate thousands of FOSS les where the developer

FOSS (Free and Open Source System) is repeatedly modied
and reused by other FOSS or proprietary software systems.
They are released to others under specic licenses whoseterms and conditions are usually written on the source-codeles as program comments. There are a few researches which
automatically analyze the licenses in a FOSS release, butthere is no statistical study on the evolution of licenses along
the evolution of FOSS. In this paper, we analyze licenses
through FreeBSD, OpenBSD, Eclipse, and ArgoUML evolution, using our license analysis tool Ninka, and discusscharacteristics on the evolution of the license used in thosesystems.

can hardly check the license of each le[8].
There are several tools which automatically analyze andreport the licenses of source-code les.

There is a license

detection tool named Ninka, which can analyze the les moreeciently and accurately than other tools[6].
Using those tools, there are a few papers (or studies) on
the analysis of licenses in FOSS[2, 4, 6, 7]. However, there
is no study of license evolution for specic evolving FOSS.
A large change of license in software aects reusabilityof software. Some people know about a large change of license in software.

However, there is no research of quan-titative analysis of a large change of license in software.
So, with software evolution analysis, it is useful for improv-

Categories and Subject Descriptors
D.2.7 [Software Engineering]:

Distribution, Maintenance,

ing reusability of FOSS to examine what often such licensechange, how the change occurs and what information we canpredict the change with.
As a rst step to a large license change research, this paperand EnhancementVersion Control; D.2.9 [Software Engineering]: ManagementsCopyrights

reports the analysis result of large-scale FOSS with respect
to the evolution of those FOSS. We analyzed each release ofGeneral Terms
Measurement, Experimentation

FreeBSD, OpenBSD, Eclipse and ArgoUML. Here we mainly
focus on the ratio of licenses used in each release of thosesystems.
The major ndings are as follows.

Keywords• The number of dierent licenses used in the operating systems such as FreeBSD and OpenBSD are larger

Software License, Repository Mining

than those used in specic applications such as Eclipse
and ArgoUML.

1. INTRODUCTION• Licenses can sometimes drastically change in a release

Licensing is one of the ways to protect intellectual prop-

version.

erty of FOSS (Free and Open Source Software). Open Source

1

Initiative

approved 66 licenses, which are commonly used

• License ratios in the kernel les of those operating sys-

by major FOSS.

tems are similar to those of the overall operating sys-

Developers have to read the licenses carefully, which aretems.

generally written on each source-code le as program comment, and to understand and follow the written require-• FreeBSD and OpenBSD kernels contain les with GPLv2

ments and constraints. One of serious risks in using FOSS

1

license, which are located separately from others.

http://www.opensource.org/

In Section 2, we describe the background knowledge usedin this paper. Section 3 sets the research questions for the
analysis of license evolution. In Section 4, we show our analysis of results for four major FOSS, and discuss their threats

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.
IWPSE-EVOL ’10 September 20-21, 2010 Antwerp, Belgium
Copyright 2010 ACM 978-1-4503-0128-2/10/09 ...$10.00.

to validity in Section 5. Section 6 shows the related works
and Section 7 concludes our discussion with a few remarks.

2.

SOFTWARE LICENSE AND NINKA
Software license (or simply license) means a set of direc-

tions to software users, which are set up by the softwareauthor.

We list the names and their abbreviation namesof licenses used in this paper in Table 1.

Many of theseWe have conducted an experiment for these research ques-licenses have several versions. In that case we use the suf-

tions. For the experiment, we have used four major FOSS,x v<number> to identify it.

If it is followed by +, that

FreeBSD, OpenBSD, Eclipse and ArgoUML. Table 2 showsmeans the user can choose this version or any newer: ortheir characteristics. Note that we have used the entire mod-later .

For example, GPLv2+ means GPL version 2 orule under the Eclipse platform project, as Eclipse. Also welater . This paper does not argue about the legal issues ofhave used the base system of FreeBSD and OpenBSD, as

those directions. A source-code le contains comments and

FreeBSD and OpenBSD, respectively. The reasons why weprogram code.

Comments are used for the explanation ofuse these system are that they are used in[2], they has many

program code, license direction, or other purposes. The li-

release version and we can examine the dierence between

cense direction contained in a le would generally consist of

an application consisted of simple application and a number

several natural-language sentences.

of application.

Software license detection tool Ninka identies each English sentence in the leading comment of a source-code le,

4.1

RQ1

and performs the lower-level pattern matching against theAt rst, we have found each release version of those sys-meta-license statement collection of well-used licenses. Fromtems, by reading the logs stored in the version control sys-

this matching result of every license-related sentence in thetems and the release information in the web site of thosecomments, then, Ninka performs the higher-level patternsystems.

matching against the sentence-arrangement pattern collec-

Secondly, we have downloaded the source tree in each re-tion of the well-used licenses, and it determines the license.

lease version. Here, we used les written in C (*.c), C++(*.cpp,

This two-phased matching approach is exible to identify*.c++, *.cxx, *.cc), Java(*.java), Python(*.py), Perl(*.pl,minor variation of license description, and it also allows ex-*,pm), Emacs lisp(*.el) and Sawsh scripting language(*.jl).

tending to new licenses.

Currently, Ninka has 427 meta-

Finally, we have identied the licenses of each release oflicense statements and 126 sentence-arrangement patterns

those systems, by using Ninka. Ninka reports the identiedin its license-knowledge database.

Ninka can identify 110

license for each le, say, BSD4 or GPLv2+. Ninka also saysdierent licenses with 93% accuracy, and it can handle more

NONE (the le includes no license-related sentences) andthan 600 les per minute[6].

UNKNOWN (the le includes the license-related sentences

License ratio means the ratio of the les with specic licenses against the total number of overall les in the target.

Abbrev.
Apache
BSD4
BSD3
BSD2
CPL
CDDLicEPL
GPL
LesserGPL
LibraryGPL
MIT/X11
MIToldName
Apache Public License
Original BSD, also known as BSD with 4
clauses
BSD4 minus advertisement clause
BSD3 minus endorsement clause
Common Public License
Common Development and Distribution
LicenseEclipse Public License
General 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 withdierent wording

Table 1: Names of common open source licenses and theirabbreviations used in this article.

but it failed to match them to the sentence-arrangement
patterns).
We have repeated second and third process for each release
version until we have obtained all needed source-code lesof each release.

Figures 1 ∼ 4 show the analysis result of FreeBSD, OpenBSD,

Eclipse, and ArgoUML respectively, over the evolution ofeach release. In each graph, X-axis means release version,
y-axis means the number of les. Each layer corresponds toeach license. We have chosen and presented 5 most popular
licenses in those Figures.
Interesting ndings here are as follows.

• In the case of FreeBSD (Figure 1), BSD4 license decreases over the evolution. On the other hand, BSD2and BSD 3 increase along the evolution. This is due tothe policy change of the Berkeley distributor such thatno more acknowledgements were needed within advertising materials and they started to change licenses in
the new les. So, this change relaxes the condition of
the license.

• The same tendency can be seen in the case of OpenBSD(Figure 2). In this case, there are many NONE les.
This is because they use COPYING le of GPLv2+ to

3. RESEARCH QUESTIONS
We set up the following three research questions to examine the license ratios in detail.
RQ1: How the license ratios of operating systems are different from the one of non-operating systems?
RQ2: What are the evolutional patterns of license ratiosof the operating systems?
RQ3: Are the license rations of the kernels of operating
systems dierent from the other parts of those systems?

indicate licenses, instead of adding license statement
to each le.

• In Eclipse (Figure 3), majority of known licenses haschanged from CPLv0.5 to CPLv1, and then to EPLv1.0.
These changes appear very sharply in Figure 3.

On

the other hand, above mentioned changes of FreeBSD
and OpenBSD would be rather very vague and older
licenses stay longer.

This is due to the dierence ofdevelopment management.

FreeBSD and OpenBSD

have been developed with many contributed source-

4. EMPIRICAL RESEARCHES

code les, and Eclipse has been developed with moreRelease Version

FreeBSD

OpenBSD

EclipseArgoUML

2.2-8.0

2.0-4.7

2.0-3.5.2

0.8.1-0.31.1

Release Date

1994/11-2009/11

1996/10-2010/5

2002/6-2009/9

2000/10-2010/6

Type

OS kernels, drivers

OS kernels, drivers

SDE platform

UML Design Tools

and compilers

and compilers# releases

45

28

25

79

# Files(oldest-latest)

6245-14181

4412-21266

11419-35880

686-2208

VCS

CVS

CVS

CVS

Subversion

Table 2: Characteristics of analyzed application in this study

16000

25000

14000

20000
12000

10000

#files#files

15000
8000

10000

6000

4000

5000
2000

0

0
2.0 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 3.0 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 4.0 4.1 4.2 4.3 4.4 4.5 4.6 4.7

Release Version
Release Version

GPLv2+
BSD4
LibraryGPLv2+

BSD2
Others

BSD3
NONE

BSD3

BSD4

BSD2

MITold1

OthersNONE

UNKNOWN

GPLv2+UNKNOWN
Figure 2: the license ratio of OpenBSD

Figure 1: the license ratio of FreeBSD
We calculated the dierence of the number of les between
strict control in accordance with Eclipse Development
Process[3]. The dierence between CPLv1.0 and EPLv1.0
is removing most of conditions on patent.

So, thischange relaxes the condition of the license.

• In ArgoUML (Figure 4), there are many UNKNOWN
les through the evolution.

Further analysis showedthat those are mostly BSD-like license, but not thesame as commonly used ones such as BSD4, BSD3,

a version and its next version. In this analysis, we did notcount les categorized as NONE, UNKNOWN and Other.
Figure 5 shows the changes of the number of FreeBSD lesand Figure 6 presents that of OpenBSD. In these graphs,
X-axis represents release version and Y-axis represents thedierence of the number of les between a version and its
previous version. Some of the ndings are as follows.

• In the case of FreeBSD, the reduction of BSD4 happened periodically, and BSD2 and BSD3 have increased

and BSD2. By adding new meta-sentences and higher-

in response to such reductions. A detailed analysis oflevel matching pattern to the database, Ninka can now
identify them.

Release Version 5.2.1 to 5.3 shows that total 531 BSD4

However, we have not sucient timeles have been changed to 423 BSD3 les, 13 BSD2

to re-run this experimentation. So, we show originaldata.

BSD license has not copy-left.

les, and 95 obsolete les.

However, EPL

has copy-left which regard source le under EPL modied or added as derivative software. So, this change
which showed in this case tightens the condition of thelicense.

• Also in the case of FreeBSD, GPLV2+ and LibraryGPLv2+ were deleted and BSD2 ∼ 4 are added.
• In the case of OpenBSD, the reduction of BSD4 iscompensated with GPLv2+ and MITold1. A detailed

Answer for RQ1: Licenses in the operating systems (FreeBSD,

analysis shows that from Release Version 3.3 to 3.4,

OpenBSD) are rather diverse and loosely controlled, com-

total 2255 les have been changed to 1957 BSD3 les,pared to non-OS systems (Eclipse, ArgoUML). A few li-

271 BSD2 les, and 27 obsolete les (KerberosV les).

censes cover almost all les in those systems, and sometimes
those licenses are drastically changed to others by the strong

Answer to RQ2: Detail analysis of the evolution of licenses

management to the overall system. And, the change relaxes

in these two operating systems shows that there are period-or tightens the condition of the license.

ical large shifts of licenses, along with system evolution.

4.2 RQ2

4.3

Based on the result for RQ1, We examined the changes of
the number of les under each license.

RQ3

In section 4.1, we have shown existence of various licenses
in the operating systems.

We do not know whether those

800

45000
40000

600
35000

400

200

25000

#files#files

30000

20000

0

15000

-200
10000

-400
5000

-600

0

-800

Release Version

Release Version

EPLv1

CPLv0.5

CPLv1

MPLv1_1

BSD3

OthersNONE

BSD4

UNKNOWN

BSD3

BSD2

GPLv2+

LibraryGPLv2+

Figure 5: the changes of the license ratio of FreeBSD

Figure 3: the license ratio of Eclipse

1500

2500

1000
2000

500

#files1500

0#files

2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 3.0 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 4.0 4.1 4.2 4.3 4.4 4.5 4.6 4.7
1000

-500

-1000

500

-1500
0.31.1

0.29.40.29.1

0.27.30.26.20.25.60.24

0.25.30.22

0.23.30.21.1

0.19.70.19.40.18.1

0.17.40.17.1

0.15.6

0.15.30.14.1

0.13.50.13.2

0.11.40.9.9

0.11.1

0.9.6

0.9.2

0.8.1

0

-2000

Release Version
-2500

EPLv1
LesserGPLv2.1+

Apachev2
OthersBSD2
UNKNOWN

Release Version

LesserGPLv2.1
NONE

BSD4

Figure 4: the license ratio of ArgoUML

BSD3

BSD2

GPLv2+

MITold1

Figure 6: the changes of the license ratio of OpenBSD

dierent licenses appear in the kernel part of those operating
systems.

The kernels have been developed generally in awell- controlled environment and it is supposed that there
exist fewer licenses with drastic change pattern.

We haveapplied the approach used in the RQ1 to the source lesof both OpenBSD kernel and FreeBSD kernel.

Those areabout 10% ∼ 25% les of the total operating systems.

Figure 7 shows the license ratio of kernel of FreeBSD andgure 8 shows OpenBSD.
Findings are as follows.

• Both kernels include various licenses with similar pattern as the overall operating systems.

• Also similar to the operating systems, the kernel li-

One of threats to validity is the accuracy of the result
from Ninka. Daniel et.al.[6] reported that Ninka's accuracy
is 93%. We think that this is suciently high, so that theidentication errors of Ninka do not seem to aect the license
rations discussed in Section 4.
Other threat to validity is selection of applications. We
use FreeBSD and OpenBSD as the targets of the operating
systems. Although they have the same root, 386 BSD, they
started to go dierently ten years ago (FreeBSD started in1991 and OpenBSD started in 1995.) with dierent development policies. Therefore, we think that they are related but
dierent operating systems with dierent license policies.
We use four systems. This is too small to make general-censes have been changed continuously and periodi-

ize the result of this empirical study. To regard this resultcally. The patterns of Figure 5 and 6 are more similar

as general result, we must apply similar empirical study toto those of Figure 1 and 2, and not similar to Figure

many other samples.

3 and 4.
Answer to RQ3: Kernel part of the operating systems have
similar evolutional pattern of their licenses to the overall
operating systems.

6.

RELATED WORKS
Di Penta et.al.[2] proposed a method to track changes in

the license terms.

It showed that license is changed fre-quently and many times.

5. THREATS TO VALIDITY

In this research, they analyzed

each revision of each le and identify many patterns of li-

#file4000

of license as a tuple ⟨actor，operation，action，object⟩ and3500

calculates propagation and conict of duty. German et.al.[5]3000

have formally dened software licenses and their patterns to2500

resolve license mismatch.

German et.al.

[4] have also in-

troduced a method to help to understand license mismatch
2000

occurred in software packages and to audit license mismatch

1500

problem in binary packages of Fedora 12. Our research did

1000

not deal with license mismatch. However, the result of ourwork may emphasize the risk of license mismatch and the500

importance of identifying licenses.
07.

Release Version

BSD2
CDDLicBSD3Others

BSD4
NONE

CONCLUSIONSThis paper presents the evolutional pattern of licenses inInterACPILicUNKNOWN

the source-code les of large-scale FOSS. By this license
analysis, we found that the evolutional patterns of the operating systems are dierent from those of non-operating sys-

Figure 7: the license ratio of kernel of FreeBSD

tems such as Eclipse and ArgoUML. The changes of licenses
in those operating systems occur periodically and continuously, and such pattern can be also seen in the kernel evo-

3500

lution.
As a future work, at rst we apply similar empirical study

3000

to many other systems. Then, we are planning to conduct

2500

more ne-grained analysis for changes. Especially, we will
#files2000

examine the cases of drastic change between two neighborversions, e.g., FreeBSD Release Version 5.2.1 and 5.3, and

1500

OpenBSD Release Version 5.3 and 5.4.
1000

8.

500

ACKNOWLEDGMENTS
This research was supported by Japan Society for the0
2.0 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 3.0 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 4.0 4.1 4.2 4.3 4.4 4.5 4.6 4.7

Release Version

BSD4

BSD2

BSD3

MITold1

MITold2

OthersNONE

UNKNOWN

Promotion of Science, Grant-in-Aid for Scientic Research(A) (No.21240002). This research was supported in part byGlobal COE (Centers of Excellence) Program of the Ministry of Education, Culture, Sports, Science and Technology,

Figure 8: the license ratio of kernel of OpenBSD

Japan.

9.

REFERENCES

cense changes between rst version and last version in target[1] T. A. Alspaugh, H. U. Asuncion, and W. Scacchi.

releases. On the other hand, our work shows the change of li-

Analyzing software licenses in open architecture

cense among releases of each system. The results show thatsoftware systems. In Proc. FLOSS 2009, pages 5457,

there are large-scale change between two releases and twolicenses. And, their work concludes that les of ArgoUML

Washington, DC, USA, 2009.
[2] M. Di Penta, D. M. German, Y.-G. Guéhéneuc, andare not changed very much. However, our work shows that

G. Antoniol. An exploratory study of the evolution ofin newer release, a large scale change occurs.

software licensing. In Proc. ICSE 2010, Cape Town,

In our re-search, we have successfully shown that such pattern occurs

South Africa, 2010.

through the evolution and the license ratio changes some-[3] Eclipse Foundation. Eclipse Development Process.

times drastically or gradually based on the distinction of

http://www.eclipse.org/projects/dev_process/

FOSS types. On the other hand, though their work has examined a change of year included in copy right description,
our work has not examined.
Some previous works deal with license ratio. Gobeille[7]introduce FOSSology which identies each license of sourceles with bSAM algorithm. He has applied it to abiword-2

2.6.4 as an example. Black Duck Software

reported daily

top 20 most commonly used licenses in open source projects
according to the Black Duck software knowledgebase. Our
research is dierent from these works in the sense that we
focus on large scale software systems with many release versions.
Also, some previous works deal with license mismatch.
Alspaugh et.al.[1] introduced a method which describes terms

2

http://www.blackducksoftware.com/oss/licenses#top20

development_process.php, 2010. Accessed June. 2010.
[4] D. M. German, M. Di Penta, and J. Davies.
Understanding and auditing the licensing of open
source software distributions. In Proc. ICPC 2010,
pages 8493, Braga, Portugal, 2010.
[5] D. M. German and A. E. Hassan. License integration
patterns: Addressing license mismatches incomponent-based development. In Proc. ICSE 2009,
pages 188198, 2009.
[6] D. M. German, Y. Manabe, and K. Inoue. A
sentence-matching method for automatic license
identication of source code les. In Proc. ASE 2010,2010. (To appear).
[7] R. Gobeille. The FOSSology project. In Proc. MSR
2008, pages 4750, New York, NY, USA, 2008. ACM.

[8] C. Run and C. Ebert. Using open source software in
product development: a primer. IEEE Software,21(1):8286, 2004.