VOL. E104-D NO. 2
FEBRUARY 2021
The usage of this PDF file must comply with the IEICE Provisions
on Copyright.
The author(s) can distribute this PDF file for research andeducational (nonprofit) purposes only.
Distribution by anyone other than the author(s) is prohibited.

IEICE TRANS. INF. & SYST., VOL.E104–D, NO.2 FEBRUARY 2021

254

PAPER

An Exploratory Study of Copyright Inconsistency in the Linux
Kernel
Shi QIU†a) , Daniel M. GERMAN††b) , Nonmembers, and Katsuro INOUE†c) , Fellow

SUMMARY
Software copyright claims an exclusive right for the software copyright owner to determine whether and under what conditions others can modify, reuse, or redistribute this software. For Free and Open
Source Software (FOSS), it is very important to identify the copyrightowner who can control those activities with license compliance. Copyright notice is a few sentences mostly placed in the header part of a source
file as a comment or in a license document in a FOSS project, and it is an
important clue to establish the ownership of a FOSS project. Repositories
of FOSS projects contain rich and varied information on the development
including the source code contributors who are also an important clue toestablish the ownership. In this paper, as a first step of understanding copyright owner, we will explore the situation of the software copyright in theLinux kernel, a typical example of FOSS, by analyzing and comparing two
kinds of datasets, copyright notices in source files and source code contributors in the software repositories. The discrepancy between two kindsof analysis results is defined as copyright inconsistency. The analysis result has indicated that copyright inconsistencies are prevalent in the Linuxkernel. We have also found that code reuse, aﬃliation change, refactoring,support function, and others’ contributions potentially have impacts on theoccurrence of the copyright inconsistencies in the Linux kernel. This study
exposes the diﬃculty in managing software copyright in FOSS, highlighting the usefulness of future work to address software copyright problems.
key words: software maintenance, mining software repositories, open
source software, software copyright1.

Introduction

Software copyright grants the copyright owner a legal rightto determine under what conditions this software can beredistributed, reused, and modified with the help of software licenses. Diﬀerent from proprietary software, FOSS
projects are developed in a collaborative manner, receiving
contributions from a large number of people, named contributors, from diﬀerent countries or regions, or diﬀerent organizations. For example, the Linux kernel is contributed by
21,074 diﬀerent contributors at the end of 2019, and thosecontributors have the potential to claim the copyright of thecontributed software [1]. In this paper, we name the individuals or organizations explicitly declared in copyright notices
as the holders, and the individuals or organizations who acManuscript received May 13, 2020.
Manuscript revised September 30, 2020.
Manuscript publicized November 17, 2020.
†
The author is with the Graduate School of Information Science and Technology, Osaka University, Suita-shi, 565–0871
Japan.
††
The author is with the Department of Computer Science, University of Victoria, Victoria, BC V8P 5C2, Canada.
a) E-mail: qiujitsu@ist.osaka-u.ac.jpb) E-mail: dmg@uvic.cac) E-mail: inoue@ist.osaka-u.ac.jp
DOI: 10.1587/transinf.2020EDP7107

tually own the copyrights as the copyright owners.
In general, the holders are seen as the copyright owners. However, the holders may not cover all contributors
who could potentially become the copyright owners. So
identifying the copyright owners of FOSS only by the holders is insuﬃcient. Therefore, an important question in the
copyright ownership problem of FOSS is: “Who are the actual copyright owners?” Identifying the copyright owner of
FOSS is important for several reasons: a) only the copyrightowner of FOSS is allowed to change its license or granting a commercial one to a third party, such as Oracle grantscommercial licenses to MySQL∗ [2]; b) only the copyrightowner of FOSS is allowed to start legal proceedings to enforce its license; c) several FOSS licenses (e.g. the BSD
family of licenses) require that the copyright owner of FOSS
projects being reused be acknowledged in the documentation and other materials of the system that reuses it.
In recent years, some developers who once contributed
to large FOSS projects have enforced the open source license against the distributors who use the FOSS. Thesecharges are based on the terms of the highly restrictive open
source licenses. These distributors may face lawsuits andpotential monetary penalties if they ignore or violate theterms of these restrictive licenses. For example, Patrick
McHardy - a developer of the Linux kernel - has sued somecompanies, claiming that he shares a great part of the authorship of the Linux kernel [3], [4]. While it is easy tofind his copyright notice existing in some source files, it is
not easy to identify what portions of his contributions still
remain in the current kernel. In other words, his declaration of the copyright notice may be inconsistent with his remained contributions. Therefore, the question arises: “Arethese developers enforcing the open source license against
the distributors the actual copyright owners of redistributed
FOSS projects?” To address this problem, both the open
source community and the industry invested a great amountof eﬀort. For example, an open source license compliancesoftware system and toolkit called FOSSology∗∗ have beendeveloped to detect the copyright notice buried in the sourcecode [5]. BlackDuck∗∗∗ also provides a service of assessing
the legal risks of software copyright to those who want tocommercially reuse FOSS.
However, establishing copyright ownership in large∗

https://www.mysql.com/
https://www.fossology.org/∗∗∗
https://www.blackducksoftware.com/∗∗

c 2021 The Institute of Electronics, Information and Communication Engineers
Copyright QIU et al.: AN EXPLORATORY STUDY OF COPYRIGHT INCONSISTENCY IN THE LINUX KERNEL

255

FOSS projects and verifying whether the statement of a
copyright notice is correct are complicated. On one hand, as
we mentioned below, the contributors, who could potentiallybecome the copyright owners as well, can not be totally covered by the holders. On another hand, since the large FOSS
projects are usually co-developed by a large number of developers during a long period, the copyright notices potentially risk the poor management and can not refer to the actual copyright ownership. For example, a copyright notice
can be added when a contributor contributes source code toa FOSS project, but if the contributed source code is totally
deleted from this FOSS project, the added copyright notice
is possibly left in the source file since the developer who did
this deletion may not know which part of source code is governed by this copyright notice. In these cases, the copyrightnotices will denote copyright ownership incorrectly. The inconsistency between the holders in the copyright notices andthe contributors of the source code (called copyright inconsistency or simply inconsistency) plays an important role inthe diﬃculty of establishing copyright ownership in large
FOSS projects.
In this paper, as a first step of understanding copyright ownership, we analyze copyright inconsistencies of theLinux kernel, which is a typical example of FOSS. To thebest of our knowledge, no work has been done to go deep
into copyright inconsistency. Only a few works analyzed therelationship between the contributors and the holders [6],which are insuﬃcient to reveal some important problems
about this issue such as how prevalent copyright inconsistencies are in FOSS and why copyright inconsistencies occur. Also, we want to know whether the statements of copyright notices are accurate and truly denote the contributors’
contributions to the source files that contain them.
To achieve our goal, we must first identify the holders
and contributors. The holders in copyright notices can bedetected from the copyright notices directly. While identifying the contributors is much more diﬃcult since tracking
the “original” authors of the source code is a diﬃcult task insoftware engineering as well. Here we use the committers
who can be tracked in software repositories as an indicatorof the contributors. The diﬀerence between committer andcontributor is that committer is the developer who commits
the source code while the contributor is the developer who
actually writes the source code. Both of them could be thepotential copyright owner who actually owns the copyrights.
Although the committers are not always consistent with thecontributors, they are the only explicit information we canobserve in software repositories directly. We will explore
the cases that a developer commits source code written byothers in our empirical study. Using the committer can help
us to conduct a quantitative analysis to study the copyrightinconsistency because the holders and contributors are twomost explicit pieces of information we can rely on to establish the ownership of the source file.
Table 1 summarizes all the roles introduced in this paper.
Based on these questions, we first define and catego-

Table 1

Summary of the roles introduced in this paper.

Role
Copyright owner
HolderContributor
Committer

Definition
Who actually owns the copyrights.
Who is explicitly declared in copyright notices.
Who actually writes the source code.
Who commits the source code to repositories.

rize the copyright inconsistency formally. We then conduct
an empirical study to study copyright inconsistency. Our
research questions are set as follows:
RQ1: How prevalent are copyright inconsistencies?
RQ2: What caused the copyright inconsistencies?
The contributions of this paper are as follows:
1. We have made the first study to focus on the prevalence of copyright inconsistencies, relying a proposed analysis method to detect and study them.
2. We have also conducted an empirical study on theLinux kernel to find the reasons.
This paper is organized as follows. Section 2 firstprovides a brief background on copyright notices in FOSS
projects, after which Sect. 3 proposes the definition of copyright inconsistency. Our empirical study on the Linux kernel
is described in Sect. 4, followed by Sect. 5 with a discussionof the results. Section 6 describes threats to validity. After a
description of related work in Sect. 7, Sect. 8 concludes thispaper.
2.

BackgroundIn this section, we have a look at the practical situation of
copyright notices and committers in the FOSS project.
2.1 Copyright Notices in FOSS Projects
A copyright notice is a sentence to declare the holders explicitly. Generally, a copyright notice begins with the word
“Copyright” or a copyright sign “(C)”, followed by thenames of the holders. The valid year of this copyright notice
is usually stated in the copyright notice as well. An exampleof the copyright notice in FOSS is as follows:## Copyright (C) 2011-2013 Free Software# Foundation, Inc.
#
# 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 2, or (at your option)# any later version.
#
This copyright notice declares that the Free Software
Foundation owns the copyright of this software. A FOSS
license is stated with the copyright notice as well.
Usually, these holders are seen as owning the copyright. Note that in this paper, holders refer to the individu-

IEICE TRANS. INF. & SYST., VOL.E104–D, NO.2 FEBRUARY 2021

256

als or organizations explicitly declared in copyright notices.
While copyright owners refer to the individuals or organizations who did own the copyrights. The holders may notalways be consistent with the copyright owners.
Similar to other types of properties, copyright can besold and transferred. Diﬀerent FOSS projects have diﬀerent rules on copyright transfer. Some FOSS projects require
their developers to transfer the copyright of their contributions. For example, Oracle - the copyright owner of MySQL- requires all contributors to transfer the copyright of theircontributions when they make the contributions [7]. This
strict requirement ensures Oracle to be the only copyrightc 2019, Oracle Corporation and/or its
owner. Therefore, “aﬃliates” is the only copyright notice of MySQL, declaringthat the holder, also the copyright owner, is Oracle Corporation and/or its aﬃliates. By having this only ownership of
MySQL, Oracle is also able to oﬀer commercial licenses.
However, most FOSS projects do not force the copyright transfer. They receive contributions from a large number of contributors, which makes establishing the ownershipof FOSS more complicated. Therefore, a FOSS project may
be copyrighted under from one to hundreds of copyright notices.An example is the Linux kernel where a lot of copyright notices can be observed. Meanwhile, these copyrightnotices are usually declared using some particular pattern.
The situations of many other FOSS projects are similar to
the Linux kernel.
2.2

Source Code Committers in FOSS Projects

Modern software development is usually participated by a
lot of developers. The large FOSS projects are also developed in a collaborative manner, receiving commits from alarge number of committers. For example, in the case of
the Linux kernel, the Linux foundation - the organization
dedicated to maintaining the Linux and other related FOSS
projects communities - reported that over 15,600 developers from more than 1,400 companies have contributed to theLinux kernel since tracking began 11 years ago [8]. Version
control systems such as git† , usually have a feature known
as “blame”, to track who nominally commits certain lines ofcode to the repositories. To track the contribution at a moregranular level of code tokens, a tool named cregit is developed to track the committer, time, and commit log of eachtoken in source file [9].
In our following study, we rely on cregit to construct
the dataset. Table 2 shows an example of the extracted information using cregit to a source file named generic.h in theLinux kernel. It is easy to know the list of the committers,
and the proportion of the contribution of each committer.
For example, Arnd Bergmann contributed 170 tokens to thesource file, accounting for 80.6% of all tokens, and committed thrice, accounting for 27.3% of all commits.
†

https://git-scm.com/

Table 2

3.

Result of using cregit on generic.h.

Person#TokenT.Prop#Commit

C.PropArnd Bergmann
Viresh Kumar
Russell King
Robin Holt
Shiraz Hashim
Masahiro Yamada
Total

170
29
5
5
1
1
211

80.6%
13.6%
2.4%
2.4%
0.5%
0.5%
100.0%

3
4
1
1
1
1
11

27.3%
36.3%
9.1%
9.1%
9.1%
9.1%
100.0%

Copyright Inconsistency

In this section, we make a precise definition of copyrightinconsistencies and categorize them.
3.1 Definition
For the purpose of this research, copyright inconsistency
refers to the inconsistency between the holders and the committer. The holders refer to the individuals or organizations
explicitly declared in copyright notices according to our definition. The committers refer to the individuals who committed the source code to repositories.
3.2 Categorization
In many FOSS projects, copyright inconsistencies can beobserved easily. Here we still take the source file generic.hin Linux kernel, as the target source file to observe. The
header comments of this source file are as follows:/** spear machine family generic header file** Copyright (C) 2009-2012* ST Microelectronics* Rajeev Kumar <rajeev-dlh.kumar@st.com>* Viresh Kumar <vireshk@kernel.org>** This file is licensed under the terms of* the GNU General Public License version 2.
* This program is licensed "as is" without* any warranty of any kind, whether express* or implied.
*/
It is easy to know that the holders are ST Microelectronics, Rajeev Kumar, and Viresh Kumar. Note that possibly Rajeev Kumar is an employee of ST Microelectronics
according to the domain of his email address. We then extract the committers relying on cregit. The committersand the proportion of their contributions to the source files
are shown in Table 2.
We can observe that inconsistencies happened in two
ways.
Firstly, we can not find any hints about the ST Microelectronics and Rajeev Kumar - both seen as the holders-QIU et al.: AN EXPLORATORY STUDY OF COPYRIGHT INCONSISTENCY IN THE LINUX KERNEL

257

in the committers. Their actual contributions to this source
files are not clear. It may be a possible reason that their
copyright notices are wrongly declared or just out of date.
Secondly, a lot of committers- Arnd Bergmann, Russell King, Robin Holt, Shiraz Hashim, and Masahiro Yamada - did not declare their copyright notices in the source
file. This resulted in a problem that the ownership of thissource file can not be established since we have no knowledge about the contributions of the committers to this source
file. Especially, the copyright notice of Arnd Bergmann,
who committed more than 80% source code to the source
file by tokens, is not declared in the source as well. Establishing the ownership of a source file without regarding acommitter who committed a large part of source code suchas Arnd Bergmann is not wise.
So establishing the ownership of a source file only by
the copyright notices is not suﬃcient. Some may argue thatthe committer such as Shiraz Hashim or Masahiro Yamada
committed too few source codes. Therefore, the proportionof their commits can not support them to become the qualified committers and declare their ownership of this source
file. We will have a discussion on this proportion in our empirical study in Sect. 4. These two types of inconsistencies
between the holders and the committers can be observed inmany other observed source files as well.
Based on the observation of Linux kernel, we observed
two types of copyright inconsistency. One is the situation that the holder is not the committer (i.e. holder-notcommitter inconsistency). Another one is the situation thatthe committer is not the holder (i.e. committer-not-holder
inconsistency).
Note that if the organizations the committer belongs to
are declared in the copyright notices, we determine there isno inconsistency in this situation. A quantitative and executable analysis of the copyright inconsistency could be
conducted based on the proposed definition and categorization.
4.

Empirical Study

The goal of this section is to introduce our analysis methods
to answer research questions. To achieve this goal, we selectthe Linux kernel - the most popular and successful opensource operating system kernel - to analyze. Table 3 showsa summary of the target version of the Linux kernel.
4.1

Research Questions

This empirical study aims at addressing the following research questions:
RQ1: How prevalent are copyright inconsistencies?
This research question investigates the prevalence of copyright inconsistencies in the Linux kernel. Copyright inconsistencies will be detected using the proposed method, followed by quantitative analysis.
RQ2: What caused the copyright inconsistencies? This
research question aims at finding the reasons causing theTable 3

Summary of the target version of the Linux kernel.
Version
Date
#File

4.14
Nov 13, 2017
45,477

copyright inconsistencies in the Linux kernel. The results
reveal the reasons by a qualitative analysis manually tracking the historical commit logs of the source files.
4.2 Dataset Construction
To achieve our goal, we first construct the datasets for our
empirical study. The dataset construction is consists of threesteps - sampling, building the committer dataset, and building the holder dataset.
4.2.1

Sampling

We first download the source code of the Linux kernel from
Github† . Notice that we only collect the source files whoselife cycle can be entirely traced in Github. Some source files- known as pre-git files - have been created and evolved before the source code was uploaded to Github. Those pre-git
files are not our target source files. This step makes copyright notices trackable, which helps us in answering the research questions. We end up with 38,932 source files after removing pre-git files from the total downloaded source
files. We aim to construct a sample dataset by randomly selecting source files from these 38,932 source files. We use
a statistical method to determine the sample size needed inorder to get results that reflect the target population as precisely as needed. The required sample size was calculated sothat our conclusions would generalize to all 45,477 source
files with a confidence level of 95% and a confidence interval of 5†† . The calculation of statistically significant sample sizes based on population size, confidence interval, andconfidence level is well established. The calculated required
sample size is 381. At last, we randomly select 500 source
files from 38,932 non pre-git files to construct the sample
dataset.
Among these 500 source files, a part of source files’
histories can not be tracked because of the mechanism ofgit. Git keeps track of changes to files in the working directory of a repository by their names. When a file is moved
or renamed, git sees it as a creation of a new file while theoriginal file is deleted. Since our analysis required the traceability of the entire history of a source file, we only selectthe source files which are not moved or renamed before. By
removing source files once moved or renamed, we end up
with a sample dataset consist of 414 source files. This number is still larger than 381 - the minimum required numberof statistically significant sample size.

†††

https://github.com/torvalds/linux
https://www.surveysystem.com/sscalc.htm

IEICE TRANS. INF. & SYST., VOL.E104–D, NO.2 FEBRUARY 2021

258
Table 44.2.2

Building the Committer Dataset

In this step, we build the committer dataset. For each source
file in the sample dataset, we extract the full name, number of tokens they contributed, and the proportion of thiscontribution for each committer using cregit. Note that acommitter may have multiple diﬀerent accounts in GitHub.
We rely on cregit to solve this problem. cregit extracts
the committer’s full name and use it as the unified identifier
to merge the multiple diﬀerent accounts owned by the samecommitter. We then extract the e-mail address of each committer by tracking the historical commit logs of the source
file.
Lastly, we identify the organizations the committersbelong to by checking the domain of their e-mail addresses.
We use a semi-automatic method to achieve this goal. A
domain dictionary is built to map the domain of the e-mailaddresses to the organizations. When we try to identify theorganization of a committer, we first check if the domain of
his or her e-mail address is in the domain dictionary or not.
If so, we determine the corresponding organization as theorganization the committer belongs to. Otherwise, we manually check this domain and identify the organization forthis committer. The pair of the domain and the organizationis added into the domain dictionary at the same time. Notethat here an organization is indicated by a uniform identifier.
In this way, we build the committer dataset. All source
files are contained in this dataset. For each of them, we list
his or her full name, the number of tokens he or she contributed, the proportion of the contribution, e-mail address,
and the organization he or she belongs to. During this process, we successfully build a domain dictionary as well.
4.2.3

Building the Holder Dataset

In this step, we build the holder dataset for each source filein the sample dataset. Note that we have built the committer
dataset containing the full names of all committers and theuniform identifiers to indicate the organizations they belong
to. We first use FOSSology [5] to detect the copyright notices, after which we manually check all detected copyrightnotices to remove the wrongly detected ones.
Then next, we build an organization dictionary shownin Table 4. The index is the uniform identifiers of the organizations. Each of the uniform identifiers refer to a listof possible organization names found in the analysis. The
organization names are the diﬀerent ways one organization
might be referred to in copyright notices. In the beginning,
the list only contains one name that we find in building thecommitter dataset.
We then match the full name of each committer toeach detected copyright notice. We achieve this by checking
whether the full name is included in the detected copyrightnotice or not. Note that this check is not case-sensitive. If wefind the full name of one committer in the detected copyrightnotice, we determine it as the holder of this copyright no-

A part of the built organization dictionary.

Index

List

ibm

IBM Corporation
IBM Corp.
International Business Machines Corp.

amd

Advanced Micro Devices, Inc
AMD, Incti

Texas Instruments, Inc.
TI, Inc

tice. At the same time, the type of this holder is determined
as individual. For the remaining copyright notices, we try tomatch them to the organization names in all lists in the organization dictionary. If an organization name is matched,
we determine the index - the uniform identifier refers to thelist containing this organization name - as the holder. At thesame time, the type of this holder is determined as organization.
After these two matches, we try to manually identify
the holders and their types for the remaining copyright notices. If the manually identified organization name has got
a uniform identifier in the organization dictionary, we determine this uniform identifier as the holder. Meanwhile, we
add this manually identified organization name into the listthat the uniform identifier refers to. If the manually identified organization name has not got a uniform identifier inthe organization dictionary, we create a new uniform identifier as the index and add this manually identified organization name into the list the newly created uniform identifier refers to. Finally, we build a holder dataset, for eachsource file in which the holders and the information about
their related copyright notices and their types (individual ororganization) are summarized.
During this process, we successfully build an organization dictionary at the same time. Table 4 shows a part of thebuilt organization dictionary constructed during the analysisof the Linux kernel.
4.3 Analysis Method
To answer RQ1, we detect the copyright inconsistencies
based on the built committer dataset and holder dataset.
Based on the definitions in Sect. 3.1, we detect two types of
copyright inconsistencies respectively - the committer-notholder inconsistency and the holder-not-committer inconsistency.
To achieve our goals, we propose two definitions ofcommitter for the detection of two types of copyright inconsistency. General committers refer to all committers who
once committed source code. This definition will be usedin the detection of the holder-not-committer inconsistency,
which ensures that the holder-not-committer inconsistency
can only be detected when we can not find any information
about the holder in the committer dataset. Core committersrefer to the committers who contributed more than a mini-QIU et al.: AN EXPLORATORY STUDY OF COPYRIGHT INCONSISTENCY IN THE LINUX KERNEL

259

mum threshold percentage of contribution. Setting a minimum threshold percentage of the contribution could exclude
the minor committers who only do some simple work, anddetermines the core committer from a general committer.
We will set this minimum percentage as 14.9% because it is
the least percentage of source code at the token granularityof the contributor who committed the highest percentage ofthe source code in the sample dataset. This definition will
be used in the detection of the committer-not-holder inconsistency.
We first detect the holder-not-committer inconsistency.
For each holder in the holder dataset, we check whether thisholder is a name of any general committer or an organization that any general committer belongs to. A holder-notcommitter inconsistency is detected if a holder is neither aname of any general committer or an organization that any
general committer belongs to.
We then detect the committer-not-holder inconsistency.
For each core committer in the committer dataset, we check
whether its name or organization is recorded in the holder
dataset or not. A committer-not-holder inconsistency is detected if neither a core committer’s name nor its organizationis recorded in the holder dataset.
To answer RQ2, we try to find the reasons behind theoccurrence of the holder-not-committer inconsistency andthe committer-not-holder inconsistency respectively. For
each inconsistency, we manually check the commit logs andthe comments in the source code of the source files to findout the reasons. A reason is determined only when it isexplicitly recorded in the commit logs or the comments insource code.
5.

Results

In this section, we report the results and have a discussion
on the results to address research questions in our empirical
study in Sect. 4.
5.1

RQ1: How Prevalent Are Copyright Inconsistencies?

In this research question, we analyze to what extent copyright inconsistencies exist in source files in the Linux kernel.
As can be seen from Table 5, 262 source files are detected as having copyright inconsistencies, accounting for63.3% of all 414 source files. As a popular and well maintained OSS project, the copyright ownership of the Linuxkernel should be clear and well maintained as well. The general image of the Linux communities is that there is not too
much copyright inconsistency in the Linux kernel. An ideal
situation is expected that there is no inconsistency. However,this result is out of our expectation and do not accord withthe general image of the communities, which suggests thatcopyright inconsistencies are prevalent in the Linux kernel.
We can see that 134 source files are detected as having the holder-not-committer inconsistency, accounting for32.4% of all 414 source files in sample dataset, and 51.1%
of 262 source files detected as having any type of inconsis-

Table 5 The number of source files with diﬀerent types of copyright1 means the ratio of the sourceinconsistencies and the ratios. Ratio to 
files detected as having this type of inconsistency to all source files in the
4 means the ratio of the source files detected as
sample dataset. Ratio to 
having this type of inconsistency to the source files detected as having any
type of inconsistency.
No

Inconsistency#Files1
Ratio to 1
sample dataset

414

100.0%

2

3

4

5


holder-not-committercommitter-not-holder
any type of inconsistency
both two types

134
229
262
101

32.4%
55.3%
63.3%
24.4%

4
Ratio to 

51.1%
87.4%
100.0%
38.5%

tencies respectively. We can also see that 229 source files
are detected as having the committer-not-holder inconsistency, accounting for 55.3% of all 414 source files in sample
dataset, and 87.4% of 262 source files detected as having
any type of inconsistencies respectively. It can be noticed
that the committer-not-holder inconsistency is more prevalent than the holder-not-committer inconsistency.
It is also easy to know that 101 source files are detected
as having both of two types, accounting for 24.4% of all
414 source files in sample dataset, 38.5% of 262 source files
detected as having any type of inconsistencies, 75.3% of
134 source files detected as having the holder-not-committerinconsistency, and 44.1% of 229 source files detected ashaving the committer-not-holder inconsistency respectively.
The result suggests that if the holder-not-committer inconsistency exists in a source file, there is also a high possibilityof the occurrence of the committer-not-holder inconsistency.
Oppositely, if the committer-not-holder inconsistency exists
in a source file, there is no such high possibility of the occurrence of the holder-not-committer inconsistency. It may
be a possible reason that for the source files detected as having the holder-not-committer inconsistency, the committers
added others’ copyright notices. Another possible reason
may be that after a long time of software evolution, a lotof new source code is committed, and the new source code
replaced the old source code committed by the committers
before. We will investigate the reasons in RQ2.
As an answer to RQ1, copyright inconsistencies areprevalent in the Linux kernel, among which, the committernot-holder inconsistency is more prevalent than the holdernot-committer inconsistency.
5.2 RQ2: What Caused the Copyright Inconsistencies?
We aim to find the reasons why copyright inconsistencies happened. To achieve this goal, for the holder-notcommitter inconsistency, we manually check the commit
logs and the comments in the source code of all 134 source
files detected as having the holder-not-committer inconsistency. If a reason is explicitly recorded in a sentence, wenote down that sentence. After that, we categorized all sentences to summarize the reasons.
For the committer-not-holder inconsistency, we selectIEICE TRANS. INF. & SYST., VOL.E104–D, NO.2 FEBRUARY 2021

260

some source files detected as having the committer-notholder inconsistency as the target. These source files should
also satisfy the condition that no holder-not-committer inconsistency is detected. We end up with 128 source files.
For these files, all holders are the committers, so we plan toinvestigate the other committers who are not holders to find
why they are not recorded in copyright notices. Diﬀerent
from the holder-not-committer inconsistency, holders who
did not add their copyright notices usually did not explain
their reasons explicitly. So we try to find some hints about
why holders did not add their copyright notices no matterthey are explicit or not. We then categorized all sentences tosummarize the reasons as well.
Table 6 shows the summarized reasons why holder-notcommitter inconsistencies happened. Among them, code
reuse and refactoring are two common activities in softwaredevelopment. It is possible that copyright notices are notwell managed during these activities.
To our surprise, aﬃliation change - the change of thecompanies or organizations the developers belong to - plays
an important role in the occurrence of the copyright inconsistency, which reveals that the management of copyright notices may be overlooked by the developers as well.
The “aﬃliation change” is found when we observed that although the developer’s aﬃliation identified by e-mail address is not consistent with the one in the copyright noticecurrently, this developer’s aﬃliation may be consistent withthe one in the copyright notice before. Specifically, we observed four cases: (1) The developer switches to a diﬀerent company or organization. (2) The developer belongs
to more than one company or organization. (3) The company or organization is merged into another one. (4) The
developer uses a personal e-mail address. All these cases
can be found by checking the commit logs, the commentsin the source code of the source files, and the profiles ofthe developers. We also try to search the related information on the Internet (e.g. the information of the developer
on LinkedIn† , the information of the company or organization in Wikipedia†† , etc.) to endorse our findings. Note that
we do not explore the reasons why “aﬃliation change” happens and whether possible legal risks exist. Developers may
just forget to update the copyright notices and the legal risks
also vary across diﬀerent countries or regions. However, we
do observe that “aﬃliation change” is an important reason
causing copyright inconsistency and needs to be noticed.
Support function and others’ contributions are two reasons why developers add others’ copyright notices when
they committed source code. Another interesting case is
All replaced, which is the situation that the source code
the holder committed is totally replaced by the source codecommitted by the committers later, but the copyright notice
is retained. All replaced also suggests that copyright notices
are not well managed in the Linux kernel. We draw a conclusion that code reuse, aﬃliation change, refactoring, sup†https://www.linkedin.com/††
https://en.wikipedia.org/

Table 6 The reasons why holder-not-committer inconsistencies happened in the Linux kernel version 4.14.
Categorization#Source files

Proportion

Code reuse
Aﬃliation change
Refactoring
Support function
Others’ contributions
Typo
All replaced

37
19
14
13
13
5
2

27.6%
14.2%
10.4%
9.7%
9.7%
3.7%
1.5%

None

31

23.2%

Total

134

100.0%

Table 7 The reasons why committer-not-holder inconsistencies happened in the Linux kernel version 4.14.
Categorization#Source files

Proportion

Code reuse
Aﬃliation change
Refactoring
Others’ contributions
Typo

30
12
8
7
1

23.4%
9.4%
6.3%
5.5%
0.8%

None

70

54.6%

Total

128

100.0%

port function, and others’ contributions are the main reasons
why the holder-not-committer inconsistency occurred.
Table 7 shows the summarized reasons why committernot-holder inconsistencies happened. The results are similar
to the results of holder-not-committer inconsistency. Codereuse, aﬃliation change, refactoring, support function, andothers’ contributions are still the main reasons why thecommitter-not-holder inconsistency occurred.
Based on these findings, the following practical suggestions may help practitioners: (1) When developers reuse
source code, the provenance of reused source code should
be recorded properly as well for the traceability of the copyright notice. (2) The list of contributors should be wellmaintained as an evidence of copyright ownership. (3) The
communities should propose a set of practical guidelines for
managing the copyright notices. For example, when a copyright notice is added, modified, or deleted, the reason andthe coverage of influence should be recorded. (4) The copyright ownership should be ascertained with a finer granularity such as line level or token level. The related tools areneeded to be developed.
As an answer to RQ2, we draw a conclusion that code
reuse, aﬃliation change, refactoring, support function, andothers’ contributions are the main reasons why copyrightinconsistency occurred.
6.

Threats to Validity

This section discusses the threats to the validity of our research. Threats to construct validity concern the relationship between theory and outcome, and relate to possible

QIU et al.: AN EXPLORATORY STUDY OF COPYRIGHT INCONSISTENCY IN THE LINUX KERNEL

261

measurement imprecision when extracting data we used inthis study. In mining the repositories to build the committer
dataset, we first rely on cregit to summarize the namesof the committers and their contributions. cregit measures the contribution in terms of tokens. Compared with themethod measuring the contribution in terms of lines before,
cregit is more precise and could avoid the case that developers doing simple code change are seen as the owner of thetotal lines. However, the precision of cregit is not provedby a large-scale test. To limit this problem, we randomly select some source files to check the precision of cregit at thesame time when we do the empirical study. Another threat
in using cregit is its method of merging the multiple diﬀerent accounts owned by the same committer. cregit merges
them based on the full name of the committer. This method
will be ineﬀective for the case that a committer uses morethan one name to commit source code to a single source file.
However, this defect does not aﬀect the results because we
do not observe this case in our empirical study.
Another threat in building the committer dataset is that
we identify the organizations the committers belong to bychecking the domain of their e-mail addresses. But the committers possibly use their personal e-mail addresses. Also,
the committers may not change their e-mail addresses in
Github when they change their organizations. For thesecases, we can not rightly identify their organizations. Considering that we also track the change of their organizationsin answering the RQ2, this threat might have an impact on
our empirical study as well.
In mining the repositories to build the holder dataset,
we first rely on FOSSology to extract the copyright notices.
Although we manually check the copyright notices detectedby FOSSology to remove the wrongly detected ones, FOSSology could have missed some copyright notices. We plan
to use other methods or tools to do the detection in the future.
Another case worthwhile of being discussed is the minimum threshold percentage of contribution to define thecommitter used to detect the committer-not-holder inconsistency. We have set this minimum threshold percentage as
14.9%. The percentage of source files detected as having thecommitter-not-holder inconsistency will increase if we donot set it. In our calculation, if we would lift the threshold,87.9% of all source files are detected as inconsistent, which
proves the eﬀectiveness of the minimum threshold percentage in excluding the minor committers who only do some
simple work. Some studies set the minimum threshold percentage as 5% to exclude the minor contributors [10], [11].
To what extent the contribution is needed to become a qualified contributor or state the copyright ownership is still acomplicated problem under discussion.
Another threat requiring consideration is the eﬀectiveness of the sampling. To achieve an accurate result, a lotof manual works are included in our proposed method todetect copyright inconsistency, for which we have introduced sampling. To validate the eﬀectiveness of the sampling and the manual works, we have conducted a compari-son experiment. We first designed a fully-automatic method
without manual works to detect copyright inconsistency andthen used it to detect copyright inconsistencies targeting all
38,932 source files in the Linux kernel and 500 source files
the sample dataset respectively. For all source files in theLinux kernel, 19,261 source files out of 38,932 total source
files are detected as having hold-not-committer inconsistency, accounting for 49.5%, and 24,143 source files are detected as having committer-not-hold inconsistency, accounting for 62.0%. For the sample dataset, 228 source files out of
500 files are detected as having hold-not-committer inconsistency, accounting for 45.6%, and 309 source files are detected as having committer-not-hold inconsistency, accounting for 61.8%. It is easy to find that the results are similar, which suggests that the sampling is eﬀective. Also, thissampling method based on population size, confidence interval, and confidence level is well established. It is first
proposed by Krejcie and Morgan in 1970 [12], and widelyused and proven by other related works [13]–[15]. Then we
have compared the results detected by the proposed method
in Table 5 and the results detected by the newly designed
fully-automatic method targeting the sample dataset. The
proportions detected by the proposed method are smaller.
Because of the manual works in the proposed method, thecopyright inconsistencies detected by the proposed method
are all actual ones while the copyright inconsistencies detected by the newly designed fully-automatic method arenot. The results suggest that the manual works are eﬀective
and could improve accuracy.
Threats to internal validity concern factors internal to
the study that could impact our results. Such a kind of threat
does not aﬀect exploratory study like the one in this paper.
The only case worthwhile of being discussed is our answering to RQ2, where we classify the reasons manually basedon our knowledge.
Threats to external validity are related to the ability togeneralize the finding in our study. Our empirical study is
only conducted on the Linux kernel. Linux kernel is themost popular and successful open-source operating systemkernel, receiving contribution from 13,500 developers from
more than 1,300 organizations. These features make Linuxkernel a suitable target to study copyright inconsistencies.
But according to the diﬀerent requirements about the copyright, other open-source projects may have diﬀerent results.
We agree that it is necessary to replicate our empirical study
on diﬀerent projects.
Another case worthwhile of being discussed is the generalization of our findings in RQ2. To address this issue, wehave repeated our experiment targeting another version of
the Linux kernel and checked whether or not we can achieve
similar results. The new experiment targeted version 5.80of the Linux kernel, from which we randomly selected 500
source files to construct the sample dataset. After removing
the source files once moved or renamed, we ended up witha sample dataset of 390 source files. We then repeated thedetection. Among these 390 source files, 126 source files
are detected as having hold-not-committer inconsistency,

IEICE TRANS. INF. & SYST., VOL.E104–D, NO.2 FEBRUARY 2021

262
Table 8 The reasons why holder-not-committer inconsistencies happened in the Linux kernel version 5.80.
Categorization#Source files

Proportion

Code reuse
Aﬃliation change
Refactoring
Support function
Others’ contributions
Typo

38
21
12
17
8
2

30.2%
16.7%
9.5%
13.5%
6.3%
1.6%

None

28

22.2%

Total

126

100.0%

Table 9 The reasons why committer-not-holder inconsistencies happened in the Linux kernel version 5.80.
Categorization#Source files

Proportion

Code reuse
Aﬃliation change
Refactoring
Others’ contributions

25
9
6
2

22.5%
8.1%
5.4%
1.8%

None

69

62.1%

Total

111

100.0%

accounting for 32.3%, while 205 source files are detected
as having committer-not-hold inconsistency, accounting for52.6%. Among the 205 source files where committer-nothold inconsistency are detected, 111 source files are detected as having only committer-not-hold inconsistency andno hold-not-committer inconsistency. Then we have used
the same method to find reasons behind the occurrence ofthe copyright inconsistency. Table 8 and Table 9 show theresults. The similar results suggest the ability to generalize
the finding in RQ2.
7.

Related Work

7.1

Software Ownership

Some studies in software engineering investigated softwareownership. Girba et al. built the ownership based on the percentage of source code lines modified by contributors [16].
Tsikerdekis et al. proposed a code contribution ranking algorithm to build the ownership by tracking the survival ofindividual characters [17]. Bird et al. explored the eﬀects
of ownership on software quality [10]. Compared with theirworks, we use a more accurate and reasonable measure token - to measure contributions. Especially, diﬀerent fromthe above works, we also included copyright notice into consideration. Our work opens up a new way to study softwareownership.
7.2

OSS Contributor

There are some studies that devoted to investigate OSS contributors and their contributions. German et al. studied thecommitters of the PostgreSQL project and found that apartfrom the core team, a large number of contributors sent
source code patches to the project [18]. Hindle et al. discovered that the large commits including a large number of files
are related to license or copyright owners [19]. Hammad etal. proposed two measures to measure the contribution ofsoftware developers in the evolved structural design of software systems [20]. Diﬀerent from their works, we discussed
the discrepancy between the contributors’ contributions andthe recorded copyright notices. Our work creates a possibility of importing the existing works on OSS Contributor into
the software copyright management of the FOSS projects.
7.3 Software License
There are some studies that devote to identify licenses [5],[21]. Based on these studies, some researchers analyzed
software licenses in open source projects and revealed somelicense issues. German et al. proposed a method to understand licensing compatibility issues in software packages [22]. Wu et al. proposed an approach to find license
inconsistencies in similar files [23]. By investigating the revision history of these files, they summarized the factorsthat caused these license inconsistencies and tried to decide
whether they are legally safe or not. Studies on software
license are also closely related to this work. Many studies
in software engineering investigated software license. However, to solve the legal risks in reusing FOSS, only the studies on software license are not suﬃcient. This work is a
supplement to works on software license by studying thesoftware ownership.
8.

Conclusion and Future WorkIn this paper, we first proposed the issue of copyright inconsistency, and then we defined copyright inconsistency andcategorized diﬀerent types of it. After that, we conducted
an empirical study on the Linux kernel to study the prevalence of copyright inconsistency. To the best of our knowledge, this study is the first in this field to address this issue.
We observed that the copyright inconsistency is prevalent
in the Linux kernel. It suggests that the copyright notices
recorded in the source files do not always reflect the actual
contributors. To find how copyright inconsistency happens,
we had a deeper look at the commit logs and the comments
in source code to find the reasons why the copyright inconsistencies happened. We found that code reuse, aﬃliation
change, refactoring, support function, and others’ contributions are the main reasons.
The proposed method and results of this work can bereused in the following aspects: (1) The proposed methodof detecting copyright inconsistency can be reused in other
OSS projects to study the situation of copyright inconsistency in them. (2) Our findings on the prevalence of copyright inconsistency and the reasons causing them can beused as a benchmark to study the diﬀerence in the copyrightrelated issue among diﬀerent OSS projects. (3) Our findings

QIU et al.: AN EXPLORATORY STUDY OF COPYRIGHT INCONSISTENCY IN THE LINUX KERNEL

263

also provide a new perspective to study software development management, code reuse, and the organizational culture in OSS projects. (4) The datasets constructed in thiswork can be reused in other highly related works such as theparticipation of developers or companies in OSS projects
and the collaboration between them.
In our future work, we will make some guidelines fordevelopers to help them in dealing with copyright notices.
We also aim to find a solution to manage the copyright notices in the FOSS projects.
References[1] M. Larabel, “The linux kernel enters 2020 at 27.8 million lines
in git but with less developers for 2019,” Web page at linux.com,
https://www.phoronix.com/scan.php?page=news item&px=LinuxGit-Stats-EOY2019, Jan. 2020.
[2] T. Golder and A. Mayer, “Whose ip is it anyway?,” Journal of Intellectual Property Law & Practice, vol.4, no.3, pp.165–175, 2009.
[3] H. Meeker, “Patrick mchardy and copyright profiteering,” Webpage at opensource.com, https://opensource.com/article/17/8/
patrick-mchardy-and-copyright-profiteering, Aug. 2017.
[4] H. Welte, “Report from the geniatech vs. mchardy gpl violation court hearing,” Web page at gnumonks.org, https://laforge.
gnumonks.org/blog/20180307-mchardy-gpl/, March 2018.
[5] R. Gobeille, “The FOSSology project,” 2008 International working
conference on Mining software repositories (MSR2008), pp.47–50,
2008.
[6] M.D. Penta and D. German, “Who are source code contributors andhow do they change?,” 2009 16th Working Conference on Reverse
Engineering, pp.11–20, Jan. 2009.
[7] Oracle, “Oracle contributor agreement - version 1.7.1,” Web pageat oracle.com, https://www.oracle.com/technetwork/community/oca-486395.html#list, 2019.
[8] J. Corbet and G. Kroah-Hartman, “2017 linux kernel development
report,” A Publication of The Linux Foundation, 2017.
[9] D.M. German, B. Adams, and K. Stewart, “cregit: Token-level
blame information in git version control repositories,” Empir. Softw.
Eng., vol.24, issue 4, pp.2725–2763, 2019.
[10] C. Bird, N. Nagappan, B. Murphy, H. Gall, and P. Devanbu,“Don’t touch my code! examining the eﬀects of ownership on
software quality,” Proc. 19th ACM SIGSOFT symposium and the13th European conference on Foundations of software engineering SIGSOFT/FSE ’11, pp.4–14, 2011.
[11] M. Foucault, J.-R. Falleri, and X. Blanc, “Code ownership in opensource software,” Proc. 18th International Conference on Evaluation
and Assessment in Software Engineering - EASE ’14, pp.1–9, 2014.
[12] R.V. Krejcie and D.W. Morgan, “Determining sample size for research activities,” Educ. Psychol. Meas., vol.30, no.3, pp.607–610,
1970.
[13] H. Hata, C. Treude, R.G. Kula, and T. Ishio, “9.6 million links
in source code comments: purpose, evolution, and decay,” 2019
IEEE/ACM 41st International Conference on Software Engineering(ICSE), pp.1211–1221, IEEE, 2019.
[14] Z. Gao, C. Bird, and E.T. Barr, “To type or not to type: quantifying
detectable bugs in javascript,” 2017 IEEE/ACM 39th International
Conference on Software Engineering (ICSE), pp.758–769, IEEE,
2017.
[15] A.D. Veiga, “A cybersecurity culture research philosophy and approach to develop a valid and reliable measuring instrument,” 2016
SAI Computing Conference (SAI), pp.1006–1015, IEEE, 2016.
[16] T. Girba, A. Kuhn, M. Seeberger, and S. Ducasse, “How developers
drive software evolution,” 8th international workshop on principles
of software evolution (IWPSE’05), pp.113–122, 2005.
[17] M. Tsikerdekis, “Persistent code contribution: A ranking algorithm

for code contribution in crowdsourced software,” Empir. Softw.
Eng., vol.23, no.4, pp.1871–1894, 2018.
[18] D.M. German, “A study of the contributors of PostgreSQL,” Proc.
2006 international workshop on Mining software repositories MSR ’06, pp.163–164, 2006.
[19] A. Hindle, D.M. German, and R. Holt, “What do large commits tellus? a taxonomical study of large commits,” Proc. 2008 international
workshop on Mining software repositories - MSR ’08, pp.99–108,
2008.
[20] M. Hammad, M. Hammad, H. Bani-Salameh, and E. Fayyoumi,“Measuring developers’ design contributions in evolved software
projects,” Journal of Software, vol.9, no.12, pp.3005–3011, 2014.
[21] D.M. German, Y. Manabe, and K. Inoue, “A sentence-matching
method for automatic license identification of source code files,”Proc. IEEE/ACM international conference on Automated software
engineering - ASE ’10, pp.437–446, 2010.
[22] D.M. German, M.D. Penta, and J. Davies, “Understanding and auditing the licensing of open source software distributions,” 2010
IEEE 18th International Conference on Program Comprehension,
pp.84–93, 2010.
[23] Y. Wu, Y. Manabe, T. Kanda, D.M. German, and K. Inoue, “A
method to detect license inconsistencies in large-scale open source
projects,” 2015 IEEE/ACM 12th Working Conference on Mining
Software Repositories, pp.324–333, 2015.

Shi Qiu
received his B.E. degree of software engineering from Jilin University in 2013and his M.E. degree of information science andtechnology from Osaka University in 2018. At
present, he is a Ph.D. student in the Graduate
School of Information Science and Technology
at Osaka University. His research interests include mining software repositories, software license/copyright analysis, and software ecosystem.

Daniel M. German
is Professor in the Department of Computer Science at the Universityof Victoria, where he does research in the areas of mining software repositories, open source
software ecosystems and the impact of intellectual property in software engineering.

Katsuro Inoue
received his Ph.D. from
Osaka University in 1984. He was an associate professor of University of Hawaii at Manoa
from 1984 to 1986. After becoming an assistantprofessor of Osaka University in 1986, he has
been a professor since 1995. His research interests include software engineering, especially
software maintenance, software reuse, empiricalapproach, program analysis, code clone detection, and software license/copyright analysis.