# Software Supply Chain Map: How Reuse Networks Expand

Hideaki Hata  Shinshu University<EMAIL_ADDRESS>and  Takashi Ishio  Nara
Institute of Science and Technology<EMAIL_ADDRESS>
###### Abstract.

Clone-and-own is a typical code reuse approach because of its simplicity and
efficiency. Cloned software components are maintained independently by a new
owner. These clone-and-own operations can be occurred sequentially, that is,
cloned components can be cloned again and owned by other new owners on the
supply chain. In general, code reuse is not documented well, consequently,
appropriate changes like security patches cannot be propagated to descendant
software projects. However, the OpenChain Project defined identifying and
tracking source code reuses as responsibilities of FLOSS software staffs.
Hence supporting source code reuse awareness is in a real need. This paper
studies software reuse relations in FLOSS ecosystem. Technically, clone-and-
own reuses of source code can be identified by file-level clone set detection.
Since change histories are associated with files, we can determine origins and
destinations in reusing across multiple software by considering times. By
building software supply chain maps, we find that clone-and-own is prevalent
in FLOSS development, and set of files are reused widely and repeatedly. These
observations open up future challenges of maintaining and tracking global
software genealogies.

software supply chain map, clone-and-own, code reuse, FLOSS ecosystem, global
version control

††ccs: Software and its engineering Software libraries and repositories††ccs:
Software and its engineering Reusability††ccs: Software and its engineering
Software evolution††ccs: Software and its engineering Open source model

##  1\. Introduction

Because of the nature of free and open source, and the lack of the view of the
whole picture, there are several problems in free/libre and open source
software (FLOSS), such as broken library dependencies (Kula et al., 2017) and
license violations (Mlouki et al., 2016). One reason of such issues is in ad
hoc code reusing. Copying software components and then maintaining them by a
new owner is one type of code reuse, which is known as clone-and-own (Dubinsky
et al., 2013; Ishio et al., 2017). In software product line engineering, the
usage of this clone-and-own approach is discouraged, since it makes
maintaining multiple product lines difficult. If changes are made in the
original or copied components, they are not easily propagated. This is because
of the ad hoc nature of component reusing. Developers working in different
product lines do not know when clone-and-own operations occurred and where the
cloned components are located. Although there are disadvantages, the clone-
and-own approach is adopted in FLOSS projects as well as industrial software
product lines due to its benefits, such as simplicity, availability, and
independence of developers (Dubinsky et al., 2013). Similar to industrial
cases, changes are not appropriately propagated because of unrecorded and ill-
managed clone-and-own reuses.

Even with its large-scale code resources and a large amount of developers,
Google is reported to address reusing properly with a monolithic source code
management system (Potvin and Levenberg, 2016). Such a monolithic system has
several advantages: unified versioning, extensive code sharing and reuse,
simplified dependency management, large-scale refactoring, and so on (Potvin
and Levenberg, 2016). Based on the monolithic source code management, changes
to core libraries are promptly and easily propagated through the dependency
chain into the final products that rely on the libraries (Potvin and
Levenberg, 2016).

Although introducing such a monolithic source code management system in the
entire FLOSS ecosystem is not practical, tracking source code across multiple
projects is recently considered to be an obligation. The OpenChain, a Linux
Foundation initiative, is working for identifying FLOSS process quality
criteria111https://www.openchainproject.org/. A core set of requirements every
quality compliance program must satisfy is defined in the OpenChain
Specification (OpenChain, 2018). As described in the specification,
identifying, recording and/or tracking of FLOSS components through reusing
source code are considered to be parts of FLOSS responsibilities. Identifying
and tracking such source code reuses are required from such an emerging real
need.

Instead of preparing a monolithic system, we try constructing networks of
clone-and-own relations. We call them software supply chain maps. Source code
reuses across projects have been analyzed by code clone detection tools.
Ossher et al. (Ossher et al., 2011), Koschke et al. (Koschke and Bazrafshan,
2016), and Lopes et al. (Lopes et al., 2017) reported that a large number of
projects included copies of libraries. Gharehyazie et al. (Gharehyazie et al.,
2017) reported that most projects obtain files from outside than provide them.
We extend such analyses to consider the directions of source file reuses
across repositories. To recover file reuse relations across projects, we
employ a file-level origin analysis proposed by Ishio et al. (Ishio et al.,
2017). The method identifies the most similar version of sets of files among
projects as origins, while existing code clone detection techniques simply
report all the cloned files in the projects. By connecting most likely clone-
and-own sets of files across projects with considering time information of
files, we build software supply chain maps, which represent software reuse
relations across software projects.

This paper presents our approach of building software supply chain maps, and
conducts an empirical study of clone-and-own activities in FLOSS projects. We
consider that this study is important to (1) understand how software reuses
spread, (2) understand reuse relations among different software projects, and
(3) help developers to maintain their software by applying appropriate changes
and propagating changes along with related software projects.

The contributions of this paper are summarized as follows.

  * •

Proposing the concept of software supply chain maps and designing algorithm to
build them.

  * •

Conducting an empirical study of software supply chain maps with 4,592 C, C++,
and Java projects on GitHub. To the best of our knowledge, this is the first
study to show directed networks of FLOSS software projects in terms of file
reusing.

  * •

Providing a new insight of source code histories and reuses, such as “single
repositories are not self-contained”. Because files are manually clone-and-
owned in newer repositories, the information of original authors and previous
histories are lost. This fact can have impact on research related to code
repository mining, developer activity analyses (social networks, turnover,
etc.), code authorship and ownership.

##  2\. Model of Software Supply Chain Maps

Figure 1. An example of a software supply chain lineage. Figure 2. An example
of a software supply chain map.

Similar to clone genealogy (Kim et al., 2005), we define a model of software
supply chain maps. The genealogies of software reuses describe how software
components, sets of source files, are reused and transferred over multiple
software projects by means of clone-and-own reusing, and can be regarded as
imaginary source file version transitions across multiple software projects.

A software supply chain lineage is a directed acyclic graph of snapshots that
are related to a specific set of files. It represents the evolution history of
a group of files across multiple software projects. Figure 1 illustrates an
example of a clone lineage across software U, X, and Y. In each software,
denoted by rounded rectangles, snapshots (files at a specific time or a
version) are shown as ellipse. Snapshots are linked with solid arrows from
older to newer, which represent updates within software. In software X, there
are two snapshots and both include files a, b, c, d, and e (small circles).
Different colors for the same files represent the modifications of those
files. We see that files of a, b, c, and e are updated from the first version
to the second version. Files a, b, and c of the first version of software X
came from software U, more specifically, the second version of software U was
reused in software X. Software Y clone-and-own the file set of a, b, c, and d
in the second version of software X. Clone-and-own relations are shown as
dotted arrows from origins (original set of source files) to destinations
(reused set of source files).

A software supply chain map is a set of software supply chain lineages that
are connected with clone-and-own links. It illustrates how software
ingredients (Ishio et al., 2016) mixed and transferred to other software
projects. Figure 2 shows an example of a software supply chain map, which is
extended from Figure 1 by including another clone lineage. In addition to a
clone lineage of software U, X, and Y related to files a, b, c, and d, the set
of files d and e is cloned from software V to software W, and the updated set
of files in software W is reused in software X. As a result, all software U,
V, W, X, and Y are connected with clone-and-own links in one chain map of a
directed network.

##  3\. Building Software Supply Chain Maps

Although clone-and-own operations should have been conducted by developers
intentionally, they are not always recorded precisely and properly (Xia et
al., 2013). Therefore, we need to identify those operations and hidden links
from multiple software version histories. As previous studies reported, there
are a considerable amount of duplication in source code among multiple
projects (Lopes et al., 2017; Gharehyazie et al., 2017). Even in Figure 1 of a
clone-and-own lineage, files a, b, and c in the last snapshots of software U,
X, and Y can be considered to be a clone group. Therefore, simply detecting
similar files is not appropriate to construct software supply chain maps. We
need to consider time differences to connect those similar sets with directed
arrows. Since the previous approach work only on one-to-many relations (given
a snapshot, identify origins) (Ishio et al., 2017), we need to extend their
approach to extract whole genealogies with many-to-many relations.

---
(a) C2: largest file sets

---
(b) C3: most similar file sets

---
(c) C4: oldest file sets

---
(d) C5: single origins

---
(e) C6: update rather than clone-and-own

Figure 3. Criteria to remove unlikely clone-and-own links. Solid lines
represent update relations and dotted lines represent clone-and-own relations.

To identify clone-and-own operations among multiple projects, we link the
original source file sets (origins) to the reused source file sets
(destinations), in any combinations of source file set pairs from multiple
software projects. We call projects that have origins as producer projects,
and reusing projects as consumer projects. In this study, we only target file
sets belonging to tagged snapshots in Git repositories. This is efficient to
reduce the search spaces, and we think it reasonable to assume that developers
reuse file sets in released snapshots, which should have tags.

A pair of file sets that have similar or identical files can be considered to
be potential origin-destination relations. As reported in previous studies
(Lopes et al., 2017; Gharehyazie et al., 2017), there are a considerable
amount of duplication in source code among multiple projects, which can be
considered to be potential origin-destination relations. We prepare criteria
for choosing most likely clone-and-own relations (Section 3.1), and design an
algorithm of detecting many-to-many clone-and-own relations (Section 3.2).

###  3.1. Criteria for Clone&Own Detection

To find most likely origins, we set the following criteria. Among various
potential clone-and-own relations, we remove unlikely relations based on our
criteria as shown in Figure 3.

C1:

Origins come from the past. For each snapshot in a potential consumer project,
origin file sets are searched from the past (until the commit time of the
snapshot).

C2:

The largest file sets are more likely to be origins. Although a destination
file set can compose of multiple small origins in theory, it is not reasonable
to assume that developers pick a single or a few files from many different
projects, instead of fetching set of files from specific projects. In software
P, there are three snapshots that contain one, two, and three files, which can
correspond to subsets of files in the snapshot of software C (Figure 3 (a)).
Since the number of corresponding files is the largest, the third snapshot is
likely to be the origin.

C3:

Most similar file sets are more likely to be origins. Identical or similar
file sets can be considered to be clone-and-own relations. As shown in Figure
3 (b), the file set in software C is more similar to the file set in the first
snapshot than the second snapshot in software P. Then we can assume that the
first snapshot is likely to be the origin.

C4:

Oldest file sets are more likely to be origins. If there are multiple
potential origins that are in the same conditions with the criteria C2 and C3,
we consider the oldest file sets is the origin. Considering Figure 3 (c), the
snapshot in software Q is likely to be the origin.

C5:

Each file does not come from multiple origins. There can be multiple potential
origins for single files. In the example shown in Figure 3 (d), the file $c$
is associated with both snapshots in software P and Q. Based on the criteria
C2, C3, and C4, only one origin is selected for a destination that have
overlapped potential origins (the snapshot in software P is selected, in this
example).

C6:

Direct ancestors are more likely to be origins. If file sets can be considered
to be updated within a project, potential clone-and-own links are removed. In
Figure 3 (e), the second snapshot in software P can be identified as a
temporal origin for the second snapshot in software C, based on the above
criteria. However, the previous version of the snapshot exists in software C.
Moreover, files a, b, and c in software P originally come from software C.
Then we consider that the second snapshots in both software P and C become
occasionally similar, or, at least, there is no clone-and-own relation between
them.

###  3.2. Clone&Own Detection Algorithm

Given a list of Git repositories of software projects, we construct software
supply chain maps among the projects. Our algorithm consists of five steps.
For all snapshots in the projects, potential origin file sets are searched by
performing the following three steps. Figure 4 (a) to (c) illustrate these
steps with an example of the snapshot in Software X as an query. Since we do
not know actual developers’ intentions of clone-and-own operations in the
past, we try to identify only plausible operations and ignore suspicious
relations.

---
(a) Step 1: collect origin candidates

---
(b) Step 2: select one origin for each project

---
(c) Step 3: determine temporal clone-and-own links

---
(d) Step 4-I: remove links between identical files

---
(e) Step 4-II: remove links between similar files

---
(f) Step 4-III: remove false transferring links

Figure 4. Clone-and-own detection algorithm. Solid lines represent
modifications within projects and dotted lines represent clone-and-own
relations.

Step 1:

Collect candidates of origins. For every file in the query snapshot, identical
or similar files are searched from any snapshots in other projects, which had
been created before the query snapshot (C1 criterion). We identify identical
files using SHA-1 file hash. We also identify similar files using n-gram-based
similarity defined in (Ishio et al., 2017) because of its efficiency for our
large-scale analysis. Found files in a snapshot are aggregated as one file
set. If there is no candidate origin for a query snapshot, terminate the
origin detection for the snapshot. In the example shown in Figure 4 (a),
identical or similar files are found in five different snapshots from three
projects.

Step 2:

Select one origin candidate for each potential producer project. From multiple
origin candidates in one potential producer project, we decide a winner
candidate. Multiple origin candidates are sorted based on the following
conditions (if there is a tie, the next condition is applied to the tie). The
first candidate in the sorted list is chosen as a winner.

  1. (1):

The descending order of the number of files in file sets (C2 criterion).

  2. (2):

The descending order of the number of identical files in file sets (C3
criterion).

  3. (3):

The ascending order of the committed times of file sets (C4 criterion).

In the example shown in Figure 4 (b), links from lost origin candidates are
removed.

Step 3:

Determine temporal clone-and-own relations. From multiple potential producer
projects, which have single winner origins, we decide winner projects if there
are overlapped origins (C5 criterion). Among overlapped origins, only one
origin is selected based on the same sorting approach with step 2. In the
example shown in Figure 4 (c), software V is removed and the remained links
are considered to be temporal clone-and-own relations.

In the temporal clone-and-own relations obtained from the above three steps,
there can be inappropriate detection. To remove inappropriate clone-and-own
relations, the following steps are performed.

Step 4:

Remove files that come from own projects. In this step we investigate the
history of each file in temporal destination file sets. If files come from
their own repositories, it is inappropriate to consider that they were fetched
from other repositories (C6 criterion). We remove temporal clone-and-own
relations between files if their relations are one of the following three
types shown in Figure 4 (d) to (f). In the figures, software P is considered
to be a temporal producer, and software C is a temporal consumer.

  1. (1):

Linked two files are identical, and the file exist in a temporal consumer
project before a temporal origin is created (Figure 4 (d)).

  2. (2):

Linked two files are similar, and the temporal origin file exists in a
temporal consumer project (Figure 4 (e)).

  3. (3):

Linked two files are similar, and the temporal origin file does not exist in a
temporal consumer project. However, the temporal origin file come from a
temporal consumer project (Figure 4 (f)).

Step 5:

Remove suspicious clone-and-own relations. We prepare two rules to remove
suspicious relations and leave more probable relations.

  1. (1):

Remove a clone-and-own link from software B to A if there is an older link
from software A to B. We assume that clone-and-own reuses happen one-way and
returning reuses rarely happen.

  2. (2):

Remove a clone-and-own link whose corresponding file set size (the number of
files) is less than a threshold. This is because a small number of files can
occasionally become similar to files in other projects. Threshold values are
discussed in Section 4.2.

By identifying producers and consumers (then identifying ‘reuse’ operations),
we can track the histories of files across projects, detect the transitions of
ownership, and consider file versions across projects. As far as we know, this
is the first study of identifying producers and consumers in file set reuses
(clone-and-own operations) and showing chain maps (file set reuse relations).

###  3.3. Algorithm Validation

Our algorithm is validated with the manually labeled clone-and-own relations
in Firefox 45.0 and Android 4.4.2_rc1 used in the previous study (Ishio et
al., 2017). We identified appropriate origins in all destinations (21 from
Firefox and 54 from Android). Incorrect 14 false links (top-1 in the ranking)
in the previous study were successfully excluded and correct destinations are
found because of the time consideration in our algorithm. With this
encouraging result, we conduct an empirical study of software supply chain
maps in FLOSS projects.

##  4\. Study Procedure

We study software supply chain maps in FLOSS projects with the following three
research questions.

(RQ1): _What are the characteristics of software supply chain maps?_ We
analyze network metrics to discuss the characteristics of obtained software
supply chain maps.

(RQ2): _How have software supply chain maps evolved?_ We investigate how
producer projects evolved along with the growth of software ecosystems.

(RQ3): _How source files are transferred in software supply chain maps?_ The
nature of supply chains in software supply chain maps are analyzed.

To study clone-and-own relations among actual projects, we try to construct
chain maps only with plausible links by ignoring false positive relations. To
this end, we prepare relatively strict settings of threshold to detect clone-
and-own relations conservatively.

###  4.1. Project Collection

We collected software projects written in C, C++, or Java from GitHub. For
each language, we selected highly starred projects as they considered to be
influential. In order to include both applications and libraries, we used
three search queries for each language. Queries “library” and “lib” were used
to identify library projects. A query “mirror” was used to select popular
projects developed outside of GitHub but having a mirror repository in GitHub.
For each query, we obtained up to 1,000 projects that have at least 20 stars.
In addition, we also collected up to 1,000 projects without query keyword
under the same star condition, i.e. the most popular projects for each
programming language. The dataset includes 7,468 projects. Their Git
repositories were cloned on November 18, 2017. The total size is 341 GB.

###  4.2. Data Processing

We analyzed tagged snapshots (e.g. official releases) of files in the Git
repositories. The grammars of C++ 14 and Java 8 were used for our lexical
analysis. The lexical analysis tools excluded whitespace and comments from
tokens, but keeps preprocessor directives for C/C++. We extracted trigrams
from each of unique files, performed pair-wise comparison, and then computed
file similarities across projects.

Table 1. Stepwise clone-and-own detection Step | # of projects | # of links | # of associated files
---|---|---|---
0 | 4,592 | — | (9,745,519)
2 | 4,592 | 111,516 | 541,795
3 | 2,330 | 5,808 | 391,946
4 | 1,847 | 3,306 | 126,689

From the collected projects, we removed projects that did not have tagged
snapshots containing targeted source files. The number of left projects was
4,592 and there were 9,745,519 unique files in the entire tagged snapshots in
the projects, as shown in the step 0 row of Table 1. We can see, from Table 1,
how our algorithm constructs most likely clone-and-own links by removing
inappropriate links step by step. After step 2, all projects belonged to the
temporal network with a large amount of links, which means that those analyzed
projects have at least one identical or similar file with other projects.
After step 3, unlikely clone-and-own links were largely removed, and false
producer and consumer projects were removed from the temporal network. After
step 4, more than two-thirds of the associated files, which are considered to
be inappropriate, were removed, and then the number of projects and links
decrease. With the first rule in step 5, about 100 links are removed (the
number of links became 3,203).

Figure 5. Step 5-2: removing small file set size links. Figure 6.
Distributions of the constructed supply chain maps. The largest map (size 383)
is excluded.

Figure 5 illustrates the impact of the threshold in the second rule of step 5.
The threshold changes from 5 to 50. We find the about half of the projects are
involved in less than five file relations (from 1,847 projects without
threshold to less than 1,000 at the threshold 5). Although there can be small
clone-and-own reuses, there also can be occasional matches. In order to focus
on intentional clone-and-own reuses, we use the threshold value 20 in this
study. This threshold will reduce smaller repositories; Lopes et al. reported
9 for Java and 11 for C++ as the median value of the number of files in a
projects in their large-scale study (Lopes et al., 2017).

With the above settings, 534 projects are identified as members of software
supply chain maps. There are 67 independent maps, from small size maps only
with two belonging projects (size 2) to the largest map (size 383). Figure 6
presents the histogram of the map sizes excluding the largest one. Although
there are many small maps, more than $70\%$ (383/535) of projects belong to
one big map shown in Figure 13. The obtained map data is now
available222https://www.dropbox.com/s/q25w60ixu7xu1a6/genealogy.zip?dl=0. We
plan to prepare archived open data in case of acceptance.

Figure 7. In-degree (reusing) distributions. Figure 8. Distributions of the
reused file set sizes. Figure 9. Out-degree (reused) distributions.

##  5\. Study Results

###  5.1. RQ1: Clone&Own Characteristics

Now that we have seen that more than $10\%$ of analyzed projects belong to
software supply chain maps, we proceed to analyze their software supply chain
maps to reveal their characteristics.

Figure 7 shows the distributions of reusing producer projects (in-degree) per
consumer project. More than a quarter of projects belong to the maps only as
producers, and most projects clone source files from single projects. The
distributions of the reused file set sizes can be seen in Figure 8. More than
three quarters of clone-and-own reuses (441 in the entire 560 links) 20 to 100
files. There are 14 reuses contain more than 1,000 files from single producer
projects, and the largest one involves 5,620 files.

Figure 9 presents the distributions of reused projects (out-degree) per
producer project. We find that more than half of projects (298/534) were not
reused by other projects, and most of the other projects were reused from only
a few projects. There are a small number of projects that are reused by more
than 10 projects, and this finding is similar to the result in the previous
work (Gharehyazie et al., 2017), that is, there are hubs of reusable code
providers to other projects. We consider that the existence of clone-and-own
hubs results in the similar observations in fine-grained clone detection work.

Summary: More than a quarter of projects played only producer roles, and more
than half were just consumers. In most clone-and-own cases, less than 100
files were reused, and only a few cases reused more than 1,000 files. There
are a small number of projects that serves as hubs of source file set
providers.

###  5.2. RQ2: Supply Chain Map Evolution

Figure 10. Growth of the map sizes (a line) and the percentages of consumers,
hubs, and the other projects (stacked bars). Figure 11. Out-degree transitions
of hub projects.

---
(a) 2010

---
(b) 2014 (the largest map)

---
(c) 2016 (the largest map)

Figure 12. software reuse map growth. Projects whose out-degrees are less than
five are not shown. Figure 13. The largest software supply chain map including
383 projects. The sizes of node represent the number of out-degree links and
the width of links represent the number of reused files (in the first reuse).
Figure 14. Distributions of chain lengths among projects.

Figure 10 shows how clone-and-own maps evolved from 2006 to 2016. A line
illustrates the increase of the maps’ members (projects), and stacked bars
represent the percentages of consumer projects (no out-degree), hub projects
(more than five out-degrees, which serves top 5% projects), and the other
projects. Although the sizes of software supply chain maps largely increased
from 2006 to 2016, their compositional structures are stable, that is, more
than half of projects are consumers and there exist less than five percent hub
projects. It can be said that inspired by a small number of hub software
projects, newer projects are created by reusing them, and which makes software
supply chain maps larger.

Next we focus on the evolution of hub projects. As seen in Figure 9, there are
eight projects that have more than 10 out-degree links in the latest map.
Figure 11 shows the out-degree transitions of those eight projects. We found
two patterns of becoming hub projects: (i) being hubs from birth, and (ii)
becoming hubs by connecting to the network. Projects OTM, xbmc-antiquated, and
RedisDesktopManager belong to (i). These projects were widely reused from
their early periods, regardless of week connections to supply chain maps. The
out-degrees of the other projects in their early periods are relatively low.
Project reactos increased its out-degree gradually after project xbmc-
antiquated reused it in 2010 (Figure 12 (a)). Similarly, project poedit
increased its out-dgree when it connects to project reactos by using its
source files in 2014 (Figure 12 (b)). Project mame also increased its out-
dgree when it reused source files of project reactos in 2016 (Figure 12 (c)).
After connecting to the largest map in 2016, project rethinkdb was reused
widely (Figure 12 (c)). The final connections can be seen in Figure 13.

Summary: While the size of maps growing from 31 to 506 since 2006 to 2016, the
percentages of consumer projects (just reusing others), hub projects (reused
by more than five projects), and the other projects are stable: about $55\%$,
less than $5\%$, and about $40\%$ respectively. Low out-degree projects can
become hubs by connecting to hub projects.

###  5.3. RQ3: Supply Chain Lengths

Table 2. Distributions of file-level path lengths 1 | 2 | 3 | 4 | 5
---|---|---|---|---
150,294 | 12,314 | 1,480 | 30 | 6

Here we consider clone-and-own links as supply chains, and investigate their
characteristics. Figure 14 shows the distributions of chain lengths among
projects, that is, project-level paths lengths in software supply chain maps.
The length of four is the most frequent, and 10 is the longest. It is revealed
that projects are connected directly and indirectly via clone-and-own reusing.
Note that since the above mentioned links do not take into account individual
files, long chains do not mean the same files are moved to far projects on the
chains.

Table 2 presents the distributions of file-level path lengths. We see from
this result that how far same files spread in the supply chain maps. Although
most of files are moved only once across projects, some files are found to be
transferred on several projects. This result indicates that the original file
authors are sometimes in far ancestor projects.

Summary: In software supply chain maps, projects are connected with clone-and-
own supply chains. The project-level chain lengths range from one to ten, and
four is most frequent. In file-level, most of files were moved once, and only
six files had been moved six times across projects.

##  6\. Discussion

###  6.1. Implications

Our findings can be summarized into the following implications.

  * •

Many FLOSS projects are connected in a large software supply chain map. In the
studied dataset, we found that many projects form one large map, which
indicates that clone-and-own is prevalent and FLOSS projects have complex
dependencies among other projects from the point of code sharing.

  * •

Hub projects play an important role in reuse spreading. As reported in
(Gharehyazie et al., 2017), we also found hub projects that serves as reusing
sources for many projects. Such hubs influence consumer projects directly and
indirectly, and also have impact on the ecosystem evolution.

  * •

Single repositories are not self-contained. As we see the transition of file
sets across projects, it is clear that tracking original authors within single
code repositories is not enough. This fact has big impact on related work and
imply the future challenge of building a global version control system for the
entire FLOSS ecosystem.

###  6.2. Threats to Validity

Our dataset includes the most popular projects on GitHub. While the projects
include popular applications and libraries according to the number of stars,
less popular application projects can also be members of software supply chain
maps. In addition, the number of stars indicates the recent popularity; we
might have excluded projects which had been popular before GitHub was
launched. Since excluded projects cannot appear in software supply chain maps,
we should have missed existing links in our analysis, and also we might have
linked to incorrect projects because of missing appropriate projects. In order
to mitigate this threat, we will increase the number of projects to be
analyzed.

The result may be affected by programming languages and their ecosystems. For
example, in C language, a common package management system is unavailable. To
use a library, individual developers are required to install the library
package provided by an operating system vendor. To enable a platform-
independent build environment, developers have to keep library files in their
repository. On the contrary, JavaScript projects heavily use the npm package
management system to reuse functions from existing projects (Kikas et al.,
2017; Decan et al., 2018). Developers do not need to keep a copy of a library,
unless they modified the library files. Such a practice may change source code
reuse activity of developers.

There are limitations in our detection approach. Since we analyze only tagged
snapshots, we could miss the actual reused snapshots in development commits,
which are not tagged. In addition, the file similarity threshold can cut file
movement histories. Addressing these limitations can be future work.

##  7\. Related Work

###  7.1. Cross-Project Code Clone Detection

Code clone detection is the most popular approach to analyze source code reuse
activities. Since developers may modify a code fragment for their own purpose,
various tools have been proposed to detect similar source code fragmetns (Roy
et al., 2009). Kamiya et al. (Kamiya et al., 2002) proposed CCFinder that
analyzes normalized token sequences. Jiang et al. (Jiang et al., 2007)
proposed DECKARD that compares a vector representation of an abstract syntax
tree of source code. Nguyen et al. (Nguyen et al., 2009) proposed Exas that
compares a vector representation of a program dependence graph. Sasaki et al.
(Sasaki et al., 2010) proposed FCFinder that recognizes file-level clones
using hash values of normalized source files. Cordy et al. (Cordy and Roy,
2011) proposed NiCad that compares a pair of code blocks using a longest
common subsequence algorithm. Sajnani et al. (Sajnani et al., 2016) proposed
SourcererCC that compares a pair of code blocks using Jaccard index of tokens.

Code clone detection tools revealed that software developers often copy source
files from other projects. Hemel et al. (Hemel and Koschke, 2012) analyzed
vendor-specific versions of Linux kernel. Their analysis showed that each
vendor created a variant of Linux kernel and customized many files in the
variant. Ossher et al. (Ossher et al., 2011) analyzed cloned files across
repositories using a lightweight technique. They reported that projects cloned
files from related projects, libraries, and utilities. Koschke et al. (Koschke
and Bazrafshan, 2016) also reported that a relatively large number of projects
included copies of libraries. Lopes et al. (Lopes et al., 2017) analyzed
duplicated files in 4.5 million projects hosted on GitHub and reported that
the projects have a large amount of file copies.

While code clone detection tools identify similar files, further analysis is
required to identify their origins. German et al. (German et al., 2009) used
CCFinder to detect code siblings reused across FreeBSD, OpenBSD and Linux
kernels, and then investigated the source code repositories of the projects to
identify the original project of a code sibling. Krinke et al. (Krinke et al.,
2010b) proposed to distinguish copies from originals by comparing timestamps
of code fragments recorded in source code repositories. Krinke et al. (Krinke
et al., 2010a) used the approach and visualized source code reuse among GNOME
Desktop Suite projects. Our method also uses timestamps recorded in
repositories but focuses on a component level code reuse.

Gharehyazie et al. (Gharehyazie et al., 2017) analyzed cross-project code
clones of 5,753 Java projects on GitHub. They also analyzed timestamps of the
clones and reported that developers often copy an entire library, and some
projects serve as hubs (sources) of clones to other projects. The analyzed
source code is a snapshot at a certain point of time. Our study extends the
analysis by including additional programming languages and all the versions of
projects.

Ray et al. (Ray and Kim, 2012) analyzed porting of an existing feature or bug
fix across forked projects. They reported that forking allows independent
evolution but results in the significant cost of porting activity. Our maps
may help developers to understand the entire history of related projects.

Some researchers consider code reuse across projects as opportunities to
extract a reusable component. Rubin et al. (Rubin et al., 2013) reported that
industrial developers extract reusable components as core assets from existing
software products. Bauer et al. (Bauer and Hauptmann, 2013) proposed to
extract code clones across products as a candidate of a new library. Ishihara
et al. (Ishihara et al., 2012) proposed a function-level clone detection to
identify common functions in a number of projects.

Our analysis method assumes that developers simply copy source code without
obfuscation tools. Luo et al. (Luo et al., 2014) proposed a code plagiarism
detection applicable to obfuscated code. The detection method identifies
semantically equivalent basic blocks in two functions. Chen et al. (Chen et
al., 2014) proposed a technique to detect clones of Android applications using
similarity between control-flow graphs of methods. Those approaches are hard
to apply to compare a large set of source files. Ragkhitwetsagul et al.
(Ragkhitwetsagul et al., 2016) evaluated how the performance of code clone
detection and relevant techniques are affected by code obfuscations and
optimizations.

Code reuse in binary forms is also out of scope of our method. Sæbjørnsen et
al. (Sæbjørnsen et al., 2009) proposed a binary clone detection to identify
similar code fragments in binaries. Hemel et al. (Hemel et al., 2011) proposed
a binary code clone detection to identify code reuse violating software
license of a component. The method compares the contents of binary files
between a target program and each of existing components. Qiu et al. (Qiu et
al., 2015) proposed a code comparison method for a binary form to identify
library functions included in an executable file.

For Java software, Davies et al. (Davies et al., 2011, 2013) proposed a file
signature to identify the origin of a jar file using classes and their methods
in the file ignoring the details of code. German et al. (German and Penta,
2012) demonstrated the approach can detect OSS jar files included in
proprietary applications. Mojica et al. (Mojica et al., 2014) used the same
approach to analyze code reuse among Android applications. Ishio et al. (Ishio
et al., 2016) extended the analysis to automatically identify libraries copied
in a product. Differently from those approaches, our method directly compares
source files because small changes in files might be important to understand
differences between a cloned component and its original version.

###  7.2. Origin Analysis

Software projects use source code repositories to manage the versions of
source code. Although a repository tracks modified lines of code between two
consecutive versions of a file, the feature is not always sufficient to
represent a complicated change. Godfrey et al. (Godfrey and Zou, 2005)
proposed origin analysis to identify merged and split functions between two
versions of source code. The method compares identifiers used in functions to
identify original functions. Steidl et al. (Steidl et al., 2014) proposed to
detect source code move, copy, and merge in a source code repository. The
method identifies a similar file in a repository as a candidate of an original
version.

Kawamitsu et al. (Kawamitsu et al., 2014) proposed an extension of origin
analysis across two source code repositories. Their method identifies an
original version of source code in a library’s source code repository. Our
method extends the idea to a set of source code repositories.

Spinellis (Spinellis, 2016) constructed a Git repository including the entire
history of Unix versions. The unified repository enables developers to
investigate the change history of source files across projects. Since our
method visualizes the relationships among projects, construction of a similar
unified repository for related projects is a future direction of our research.

Kanda et al. (Kanda et al., 2013) proposed a method to recover an evolution
history of a product and its variants from their source code archives without
a version control. The approach compares the full contents of source files of
products, using a heuristic that developers tend to enhance a derived version
and do not often remove code from the derived version.

Antoniol et al. (Antoniol et al., 2000) proposed a method to recover the
traceability links between design documents and source files. The method
computes similarity of classes by aggregating similarity of their attribute
names to identify an original class definition in design documents. Ishio et
al. (Ishio et al., 2017) proposed a method to identify the most likely
original version of source files by aggregatting file similarity. Jewmeidang
et al. (JEWMAIDANG et al., 2018) proposed to visualize how library files are
updated in a repository using the method. Our method also adopted the approach
of aggregated similarity to track source code reuse across repositories.

To compare similar software products in detail, several tools have been
proposed. Duszynski (Duszynski et al., 2011) proposed a code comparison tool
to analyze source code commonalities from a number of similar product
variants. Sakaguchi et al. (Sakaguchi et al., 2015) also proposed a code
comparison tool that visualizes a unified directory tree for source files of
several products. Fischer et al. (Fischer et al., 2014) proposed to extract
common components from existing product variants and compose a new product.

It should be noted that our analysis method ignores code reuse of a single
file or a code fragment. A typical small-scale reuse is ad-hoc code reuse from
the Internet; it has a risk of a license violation (Sojer and Henkel, 2011).
To analyze the problem, Inoue et al. (Inoue et al., 2012) proposed a search
engine named Ichi-tracker. The tool employs existing code search engines and
CCFinder to extract similar source code fragments on the Internet. Yang et al.
(Yang et al., 2017) employed SourcererCC to identify Python functions on
GitHub that are similar to examples on StackOverflow.

##  8\. Conclusions

In this study, we defined the concept of software supply chain maps and its
construction algorithm. We built and analyzed the software supply chain maps
from 4,592 C/C++/Java projects on GitHub. The software supply chain maps show
that more than a half projects are just consumers, more than a quarter of
projects are producers, and a small number of projects are hubs. The
percentages of the project categories are stable since 2006 to 2016. The
longest software supply chain map includes 10 projects. The result shows that
the clone-and-own source code reuse has been omnipresent in the OSS projects.
To understand the source code of a software project, developers shoudl analyze
related projects including the original source files. The software supply
chain maps may help to understand how a project obtained components from
existing OSS projects, and how the project is reused by derived projects.

## References

  * (1)
  * Antoniol et al. (2000) Giulio Antoniol, Bruno Caprile, Alessandra Potrich, and Paolo Tonella. 2000.  Design-code Traceability for Object-oriented Systems.  Annals of Software Engineering 9, 1-4 (Jan. 2000), 35–58.
  * Bauer and Hauptmann (2013) Veronika Bauer and Benedikt Hauptmann. 2013.  Assessing Cross-Project Clones for Reuse Optimization. In Proceedings of the International Workshop on Software Clones. 60–61.
  * Chen et al. (2014) Kai Chen, Peng Liu, and Yingjun Zhang. 2014.  Achieving Accuracy and Scalability Simultaneously in Detecting Application Clones on Android Markets. In Proceedings of the 36th IEEE/ACM International Conference on Software Engineering. 175–186.
  * Cordy and Roy (2011) James R. Cordy and Chanchal K. Roy. 2011.  The NiCad Clone Detector. In Proceedings of the 2011 IEEE 19th International Conference on Program Comprehension (ICPC ’11). IEEE Computer Society, Washington, DC, USA, 219–220.  DOI:http://dx.doi.org/10.1109/ICPC.2011.26
  * Davies et al. (2011) Julius Davies, Daniel M. German, Michael W. Godfrey, and Abram Hindle. 2011.  Software Bertillonage: Finding the Provenance of an Entity. In Proceedings of the 8th Working Conference on Mining Software Repositories. 183–192.
  * Davies et al. (2013) Julius Davies, Daniel M. German, Michael W. Godfrey, and Abram Hindle. 2013.  Software Bertillonage: Determining the provenance of software development artifacts.  Empirical Software Engineering 18 (2013), 1195–1237.
  * Decan et al. (2018) Alexandre Decan, Tom Mens, and Philippe Grosjean. 2018\.  An empirical comparison of dependency network evolution in seven software packaging ecosystems.  Empirical Software Engineering (10 Feb 2018).  DOI:http://dx.doi.org/10.1007/s10664-017-9589-y
  * Dubinsky et al. (2013) Yael Dubinsky, Julia Rubin, Thorsten Berger, Slawomir Duszynski, Martin Becker, and Krzysztof Czarnecki. 2013.  An Exploratory Study of Cloning in Industrial Software Product Lines. In Proceedings of the 2013 17th European Conference on Software Maintenance and Reengineering (CSMR ’13). IEEE Computer Society, Washington, DC, USA, 25–34.  DOI:http://dx.doi.org/10.1109/CSMR.2013.13
  * Duszynski et al. (2011) S. Duszynski, J. Knodel, and M. Becker. 2011.  Analyzing the Source Code of Multiple Software Variants for Reuse Potential. In Proceedings of the 18th IEEE Working Conference on Reverse Engineering. 303–307.  DOI:http://dx.doi.org/10.1109/WCRE.2011.44
  * Fischer et al. (2014) Stefan Fischer, Lukas Linsbauer, Roberto E. Lopez-Herrejon, and Alexander Egyed. 2014.  Enhancing Clone-and-Own with Systematic Reuse for Developing Software Variants. In Proceedings of the 30th IEEE International Conference on Software Maintenance and Evolution. 391–400.
  * German and Penta (2012) Daniel M. German and Massimiliano Di Penta. 2012.  A Method for Open Source License Compliance of Java Applications.  IEEE Software 29, 3 (2012), 58–63.  DOI:http://dx.doi.org/10.1109/MS.2012.50
  * German et al. (2009) Daniel M. German, Massimiliano Di Penta, Yann-Gael Guéhéneuc, and Giuliano Antoniol. 2009\.  Code siblings: Technical and legal implications of copying code between applications. In Proceedings of the 6th Working Conference on Mining Software Repositories. 81–90.
  * Gharehyazie et al. (2017) Mohammad Gharehyazie, Baishakhi Ray, and Vladimir Filkov. 2017\.  Some from Here, Some from There: Cross-project Code Reuse in GitHub. In Proceedings of the 14th International Conference on Mining Software Repositories (MSR ’17). IEEE Press, Piscataway, NJ, USA, 291–301.  DOI:http://dx.doi.org/10.1109/MSR.2017.15
  * Godfrey and Zou (2005) Michael W Godfrey and Lijie Zou. 2005.  Using Origin Analysis to Detect Merging and Splitting of Source Code Entities.  IEEE Transactions on Software Engineering 31, 2 (2005), 166–181.  DOI:http://dx.doi.org/10.1109/tse.2005.28
  * Hemel et al. (2011) Armijn Hemel, Karl Trygve Kalleberg, Rob Vermaas, and Eelco Dolstra. 2011.  Finding Software License Violations Through Binary Code Clone Detection. In Proceedings of the 8th Working Conference on Mining Software Repositories. 63–72.
  * Hemel and Koschke (2012) Armijn Hemel and Rainer Koschke. 2012.  Reverse Engineering Variability in Source Code Using Clone Detection: A Case Study for Linux Variants of Consumer Electronic Devices. In Proceedings of the 19th IEEE Working Conference on Reverse Engineering. 357–366.
  * Inoue et al. (2012) K. Inoue, Y. Sasaki, Pei Xia, and Y. Manabe. 2012\.  Where does this code come from and where does it go? – Integrated code history tracker for open source systems –. In Proceedings of the 34th IEEE/ACM International Conference on Software Engineering. 331–341.  DOI:http://dx.doi.org/10.1109/ICSE.2012.6227181
  * Ishihara et al. (2012) Tomoya Ishihara, Keisuke Hotta, Yoshiki Higo, Hiroshi Igaki, and Shinji Kusumoto. 2012.  Inter-Project Functional Clone Detection toward Building Libraries – An Empirical Study on 13,000 Projects. In Proceedings of the 19th Working Conference on Reverse Engineering. 387–391.
  * Ishio et al. (2016) Takashi Ishio, Raula Gaikovina Kula, Tetsuya Kanda, Daniel M. German, and Katsuro Inoue. 2016\.  Software Ingredients: Detection of Third-party Component Reuse in Java Software Release. In Proceedings of the 13th International Conference on Mining Software Repositories. 339–350.
  * Ishio et al. (2017) Takashi Ishio, Yusuke Sakaguchi, Kaoru Ito, and Katsuro Inoue. 2017.  Source File Set Search for Clone-and-own Reuse Analysis. In Proceedings of the 14th International Conference on Mining Software Repositories (MSR ’17). IEEE Press, Piscataway, NJ, USA, 257–268.  DOI:http://dx.doi.org/10.1109/MSR.2017.19
  * JEWMAIDANG et al. (2018) Kanyakorn JEWMAIDANG, Takashi ISHIO, Akinori IHARA, Kenichi MATSUMOTO, and Pattara LEELAPRUTE. 2018.  Extraction of Library Update History Using Source Code Reuse Detection.  (March 2018).
  * Jiang et al. (2007) Lingxiao Jiang, Ghassan Misherghi, Zhendong Su, and Stephane Glondu. 2007.  DECKARD: Scalable and Accurate Tree-Based Detection of Code Clones. In Proceedings of the 29th International Conference on Software Engineering. 96–105.
  * Kamiya et al. (2002) T. Kamiya, S. Kusumoto, and K. Inoue. 2002.  CCFinder: a multilinguistic token-based code clone detection system for large scale source code.  IEEE Transactions on Software Engineering 28, 7 (2002), 654–670.  DOI:http://dx.doi.org/10.1109/TSE.2002.1019480
  * Kanda et al. (2013) Tetsuya Kanda, Takashi Ishio, and Katsuro Inoue. 2013\.  Extraction of product evolution tree from source code of product variants. In Proceedings of the 17th International Software Product Line Conference. 141–150.
  * Kawamitsu et al. (2014) Naohiro Kawamitsu, Takashi Ishio, Tetsuya Kanda, Raula Gaikovina Kula, Coen De Roover, and Katsuro Inoue. 2014.  Identifying Source Code Reuse across Repositories using LCS-based Source Code Similarity. In Proceedings of the 14th International Working Conference on Source Code Analysis and Manipulation. 305–314.
  * Kikas et al. (2017) Riivo Kikas, Georgios Gousios, Marlon Dumas, and Dietmar Pfahl. 2017.  Structure and Evolution of Package Dependency Networks. In Proceedings of the 14th International Conference on Mining Software Repositories (MSR ’17). IEEE Press, Piscataway, NJ, USA, 102–112.  DOI:http://dx.doi.org/10.1109/MSR.2017.55
  * Kim et al. (2005) Miryung Kim, Vibha Sazawal, David Notkin, and Gail Murphy. 2005.  An empirical study of code clone genealogies. In Proc. of 5th Joint Meeting of the European Softw. Eng. Conf. and the ACM SIGSOFT Symp. on the Found. of Softw. Eng. (ESEC/FSE-13). ACM, New York, NY, USA, 187–196.  DOI:http://dx.doi.org/10.1145/1081706.1081737
  * Koschke and Bazrafshan (2016) Rainer Koschke and Saman Bazrafshan. 2016.  Software-Clone Rates in Open-Source Programs Written in C or C++. In Proceedings of the 10th International Workshop on Software Clones. 1–7.
  * Krinke et al. (2010a) Jens Krinke, Nicolas Gold, Yue Jia, and David Binkley. 2010a.  Cloning and copying between GNOME projects. In Proceedings of the 7th IEEE Working Conference on Mining Software Repositories. 98–101.
  * Krinke et al. (2010b) Jens Krinke, Nicolas Gold, Yue Jia, and David Binkley. 2010b.  Distinguishing Copies from Originals in Software Clones. In Proceedings of the 4th International Workshop on Software Clones. 41–48.
  * Kula et al. (2017) Raula Gaikovina Kula, Daniel M. German, Ali Ouni, Takashi Ishio, and Katsuro Inoue. 2017\.  Do developers update their library dependencies?  Empirical Softw. Eng. (11 May 2017).  DOI:http://dx.doi.org/10.1007/s10664-017-9521-5
  * Lopes et al. (2017) Cristina V. Lopes, Petr Maj, Pedro Martins, Vaibhav Saini, Di Yang, Jakub Zitny, Hitesh Sajnani, and Jan Vitek. 2017\.  DéJàVu: A Map of Code Duplicates on GitHub.  Proc. ACM Program. Lang. 1, OOPSLA, Article 84 (Oct. 2017), 28 pages.  DOI:http://dx.doi.org/10.1145/3133908
  * Luo et al. (2014) Lannan Luo, Jiang Ming, Dinghao Wu, Peng Liu, and Sencun Zhu. 2014.  Semantics-Based Obfuscation-Resilient Binary Code Similarity Comparison with Applications to Software Plagiarism Detection. In Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering. 389–400.
  * Mlouki et al. (2016) O. Mlouki, F. Khomh, and G. Antoniol. 2016.  On the Detection of Licenses Violations in the Android Ecosystem. In 2016 IEEE 23rd International Conference on Software Analysis, Evolution, and Reengineering (SANER), Vol. 1. 382–392.  DOI:http://dx.doi.org/10.1109/SANER.2016.73
  * Mojica et al. (2014) Israel J. Mojica, Bram Adams, Meiyappan Nagappan, Steffan Dienst, Thorsten Berger, and Ahmed Hassan. 2014.  A Large-Scale Empirical Study on Software Reuse in Mobile Apps.  IEEE Software 31, 2 (2014), 78–86.  DOI:http://dx.doi.org/10.1109/MS.2013.142
  * Nguyen et al. (2009) Hoan Anh Nguyen, Tung Thanh Nguyen, Nam H. Pham, Jafar M. Al-Kofahi, and Tien N. Nguyen. 2009.  Accurate and Efficient Structural Characteristic Feature Extraction for Clone Detection. In Proceedings of the 12th International Conference on Fundamental Approaches to Software Engineering. 440–455.
  * OpenChain (2018) OpenChain. 2018\.  OpenChain Specification Version 1.2.  https://www.openchainproject.org/spec. (2018).
  * Ossher et al. (2011) J. Ossher, H. Sajnani, and C. Lopes. 2011.  File cloning in open source Java projects: The good, the bad, and the ugly. In 2011 27th IEEE International Conference on Software Maintenance (ICSM). 283–292.  DOI:http://dx.doi.org/10.1109/ICSM.2011.6080795
  * Potvin and Levenberg (2016) Rachel Potvin and Josh Levenberg. 2016.  Why Google Stores Billions of Lines of Code in a Single Repository.  Commun. ACM 59, 7 (June 2016), 78–87.  DOI:http://dx.doi.org/10.1145/2854146
  * Qiu et al. (2015) Jing Qiu, Xiaohong Su, and Peijun Ma. 2015.  Library Functions Identification in Binary Code by Using Graph Isomorphism Testings. In Proceedings of the 22nd IEEE International Conference on Software Analysis, Evolution, and Reengineering. 261–270.
  * Ragkhitwetsagul et al. (2016) Chaiyong Ragkhitwetsagul, Jens Krinke, and David Clark. 2016\.  Similarity of Source Code in the Presence of Pervasive Modifications. In Proceedings of the 16th International Working Conference on Source Code Analysis and Manipulation. 117–126.
  * Ray and Kim (2012) Baishakhi Ray and Miryung Kim. 2012.  A Case Study of Cross-system Porting in Forked Projects. In Proceedings of the ACM SIGSOFT 20th International Symposium on the Foundations of Software Engineering (FSE ’12). ACM, New York, NY, USA, Article 53, 11 pages.  DOI:http://dx.doi.org/10.1145/2393596.2393659
  * Roy et al. (2009) Chanchal K. Roy, James R. Cordy, and Rainer Koschke. 2009\.  Comparison and Evaluation of Code Clone Detection Techniques and Tools: a Qualitative Approach.  Science of Computer Programming 74, 7 (2009), 470–495.
  * Rubin et al. (2013) Julia Rubin, Krzysztof Czarnecki, and Marsha Chechik. 2013\.  Managing Cloned Variants: A Framework and Experience. In Proceedings of the 17th International Software Product Line Conference. 101–110.
  * Sæbjørnsen et al. (2009) Andreas Sæbjørnsen, Jeremiah Willcock, Thomas Panas, Daniel Quinlan, and Zhendong Su. 2009\.  Detecting Code Clones in Binary Executables. In Proceedings of the 18th ACM International Symposium on Software Testing and Analysis. 117–128.
  * Sajnani et al. (2016) Hitesh Sajnani, Vaibhav Saini, Jeffrey Svajlenko, Chanchal K. Roy, and Cristina V. Lopes. 2016\.  SourcererCC: Scaling Code Clone Detection to Big-Code. In Proceedings of the IEEE/ACM 38th IEEE International Conference on Software Engineering. 1157–1168.
  * Sakaguchi et al. (2015) Yusuke Sakaguchi, Takashi Ishio, Tetsuya Kanda, and Katsuro Inoue. 2015.  Extracting a Unified Directory Tree to Compare Similar Software Products. In Proceedings of the 3rd IEEE Working Conference on Software Visualization. 165–169.
  * Sasaki et al. (2010) Yusuke Sasaki, Tetsuo Yamamoto, Yasuhiro Hayase, and Katsuro Inoue. 2010.  Finding File Clones in FreeBSD Ports Collection. In Proceedings of the 7th IEEE Working Conference on Mining Software Repositories. 102–105.
  * Sojer and Henkel (2011) Manuel Sojer and Joachim Henkel. 2011.  License Risks from Ad Hoc Reuse of Code from the Internet.  Commun. ACM 54, 12 (2011), 74–81.  DOI:http://dx.doi.org/10.1145/2043174.2043193
  * Spinellis (2016) Diomidis Spinellis. 2016\.  A repository of Unix history and evolution.  Empirical Software Engineering 22, 3 (aug 2016), 1372–1404.  DOI:http://dx.doi.org/10.1007/s10664-016-9445-5
  * Steidl et al. (2014) Daniela Steidl, Benjamin Hummel, and Elmar Juergens. 2014\.  Incremental Origin Analysis of Source Code Files. In Proceedings of the 11th Working Conference on Mining Software Repositories. 42–51.
  * Xia et al. (2013) Pei Xia, Makoto Matsushita, Norihiro Yoshida, and Katsuro Inoue. 2013.  Studying Reuse of Out-dated Third-party Code in Open Source Projects.  JSSST Computer Software 30, 4 (2013), 98–104.
  * Yang et al. (2017) Di Yang, Pedro Martins, Vaibhav Saini, and Cristina Lopes. 2017\.  Stack Overflow in Github: Any Snippets There?. In Proceedings of the 14th International Conference on Mining Software Repositories (MSR ’17). IEEE Press, Piscataway, NJ, USA, 280–290.  DOI:http://dx.doi.org/10.1109/MSR.2017.13