arXiv:2606.23495v1 [cs.SE] 22 Jun 2026
Ensuring Open Source Integrity: The Intersection of Copy-Based Reuse and License Compliance 1st Mahmoud Jahanshahi
2nd Bogdan Vasilescu
3rd Audris Mockus
University of Tennessee Knoxville, USA [email protected]
Carnegie Mellon University Pittsburgh, USA [email protected]
University of Tennessee Knoxville, USA [email protected]
Abstract—As other creative work, source code is protected by copyright. The owner can license the work, e.g., to permit copy and other kinds of use, and even start legal proceeding against license violators. However, source code can be reused in subtle ways, e.g., via copying without explicit package manager dependencies, making it hard to reason about potential license noncompliance. Using the World of Code infrastructure approximating the entirely of open source software, in this paper we create a copy-based code reuse network mapping direct copying across projects, and use it to quantify the extent of potential license noncompliance across the entire open source ecosystem. In addition, we estimate regression models to understand whether code copying is affected by the origin project’s license, and, if so, how it varies with other project characteristics. We find that code in repositories with permissive licenses, such as MIT and Apache, shows higher likelihood of reuse across programming languages. In contrast, copyleft licenses, like the GPL, exhibit mixed effects. Public domain licenses, despite their aim of allowing unrestricted use, are associated with lower likelihood of copy-based reuse. A widespread potential license noncompliance appears to accompany copy-based reuse, with 39.4% of project combinations at potential noncompliance risk, particularly when licenses are unclear or absent. Our findings reveal that only 2.43% of reuse detected through the copy-based network was discoverable via dependency analysis, highlighting the limitations of existing dependency-tracking tools in capturing copy-based reuse. This gap underscores the need for more advanced methods to ensure license compliance in open source projects, from nudging developers to set appropriate license templates to flagging potential noncompliance due to license changes across copy origin and destination projects. Index Terms—Software License, Open Source Software, Open Source License, Copy-based Reuse, Software Supply Chain, World of Code, License Compliance
I. I NTRODUCTION Open Source Software (OSS) plays a critical role in software development and distribution across various industries. A fundamental aspect of OSS is its licensing, which dictates how software can be reused, modified, and redistributed. However, not all OSS participants are aware of or follow the ramifications of licensing [1]. For example, their code is under exclusive copyright by default if no license is specified. The lack of knowledge, and/or, possibly, the lack of enforcement, results in reuse of unlicensed code in contexts where license incompatibilities are likely. For example, with the rise of large language models (LLMs), a significant portion of the massive Replication package available at: https://zenodo.org/records/14061115
source code used for training consists of code without any license [2], [3], [4]. OSS licenses are typically categorized into permissive licenses (e.g., MIT, Apache), copyleft licenses (e.g., GPL), weak copyleft licenses (e.g., LGPL), public domain licenses, and others with specific conditions (e.g., Creative Commons). Each type of license imposes distinct obligations on developers and users, making the choice of license a pivotal factor in determining the extent and manner in which a project’s code can be reused. Moreover, creative works, such as code, are protected by copyright by default if no license is specified. Despite these legal restrictions, code without a license is often copied in practice [5] and even used to train Large Language Models [3]. This study aims to enhance understanding of the extent to which, and the contexts in which, different OSS license types affect software reuse in copy-based reuse networks, where artifacts are copied from one repository to another. While prior research has primarily focused on dependencybased reuse, where projects formally declare dependencies on external libraries, copy-based reuse—where code is directly copied between projects—introduces unique challenges regarding license compliance and tracking, because there is typically no trace of the copying. Studies highlight that identifying the exact origin of reused OSS components remains a significant challenge, underscoring the need for more effective tools to track code provenance, particularly to ensure compliance with copyleft licenses [6]. Although copy-based reuse is common in OSS development [7], it is often overlooked in studies that focus exclusively on dependencies managed through package managers [8], [9], [10]. While the decision to copy an artifact from an upstream project may be driven by factors largely unrelated to license compatibility, the type of license should still play a significant role, particularly if the license of the copied artifact is ultimately incompatible with that of the reusing project. Specifically, we answer the following research questions: • RQ1: How does the license type of the upstream project affect the probability of its artifacts getting copied? • RQ2: How widespread is potential license noncompliance in copy-based reuse network? We begin by reviewing the literature on code copying to identify key factors driving this phenomenon. Next, we use the
World of Code (WoC) infrastructure, which provides comprehensive, cross-referenced data on the global OSS ecosystem, to operationalize these factors and create a curated dataset of copying instances, including the licenses of both upstream and downstream projects. Finally, we fit a model that examines the probability of a project’s artifacts being reused based on its license, while controlling for other contextual factors. Our findings indicate that permissive licenses, such as MIT and Apache, are consistently associated with higher reuse rates across multiple programming languages. In contrast, copyleft licenses, like GPL, display more complex reuse patterns. While they are associated with higher rates of reuse in certain cases, such as in JavaScript projects, they are generally associated with lower reuse when factors like project size and activity are considered. Interestingly, projects under public domain licenses, which are intended to permit unrestricted reuse, tend to experience lower reuse rates. This suggests that legal uncertainties surrounding these licenses may deter developers from reusing the code. One notable issue we uncovered is the prevalence of license noncompliance in copy-based reuse, especially when projects either lack a clear license or use incompatible licenses, posing legal risks for developers and organizations alike. License noncompliance in software reuse is not just a theoretical concern but has resulted in significant legal disputes in the software industry. A notable example is the Jacobsen v. Katzer case [11], wherein the court upheld the enforceability of open source licenses under copyright law. Jacobsen, the creator of the Java Model Railroad Interface (JMRI) project, sued Katzer for incorporating JMRI’s code into commercial software without adhering to the terms of the project’s Artistic License. The court’s decision affirmed that violating open source license terms constitutes copyright infringement, emphasizing the legal obligations developers have when reusing code. Another case illustrating the repercussions of license noncompliance involves the GPL-licensed BusyBox OSS project [12]. BusyBox developers filed lawsuits against several companies for distributing their software within commercial products without complying with GPL terms. These companies failed to provide access to the source code and did not include the GPL license text with their products, both required under the GPL. The legal actions often resulted in settlements where the offending companies agreed to release the source code and comply with the GPL terms. These real-world examples underscore the importance of understanding and adhering to license terms, especially in copy-based reuse where code is directly replicated between projects. Noncompliance not only exposes developers and organizations to legal risks but also undermines the collaborative ethos of the OSS community [10]. It can deter developers from contributing or reusing code due to fears of infringement, thereby stifling innovation and collaboration. Therefore, ensuring proper license compliance is essential for fostering trust and sustainability in open source software development. Finally, our study reveals that traditional tools focused on dependency tracking fail to capture a substantial number
of reuse cases occurring through direct code copying. This highlights the need for more sophisticated tools capable of detecting direct code copying at scale, to improve license compliance monitoring within the OSS ecosystem. II. R ELATED W ORK AND K NOWLEDGE G APS A. Software Reuse In open source software, the reuse within supply chains can be categorized based on how open source components are integrated and used in software projects [13], [14], [15]. 1) Dependency-Based Reuse: This category involves incorporating open source libraries and packages as dependencies in a project. Package managers like NPM for JavaScript, pip for Python, or Maven for Java are typically used to manage these dependencies. If not properly overseen, reliance on these dependencies can introduce vulnerabilities and risks [16]. 2) Copy-Based Reuse (Our Focus): In copy-based reuse, developers directly copy code from OSS projects, e.g., a utility function [7], into their own projects. While this approach is quick, it can lead to challenges in maintaining and updating the copied code. Therefore, it’s essential to track and manage these copies to ensure they remain secure and up-to-date [17]. Previous studies have identified several factors that influence the likelihood of a project’s artifacts being reused through copy-based methods [7]. One key factor is project activity, typically measured by the number of commits. Projects with a higher commit count are generally more active and frequently updated, making them attractive to developers seeking reliable and current code snippets [18]. Another important factor is project size, often indicated by the number of files. Larger projects tend to offer a broader range of functionalities and code examples, increasing the likelihood that other developers will find useful code for reuse. This extensive codebase provides a valuable resource for copy-based reuse [19]. The collaborative nature of a project also plays a role. Metrics such as the number of authors reflect the volume and diversity of expertise within a project’s contributor base. Projects with more contributors tend to benefit from enhanced innovation and decentralized communication, which can improve the development process [20] and increase the likelihood of reuse [7]. Community engagement and popularity, often approximated by metrics such as the number of forks and stars on platforms like GitHub, further explain reuse potential [21], [22]. Projects with more forks and stars are more visible and reputable within the developer community, increasing trust and making their code more likely to be reused [7]. These indicators reflect community interest and endorsement, enhancing the project’s appeal as a resource. The maturity and stability of a project, assessed through its duration of activity, age, and activity fluctuations (burstiness), also correlate with its reuse potential [7]. Mature projects with sustained activity over a long period are often viewed as stable and reliable. Consistent development without erratic bursts signals a well-maintained project, increasing the likelihood that its code will be reused [23]. Additionally, a
2
project’s community culture and technical characteristics— approximated by its primary programming language—play a significant role in explaining its reuse potential [7]. Different programming languages vary in popularity, community support, and ecosystem maturity [24]. Projects written in widely adopted languages such as Python, JavaScript, or Java are more accessible to a larger pool of developers, thus increasing the chances of their code being reused. Moreover, the programming language reflects the community’s coding conventions, documentation practices, and collaboration norms, which can make the project more appealing for developers looking to incorporate its code into their own work. Finally, the literature highlights that permissive licenses, such as MIT and BSD, are generally associated with higher reuse rates compared to restrictive licenses like GPL [25], [26]. Additionally, a delay in license adoption for a project might increase the chances of its artifacts being reused as the absence of a clear license can create ambiguity, leading developers to assume permissibility, thus fostering reuse even if unintended by the project maintainers. However, these conclusions are based on simple statistical analyses that do not account for the critical factors influencing reuse discussed earlier. Therefore, it is possible that the observed effect of licensing on reuse is not as strong as suggested, or that other variables may be driving these patterns. A more comprehensive analysis—one that controls for these additional variables—is necessary to determine whether licensing independently influences reuse or if the previously-reported results are mostly shaped by other project characteristics. Towards answering RQ1, we posit two concrete hypotheses: • Hypothesis (H1a): Projects using permissive licenses, when controlling for other context factors, have a higher likelihood of their artifacts being reused via copying. • Hypothesis (H1b): Projects using restrictive licenses, when controlling for other context factors, have a lower likelihood of their artifacts being reused via copying.
long as the LGPL-covered components remain modifiable and separable. However, it’s important to carefully consider the terms to avoid violations, particularly regarding modification and distribution [30]. Conditional open licenses, including many Creative Commons licenses, offer specific conditions for use. For example, CC-BY licenses require attribution, while CC-BY-SA licenses require derivative works to be licensed under the same terms. These licenses can include share-alike clauses, which impact how code can be distributed, especially if combined with other licenses with different terms. While these licenses are more commonly used for creative works than software, they can still impact code distribution. Public domain and license-free software code generally impose no restrictions on reuse, as they are not protected by copyright. Works in the public domain can be freely used, modified, and distributed. Finally, projects with no explicit license (not to be confused with license-free) present significant legal risks. By default, all rights are reserved under copyright law, meaning that reuse, modification, or distribution may be restricted without the author’s explicit permission [31]. This lack of clarity can lead to potential legal issues, as the permissions for using the software are not clearly defined. C. Open Source License Compliance License compatibility is a critical concern in OSS development. Projects often encounter significant difficulties when integrating components with conflicting licenses [32]. Ensuring compliance with open source licenses is also a major concern for companies incorporating OSS into their products. German et al. [10] emphasized the need for auditing OSS distributions to ensure adherence to license terms, especially in scenarios where components with varying licenses are integrated. Wu et al. [33] conducted a large-scale empirical analysis on the usage of open source licenses, highlighting the practices and challenges developers face. Their findings revealed frequent misunderstandings and misapplications of licenses, especially in large-scale projects. Cui et al. [34] created a tool called DIKE to detect license conflicts in over 16,000 popular free and OSS software, finding that over 25% had conflicts. In addition, their study suggests that these conflicts often arise from misinterpretations of license terms and the challenges of handling multi-license environments. Finally, Mathur et al. [35] conducted an empirical study on license violations resulting from code reuse across 1,423 projects, uncovering numerous instances of license incompatibilities. In addition, many developers involved in OSS projects do not fully understand the implications of the licenses they use. Almeida et al. [1] and Almeida et al. [36] revealed gaps in developers’ knowledge of licensing issues, which can result in non-compliance, particularly in complex projects that integrate multiple OSS components. Moraes et al. [37] and Qiu et al. [38] focused on the JavaScript ecosystem, investigating the effects of multi-licensing and license violations related to dependencies. Their findings show that the complex network of dependencies in JavaScript projects frequently results in unintentional license violations, highlighting the need for
B. Open Source Licenses There are many licenses for open source code, each with its own requirements and restrictions. Permissive licenses, such as MIT and Apache-2.0, typically allow for extensive reuse with few restrictions. They usually require only attribution and permit integration with other license types, offering significant flexibility [27]. In contrast, copyleft licenses, such as the GPL, require that any derivative work be distributed under the same license. Noncompliance can occur if copyleft-licensed code is combined with code under a non-copyleft license without adhering to the copyleft terms. For example, incorporating GPL-licensed code into proprietary software without releasing the combined code under the GPL would violate the license [28]. This principle ensures that all modifications and derivative works remain free, preserving software freedom [29]. Weak copyleft licenses, such as the LGPL, are less restrictive than full copyleft licenses. They permit linking with proprietary software without requiring the entire work to be open sourced, as
3
improved dependency management practices. Feng et al. [39] investigated license violations in large-scale binary software, revealing that many projects unintentionally breach license terms due to the complexities involved in binary distribution. Finally, Papoutsoglou et al. [40] examined licensing questions on Stack Exchange sites, their results showing that many developers find it challenging to grasp licensing terms, leading to frequent inquiries about compliance and compatibility issues. Studies have also demonstrated that a project’s declared license is not always reliable [10], [41], [42]. For example, in a study of OSS projects on GitHub, Wolter et al. [42] discovered that in approximately 50% of the projects analyzed, the top-level declared license did not fully reflect all the licenses present within the project, emphasizing the importance of improved education and automated tools for ensuring compliance. Moreover, Wu et al. [43] found instances where the license of a source code file was altered after being copied, both by the original author of the code, and by the reuser; the latter likely constitute a license violation. The complexities of OSS licensing are further heightened by the widespread practice of copy-based code reuse, which can lead to unintended license violations [7]. Managing license compliance in these scenarios is crucial for maintaining the integrity of open source projects. Jahanshahi et al. [7] showed that 80% of OSS projects have practiced copy-based reuse, including large and popular projects. They also demonstrated that a significant portion of the reused artifacts originate from small, lesser-known projects. Given the widespread prevalence of copy-based reuse and the complexities of tracking the origins of artifacts, we anticipate a high potential risk of license noncompliance in this type of reuse. This issue becomes even more critical considering that copy-based reuse is generally overlooked both by prior research and practitioners, thereby increasing the overall risk for the OSS community. Towards answering RQ2, we hypothesize that: • Hypothesis (H2a): Copy-based reuse carries a high risk of license noncompliance due to compounded complexities in tracking artifact origins. • Hypothesis (H2b): By overlooking copy-based code reuse, we are missing a significant portion of license noncompliance issues in open source software.
of Code [46]) for files containing the word “license” in their filepath. This includes not only standard license files but also any file that may contain licensing information, ensuring no (obvious) potential license data is overlooked. 2) Scale and Scope of Analysis: Previous studies often concentrate on specific platforms (e.g., GitHub), particular package manager ecosystems (e.g., NPM), or a narrow range of licenses (e.g., OSI-approved), leading to a partial approach to license detection and analysis. For instance, the work by Feng et al. [39] maps binary code to source code, detecting instances where code is directly incorporated into binary software. While theoretically feasible, this approach encounters significant scalability challenges due to the substantial processing power required for large-scale analysis. The computational demands of binary-to-source mapping render it impractical for use across the entire open-source ecosystem, especially when dealing with diverse binaries and platforms. In contrast, our work examines the entire open-source ecosystem, offering a more comprehensive, cross-platform perspective on licensing violations. By focusing on scalable methods that encompass various licenses, package managers, and code reuse practices, our approach addresses the scale limitations of prior studies, while providing a more practical solution for detecting license violations across the open-source landscape. Moreover, our approach is not limited to code reuse; it can identify reuse across various types of artifacts, including documentation, configuration files, and other non-code components. This capability offers a more comprehensive perspective on reuse and the associated licensing challenges.
D. Our Study vs Prior Work
3) Controlling for Project Context: Compared to prior research, our work reflects a more nuanced analysis of the relationship between software licensing and code reuse. Unlike earlier studies that primarily used bivariate statistical correlations [25], [26], we use a more sophisticated methodology that accounts for covariates, such as project size, community activity, and programming language. By controlling for these factors, our work provides a clearer understanding of whether licensing type—permissive versus restrictive—independently influences reuse probability. This allows us to re-examine the claims made in prior studies and offers more robust insights into the impact of licensing on OSS reuse.
Our work offers a comprehensive and practical approach to identifying and addressing potential licensing issues arising from copy-based reuse in open source software, and it distinguishes itself from prior research in several ways: 1) Comprehensive Identification of Licenses: Most studies, including those by Wu et al. [33] and Xu et al. [44], rely heavily on explicit license declarations in metadata files. Others, like Feng et al. [39], use static analysis of binaries to detect embedded license texts. However, these approaches can miss licenses that are not explicitly declared or are located in less conventional directories. In contrast, our work analyzes a comprehensive dataset [45] created by exhaustively scanning the entire OSS landscape (as reflected in the World
4) Analysis of License Violations in Copy-based Reuse: While many studies have explored license conflicts, few have employed a copy-based reuse network approach to understand the reuse patterns and potential violations and they often focus only on dependency-based reuse networks. As shown recently [7], copy-based reuse is prevalent and contributes significantly to reuse practices in OSS. Our research uses the copy-based reuse network to identify potential license violations due to license incompatibilities and reuse patterns, providing a novel perspective on how licenses interact across repositories. This not only reveals license conflicts but also traces their origins, facilitating targeted resolutions and ensuring compliance across the software ecosystem.
4
III. M ETHODOLOGY
all commits creating a blob, with the project associated with the earliest commit identified as the creator. Projects with any subsequent commits are then identified as reusers of that blob. Next, since we are interested in a project-level analysis and since projects may reuse many blobs from one another, we further aggregated the data based on unique combinations of upstream and downstream projects, counting the number of reused blobs between these projects for each combination. The total number of unique upstream-downstream project combinations was 1,815,996,757. Given our focus on potential license noncompliance, we excluded all instances of code reuse where the same entity (account) owns both the source and target projects. This further reduced the data down to 1,788,541,220 combinations, indicating that about 1.5% of reuse instances occurred between projects with the same owner. Furthermore, given that the distribution of copied blob counts between projects is heavily right-skewed, we analyze potential noncompliance within the reuse network in two distinct modes to gain better insights. First, we consider complete reuse, including any instance where at least one blob has been copied in our analysis. Second, we refine the data to focus on reuse instances where at least ten blobs have been copied between upstream and downstream projects, as a proxy for more deliberate and substantial reuse.
A. World of Code Infrastructure World of Code (WoC)1 [46] is an infrastructure developed to cross-reference source code change data across the entire OSS community, enabling sampling, measurement, and analysis both within and across software ecosystems [46], [47]. Essentially, WoC functions as a software analysis pipeline, handling data discovery and retrieval, storage and updates, as well as the transformations and augmentations required for subsequent analytical tasks [47]. WoC provides various maps that link git objects and metadata (e.g., commits, blobs, authors) to each other. It also offers more advanced maps, such as project-to-data connections (e.g., project-to-author), author aliasing [48], and project deforking maps [49]. In our study, we use WoC’s project-to-license (P2L) map [45], which shows the licenses committed to each project in its most recent state (Version V of WoC, updated in March 2024). 2 Additionally, we apply the concept of deforked projects, as introduced by Mockus et al. [49], to minimize potential biases caused by forks and duplicates of the same project. Throughout this paper, the term “project” refers to these deforked projects unless stated otherwise. B. Copy-based Reuse Network In the context of OSS development, analyzing code reuse is essential for understanding the propagation of software components and the associated licensing implications. Traditionally, the literature has primarily focused on dependencybased reuse, where the relationships between projects are analyzed based on declared package-manager dependencies, such as libraries or frameworks included in a project. While dependency-based analysis provides valuable insights into how projects rely on external components, it often overlooks the more granular aspect of direct code copying, which can occur independently of formal dependencies. Such practices are common in OSS projects but often remain undetected in dependency-based analyses, as shown by Jahanshahi et al. [7]. By mapping these direct copies, a copy-based reuse network provides a comprehensive view of code propagation, highlighting the actual flow of code between projects. In the realm of license compliance, dependency-based analysis often focuses on the licenses of declared dependencies. However, license obligations are not limited to these formal dependencies. Copy-based reuse, particularly when undetected, can lead to unintentional license violations. By mapping direct code copying, a copy-based reuse network allows for the identification of potential licensing conflicts that may arise from incorporating code with incompatible license terms, when the code wasn’t part of a declared dependency. To track this kind of reuse, WoC offers the Ptb2Pt map, which lists reused blobs (i.e., file versions) along with the creator, reuser, and the time each project first committed that blob [50]. This map is created by sorting the timestamps of
C. Potential License Noncompliance Noncompliance can manifest in various ways, often resulting in substantial legal and operational risks. For example, it can occur when there are conflicts or misunderstandings regarding the terms and conditions of these licenses. To better understand the associated risks, we categorize the outcomes of license combinations into three levels: No Issues, Potential Issue - Low Risk, and Potential Issue - High Risk. a) No Issues: This category covers situations where combining different licenses does not create legal or practical issues. Projects under these licenses can be freely integrated, modified, and redistributed without concern for restrictive terms. For instance, public domain and permissive licenses, such as the MIT or Apache 2.0 licenses, generally impose minimal restrictions. These licenses are designed to encourage widespread use and modification, making them highly compatible with other licenses. Their permissive nature ensures that they do not impose additional restrictions on combined works, allowing for seamless integration with other projects [27], [30]. b) Potential Issue - Low Risk: These combinations produce minor or manageable incompatibilities, such as attribution, notice preservation, or compliance with specific conditions. For example, weak copyleft licenses, such as the LGPL, allow linking with proprietary software, provided that modifications to the LGPL-covered code remain open-source. This flexibility reduces the likelihood of significant legal issues when combined with other licenses. Similarly, licenses such as the Mozilla Public License (MPL) require modified files to be distributed under the same license but allow linking with other code, thus posing only minor issues [51].
1 https://worldofcode.org 2 Version V, the most recent at the time of this study.
5
conservative scenario—to quantify how often noncompliance is detectable through conventional methods (package manager analysis) versus cases that require copy-based detection. To keep the analysis tractable we selected a sample of 50,000 unique upstream-downstream project pairs from our dataset. Using a stratified sampling, we proportionally selected from each of the 16 high-risk categories, which together represent a total of 82 million projects. To ensure adequate representation of smaller categories, a minimum sample size of 1,000 was enforced, even when the proportional size was smaller. This approach ensures sufficient representation from smaller categories while maintaining overall proportionality. Our final sample included a total of 57,341 project combinations. Next, we used the maps provided in WoC, which detail all import and export statements in every blob for each commit. By analyzing these maps, we identified all import/export statements within the projects in our sample3 . We then matched these statements between upstream and downstream projects to determine if they share any declared dependencies (i.e., the downstream project imports a package that the upstream project exports).
TABLE I L ICENSE R EUSE M ATRIX AND P OTENTIAL N ONCOMPLIANCE S CENARIOS To From Permissive Copyleft Weak Copyleft Conditional Public Domain No License
Permissive
Copyleft
Weak Copyleft
Conditional Open
Public Domain
No License
No High Low Low No High
No No No High No High
No High No High No High
No High Low High No High
No High Low Low No High
Low High High High No High
c) Potential Issue - High Risk: These combinations can create substantial legal or practical obstacles. These issues typically arise from strict copyleft provisions or other incompatible conditions that limit the redistribution, modification, or integration of the software. For instance, strong copyleft licenses, such as the GPL, require that any derivative works be licensed under the same terms. This requirement can conflict with other licenses, especially those that are more permissive or do not allow for relicensing under the GPL’s terms. Such incompatibilities can prevent the distribution of combined works, necessitating careful consideration and potentially complex legal negotiations [28], [52]. The matrix in Table I outlines various reuse scenarios and the corresponding risks of license noncompliance. We use this rationale in RQ2 to identify and categorize potential license noncompliance in our copy-based reuse network. We use projects’ latest status licenses for this examination. Since both upstream and downstream projects may have multiple licenses, we evaluate all combinations of possible noncompliance to test hypothesis H2a. However, there is an aggregation design decision here: how to aggregate possible noncompliance combinations of licenses with different risk levels for the same pair of upstream–downstream projects? We consider two options. For a high sensitivity approach, we select the highest risk level combination of licenses for a given pair of upstream–downstream projects. Conversely, for a low sensitivity approach, we select the lowest risk level combination.
E. Regression Model In RQ1, we investigate whether the upstream project’s license type affects the likelihood of its artifacts getting reused, testing hypotheses H1a and H1b. Since the response variable is binary (1 if the project has introduced at least one reused blob, 0 otherwise), a logistic regression model is used. It is the standard approach for binary outcomes and enables us to estimate the probability of reuse from various predictors [53]. 1) Stratified Sampling: Given the scale and diversity of OSS projects, we employed a stratified sampling approach to ensure that our regression model accurately represents the OSS landscape [54]. Projects were divided into strata based on six key variables: number of commits, blobs, authors, forks, active months, and earliest commit time. These variables reflect project size, activity, and history, all of which are likely to influence our outcome variables, as discussed in Sec. II above. The strata were defined as follows: number of commits (fewer than 500, 500–2000, and more than 2000), number of blobs (fewer than 10,000 and more than 10,000), number of authors (one author, 2–10 authors, and more than 10 authors), number of forks (no forks and at least one fork), and active months (fewer than three months and more than three months). Additionally, we categorized projects into four historical eras based on their earliest commit time: the Foundational Era (before 1998), the Dot-com Boom and OSS Expansion (1998–2010), the Maturation and Mainstream Adoption phase (2010–2018), and the Modern Era with a Community Focus (2019–present). This stratification resulted in 288 unique bins. We sampled projects from each bin, yielding a final dataset of approximately half a million projects. While some bins contained fewer projects than anticipated due to uneven distribution,
( max risk(LAi , LBj ) : High Sen. ComplianceA,B = min risk(LAi , LBj ) : Low Sen. where: • LAi : Each license of Project A, • LBj : Each license of Project B, • risk(LAi , LBj ): Incompatibility risk level between license LAi and license LBj . For brevity, we present and discuss only the low-sensitivity results below, but include the high-sensitivity results in our replication package, for completeness. D. Copy-based vs. Dependency-based Reuse To test our hypothesis H2b, we compare the reuse instances captured via copy-based network with dependency-based network. For this analysis, we focus on high-risk categories in low-sensitivity mode with 10 or more reused blobs—our least
3 Analyzed languages: Java, JavaScript, Python, R, Rust, Scala, C#, Go, Groovy, Kotlin, and Perl.
6
this approach ensures that our sample is representative of the broader OSS ecosystem, allowing for robust and generalizable conclusions from our analyses. 2) Predictors: Checking for correlations among predictors is crucial in regression models, as multicollinearity—strong correlations between predictors—can distort the results and reduce reliability [55]. To manage multicollinearity, we applied a 0.6 correlation threshold. Variables with correlations exceeding this threshold indicate overlapping information, and removing them helps mitigate multicollinearity while retaining the most important predictors and their portion of explained variance [56]. The descriptive statistics for the remaining variables are provided in Table II. While we removed highly correlated numerical variables to avoid multicollinearity, this approach cannot be directly applied to categorical variables. Therefore, we included interaction terms between two categorical variables—license type and programming language—in our model to better capture the combined effect of these factors on reuse probability. This approach allows us to account for potential interactions between these variables, offering a more nuanced understanding of how different license types may influence reuse within the context of specific programming languages. Additionally, we applied sum contrasts for these two predictors, also known as effect coding, where each level of the predictor is compared to the overall mean of all levels. This method allows for a more balanced interpretation of coefficient estimates, by contrasting each category with the overall mean rather than a specific reference category. In sum contrasts, the coefficients for all levels, including the intercept, sum to zero, ensuring that one level’s coefficient is determined by the others, thereby maintaining balance and enhancing interpretability in the model.
Fig. 1. Simple Model - Odds Ratios and 95% Confidence Intervals.
permissive licenses, they unexpectedly show higher odds of reuse than public domain licenses. Recall, this initial model does not account for other potential factors that may influence reuse. Consequently, while the preliminary results provide valuable insights, they may be confounded by unconsidered variables. To address this limitation, we introduce a second model incorporating additional control variables, which allows for a more precise analysis of the true impact of license type on artifact reuse. Table III presents the ANOVA results for this model, showing that all predictors have highly statistically significant coefficients (p-values close to zero; not surprising given our sample size), and allowing for a comparison of relative explanatory power of each variable (the Deviance column). Almost all control variables had the hypothesized effects, except for burstiness, which seems to be encouraging reuse; however, its deviance is relatively low. The regression coefficient estimates are also shown in this table for non-categorical variables4 . Note, while a categorical variable may be significant in the model based on ANOVA results, indicating it contributes meaningfully, the coefficients for some individual levels of the variable can still be insignificant. This suggests that, although the variable as a whole impacts the outcome, not every category within it shows a statistically significant effect. Similarly to the previous model, Figure 2 displays the odds ratios and their corresponding 95% confidence intervals for the significant license variables. When additional control variables such as programming language and its interaction with license types are introduced into the model, the results reveal a more nuanced understanding of how these license types influence software reuse. Significant results are observed only in specific combinations of license types and programming languages. For permissive licenses, Python, C/C++, and JavaScript projects exhibit an odds ratio greater than 1, indicating an increase in reuse. The positive impact of permissive licenses is significant only for these three programming languages, while other languages do not show statistically significant effects. The first model suggested that public domain licenses are negatively associated with reuse, and the second model confirms that this effect is significant only for JavaScript and Ruby, with no notable impact in other languages. This finding implies that public domain licenses may lack the legal incentives or protections that developers value, making them less attractive for promoting reuse in certain contexts. Hypothesis H1a is therefore partially supported.
IV. R ESULTS AND D ISCUSSION A. RQ1 - Regression Model 1) Our Findings: To establish a baseline, we first modeled the probability of reuse based solely on the project’s license type, without considering other potential factors. This initial model showed a significant relationship between license type and reuse likelihood. Specifically, projects with permissive, copyleft, or weak copyleft licenses were more likely to have their artifacts reused, while those with public domain licenses were less likely to be reused. To assess the impact of the variables with significant coefficients, we examine the odds ratios derived from the logistic regression coefficients. An odds ratio greater than 1 signifies a positive impact, whereas an odds ratio less than 1 indicates a negative impact. Figure 1 presents the odds ratios along with their corresponding 95% confidence intervals. Based on these findings, hypothesis H1a is partially supported. Projects with permissive licenses, such as MIT and BSD, have higher reuse rates; however, those with public domain licenses do not follow this pattern. Similarly, hypothesis H1b receives partial support: while restrictive licenses generally exhibit a lower probability of reuse compared to
4 The p.value (P r(> |z|)) for all this variables are close to zero (< 2.2e−16 ).
7
TABLE II R EGRESSION M ODEL - D ESCRIPTIVE S TATISTICS Variable
Description
Statistics
Reuse
Introduced at least 1 reused blob
Yes:
444,144 (77.62%)
No:
5% Median Mean EarliestCommit Time since the earliest commit 05/08/2006 07/05/2017 01/31/2016 LatestCommit Time since the latest commit 04/30/2011 02/17/2020 03/15/2019 CoreAuthors Authors with 80%+ of commits 1 2 8.62 Forks Number of forks 0 0 27.66 Commits Number of commits 2 155 2,982.63 Files Number of files 5 1,820 17,295.57 AdoptDelay Earliest commit to license adoption (days) 0 0 133 Burstiness (Latest - Earliest) / Active months 0 1 1.87 ....................................................................... Language JavaScript C/C++ Python Java PHP Ruby Counts (%) 221,588 (38.72%) 82,551 (14.43%) 53,468 (9.34%) 50,372 (8.80%) 44,952 (7.86%) 18,592 (3.25%) ....................................................................... License No License Permissive Copyleft Weak Copyleft Conditional Open Counts (%) 263,974 (46.13%) 148,320 (25.92%) 60,925 (10.65%) 43,143 (7.54%) 30,933 (5.41%)
Df
Deviance
Pr(>Chi)
Coefficient
1 1 1 1 1 1 1 1 11 5 55
5,396 30,987 8,143 7,994 23,749 65,912 662 128 7,710 874 1,799
< 2.2e−16 < 2.2e−16 < 2.2e−16 < 2.2e−16 < 2.2e−16 < 2.2e−16 5.75e−146 1.42e−29 < 2.2e−16 1.20e−186 < 2.2e−16
5.60e−01 −1.49e−01 2.56e−01 4.05e−01 2.57e−01 2.80e−01 2.05e−02 6.68e−02 Cat. Cat. Cat.
95% 11/23/2021 04/28/2023 17 48 5,770 59,939.60 751 6.37 (Remaining) 100,650 (17.59%) Public Domain 24,878 (4.35%)
thus in contrast to H1a. Several factors may contribute to this unexpected result. One possibility is legal uncertainty; the concept of dedicating works to the public domain is not consistently recognized across jurisdictions. In some countries, authors cannot fully waive their copyright, leading to ambiguities that might deter developers from reusing public domain code. Additionally, the absence of explicit permissions can create confusion. Although public domain status implies freedom of use, developers and organizations may prefer licenses that clearly state permissions and limitations, such as the MIT or BSD licenses, which provide explicit legal reassurances. The perceived lack of explicit disclaimers or warranties in public domain software might also make it appear riskier, particularly for commercial use. By contrast, permissive licenses typically include clauses limiting liability and disclaiming warranties, thereby offering additional protections. Community trust and familiarity may also play a significant role. Established permissive licenses are widely recognized and trusted, whereas public domain licenses may not enjoy the same level of familiarity or acceptance, leading developers to favor more well-known licensing options. For copyleft licenses, the overall effect is negative. However, JavaScript projects under such licenses exhibit an odds ratio greater than 1, suggesting that the effect of copyleft licenses varies significantly depending on the language. Weak copyleft licenses also show negative impacts on reuse for JavaScript, Java, C/C++, and Rust projects. These findings suggest that hypothesis H1b is also partially supported. Although copyleft licenses generally reduce the probability of reuse, this is not the case for all programming languages. Moreover, weak copyleft licenses reduce reuse only in specific languages.
TABLE III ANOVA TABLE AND R EGRESSION C OEFFICIENTS
EarliestCommit LatestCommit CoreAuthors Forks Commits Files AdoptionDelay Burstiness Language License Language:License
128,029 (22.38%)
Fig. 2. Full Model - Odds Ratios and 95% Confidence Intervals.
Projects using permissive licenses show increased reuse in Python, C/C++, and JavaScript, but this effect is not significant in other languages, suggesting that permissive licenses enhance reuse only in specific environments. Furthermore, public domain licenses do not generally impact reuse odds, but reduce the likelihood of reuse in JavaScript and Ruby, contrary to the expectation that more permissive licenses encourage reuse, and
2) Implications: A key takeaway is that the choice of license for a project has a substantial impact on the likelihood of its artifacts being reused. This effect varies across different license types and programming languages, highlighting nuanced relationships between license choice, programming
8
RQ1 Key Findings 1) Permissive licenses have the strongest positive impact on reuse, particularly in Python, C/C++, and JavaScript projects. (H1a) 2) Public domain licenses show a negative association with reuse, specifically in Ruby and JavaScript projects. (H1a) 3) Copyleft licenses show mixed results: they are beneficial for reuse in specific contexts, such as JavaScript, but generally have a negative effect on reuse when controlling for other factors. (H1b) 4) Weak copyleft licenses reduce reuse only in Rust, C/C++, and Java projects when other factors are considered. (H1b) 5) The influence of license type on reuse is highly dependent on programming language, indicating that license effectiveness varies significantly across different language ecosystems.
Fig. 3. Top 10 License Types - 1 Reused Blob, High Sensitivity
a) At least 1 Reused blob: Figure 4 highlights the top 10 categories of license combinations between upstream and downstream projects, showcasing the most frequent pairings. The pie chart illustrates the distribution of project tuples across three categories: no issues, high-risk potential, and low-risk potential for license noncompliance. The results indicate that a significant majority (55%) of upstream-downstream license combinations fall into the highrisk category. The most common high-risk scenario occurs when neither the upstream nor downstream projects have a license, accounting for 605 million project tuples. This creates legal uncertainty regarding reuse, modification, and distribution rights. Other high-risk combinations within the top 10 involve cases where one project lacks a license, such as nolicense to permissive. Even when the upstream project has a clear license, the absence of a downstream license introduces ambiguity and potential legal challenges. On the positive side, 30% of the tuples present no issues, such as permissive to permissive combinations, where both upstream and downstream projects are clearly licensed, minimizing legal risk. Low-risk combinations make up 14%, including cases like permissive to no-license, which involves some legal uncertainty but is less risky than high-risk scenarios. As Figure 4 shows, the proportion of high-risk tuples decreases from 63% to 55%, with many of these tuples shifting to the no-issues category, which increases from 23% to 31%. This shift is primarily observed in the permissive to weak-copyleft and public-domain combinations, indicating that permissive licenses are prevalent in projects with multiple licenses. Despite these shifts, the no-license to no-license combination remains the largest high-risk group, unchanged, highlighting the ongoing legal uncertainty in projects without clear licensing. b) At least 10 Reused blobs: The total number of reuse instances (unique combinations of upstream and downstream projects) drops significantly from 1.816 billion to 212 million after applying the constraint of at least 10 reused blobs—a reduction of approximately 88%. This sharp decline indicates that the majority of earlier reuse cases involved fewer than 10 blobs, suggesting that much of the initial reuse was minimal or partial. This reduction highlights that a significant portion of copy-based reuse in the open source ecosystem is
language, and reuse behavior. This indicates that developers and contributors should be mindful of how their choice of license can influence the adoption and reach of their work. One of the most unexpected findings is that public domain licenses, designed to allow free and unrestricted reuse, have a negative effect on reuse. This is concerning because the intent behind these licenses is to eliminate barriers, yet the data suggest the opposite. The negative association of public domain licenses with reuse indicates that the OSS community may need to address this unintended outcome. One way forward is to enhance awareness and education about public domain licensing, clarifying the legal protections and reuse rights it offers. Clearer guidance on how public domain licenses differ from other open source licenses, particularly regarding legal clarity and potential liability, could benefit OSS contributors, especially newcomers. The community might also consider providing stronger legal frameworks or support around public domain licenses to reduce uncertainties and hesitations. Project maintainers may also reconsider using public domain licenses if their primary goal is to maximize reuse. The data suggest that permissive licenses may be more effective in promoting reuse. In conclusion, while the OSS movement encourages reuse and collaboration, these results show that the choice of license plays a crucial role in determining whether a project achieves those goals. The community must be attentive to the barriers that certain licenses, such as public domain, may unintentionally create and take steps to provide better education, support, and legal frameworks to ensure that the intentions behind these licenses are effectively realized in practice. B. RQ2 - Noncompliance 1) Our Findings: As discussed above, we report only the results of our low-sensitivity aggregation here (i.e., considering the lowest-risk pairs of licenses for a given upstream– downstream pair of projects). Figures 4 and 6 summarize our findings for the two flavors of reuse we consider (complete reuse, with at least one shared blob, and substantial reuse, with 10 or more blobs).
9
Fig. 6. Top 10 License Types - 10 Reused Blobs, Low Sensitivity
Fig. 4. Top 10 License Types - 1 Reused Blob, Low Sensitivity
TABLE IV R EUSE D ETECTABLE BY D EPENDENCY R ELATIONSHIP License Type
Fig. 5. Top 10 License Types - 10 Reused Blobs, High Sensitivity
small-scale or potentially superficial, involving limited sharing between projects, with fewer instances of deeper, substantial dependencies. By focusing on reuse instances involving at least 10 reused blobs, the data now captures more meaningful relationships, wherein downstream projects are more closely integrated with upstream codebases. Although the number of high-risk combinations decreases proportionally from the earlier results, they still account for 39% of the remaining reuse instances (see Figure 6). This indicates that even in cases of more substantial reuse, issues related to licensing or lack of clear licensing persist. However, the increase in the no-issues category to 48%, primarily driven by permissive to permissive license reuse, suggests that when significant reuse occurs, clearer licensing tends to be in place, especially for permissive licenses. Under the low-sensitivity approach for reuse involving over 10 blobs, there is a noticeable shift in the distribution of risk categories (see Figure 6). High-risk combinations decrease from 51% in the high-sensitivity scenario to 39%, indicating a more favorable risk landscape when the least-risky license is selected in multi-licensed projects. The no-issues category grows to 48%; however, the nolicense to no-license combination remains a significant highrisk category, unchanged at 35 million tuples. This persistent issue demonstrates that, even with more lenient interpretations, projects lacking clear licenses continue to pose substantial legal risks. Overall, while the results under the low-sensitivity approach reveal a more favorable risk profile, with fewer high-risk
Sample Size
Decl. Dep.
Percent
no-license-2-no-license no-license-2-permissive no-license-2-weak-copyleft no-license-2-public-domain copyleft-2-no-license conditional-open-2-conditional-open conditional-open-2-copyleft conditional-open-2-no-license conditional-open-2-weak-copyleft copyleft-2-conditional-open copyleft-2-permissive copyleft-2-public-domain copyleft-2-weak-copyleft no-license-2-conditional-open no-license-2-copyleft weak-copyleft-2-no-license
21,102 13,670 6,357 4,107 1,105 1,000 1,000 1,000 1,000 1,000 1,000 1,000 1,000 1,000 1,000 1,000
499 346 94 93 48 20 20 40 18 19 36 36 14 34 43 36
2.36% 2.53% 1.48% 2.26% 3.35% 2.00% 2.00% 4.00% 1.80% 1.90% 3.60% 3.60% 1.40% 3.40% 4.30% 3.60%
Total
57,341
1,396
2.43%
combinations and an increased share of safe reuse, we still observe 82 million reuse instances (39% of total reuse) with high potential risk of license noncompliance, supporting our Hypothesis H2a and underscoring the critical importance of proper licensing. Overall, these findings support our hypothesis H2a and underscore the critical importance of proper licensing. c) Copy-based vs. Dependency-based Reuse: Existing research highlights the need for more granular methods to detect code reuse beyond declared dependencies, as traditional tools often overlook directly copied code between projects. This section aims to expose the limitations of relying solely on package managers for license compliance monitoring. While package managers effectively track formal dependencies (such as imports and exports) between projects, they often fail to detect instances of direct code copying without an explicitly declared dependency. The results of comparing reuse detected via copy-based network and dependency-based network are presented in Table IV. The results highlight a significant limitation in current dependency detection tools, showing that the percentage of code reuse detected through declared dependencies is remarkably low across all categories. Despite analyzing over 57,000 project combinations, the overall detection rate of code reuse
10
the applicability of the main project license. Thus, while the project may be licensed under a specific open-source framework, that license may only cover certain parts, with other components subject to different licensing terms. 3) Dependency-Based Reuse: One limitation in comparing copy-based reuse with dependency-based reuse is that some projects use dynamic or implicit imports, where dependencies are loaded at runtime or through unconventional methods that may not be captured by a straightforward export-import analysis. This can result in certain dependencies, which package managers can detect, being overlooked, exposing gaps in our approach. Nonetheless, our methodology is conservative, as we track dependencies over time rather than focusing solely on the latest version. By excluding any reuse instance that was detectable through dependencies at any point in the project’s history, we provide a more thorough view of potential dependency-based reuse. This approach reduces the risk of missing past dependencies that may have been removed or modified in subsequent versions, delivering a more inclusive analysis of reuse instances. However, this conservatism may also lead to attributing reuse to dependencies that no longer exist, slightly skewing the results toward historical dependency detection.
RQ2 Key Findings 1) A significant portion of upstream-downstream project combinations are classified as high-risk for potential license noncompliance, leading to considerable legal uncertainties regarding reuse, modification, and distribution rights. (H2a) 2) The most common high-risk potential noncompliance scenario involves projects lacking any license, underscoring a legal vulnerability within the open-source community and highlighting the urgent need for consistent and clear licensing practices. 3) Dependency tracking is inadequate for detecting most instances of code reuse, highlighting the need for more granular detection methods capable of identifying copy-based reuse that would enable more accurate license compliance monitoring in open-source projects. (H2b)
through formal dependency relationships was only 2.43%. This suggests that traditional methods relying on package managers, which track declared imports and exports between projects, are insufficient for capturing most instances of code reuse, supporting our hypothesis H2b. 2) Implications: These findings have significant implications for the open-source community, particularly in relation to license compliance and code reuse detection. The results reveal that a majority of upstream-downstream project combinations are classified as high-risk for potential noncompliance, underscoring a persistent issue in open-source software development. The high occurrence of high-risk cases, especially in projects with no license, highlights a potential legal vulnerability that could impact the sustainability and collaboration within the open-source ecosystem. This findings also call for more advanced detection techniques that go beyond traditional dependency analysis. Tools that can detect code reuse through copying are essential for identifying non-compliance with licensing terms. The low detection rates across the board demonstrate that current tools are not capable of providing a complete picture of how code is reused, and more comprehensive approaches are necessary to ensure effective license compliance monitoring.
B. External Validity 1) Copy-Based Reuse: While emphasizing copy-based reuse offers valuable insights into license compliance, we recognize the significant role of dependency-based reuse within the broader reuse network. Focusing solely on copy-based reuse may overlook certain aspects of how dependencies are integrated into a project. Conversely, dependency-based reuse can miss critical instances where code is directly copied between projects, which is equally crucial in identifying potential noncompliance. Thus, while this work prioritizes copybased reuse, it serves to complement—rather than replace—the understanding gained from analyzing dependency-based reuse, together providing a more comprehensive view of compliance. VI. C ONCLUSIONS Our study shows that the choice of open-source license plays a significant role in influencing the likelihood of reuse. Permissive licenses consistently encourage reuse across a variety of programming languages, while copyleft and weak copyleft licenses exhibit more context-specific effects, sometimes limiting reuse depending on the language and environment. Despite offering unrestricted reuse, public domain licenses were linked to a negative impact on reuse, likely due to legal uncertainties. Our findings also emphasize the importance of detecting copy-based reuse, as traditional dependency-based approaches often fail to capture the full scope of reuse, especially when explicit dependencies are not declared. This highlights the need for more advanced detection methods to improve license compliance monitoring in the open-source ecosystem. Moreover, projects without clear licenses continue to present significant legal risks, underscoring the need for
V. L IMITATIONS A. Internal Validity 1) Project to License Map: The project to license map (P2L) in WoC relies on detecting license files in repositories, assuming licenses are always recorded in dedicated files. Nevertheless, licenses might appear in README or source files, leading to underreporting or misclassification. This suggests that results should be interpreted cautiously, and additional manual verification may be needed for a more accurate understanding of license noncompliance. 2) License Scope: Assigning a license to an entire OSS project can introduce challenges, as the license may not uniformly apply to all components. Projects often incorporate third-party libraries, modules, or contributions that come with their own distinct licenses, which may conflict with or restrict
11
more consistent and transparent licensing practices within the open-source community.
12
R EFERENCES [1]
[2]
[3] [4]
[5]
[6] [7]
[8]
[9] [10]
[11]
[12]
[13]
[14] [15] [16]
[17] [18] [19]
[20] [21]
D. A. Almeida, G. C. Murphy, G. Wilson, and M. Hoye, “Do software developers understand open source licenses?” In 2017 IEEE/ACM 25th International Conference on Program Comprehension (ICPC), IEEE, 2017, pp. 1–11. Z. Yu, Y. Wu, N. Zhang, C. Wang, Y. Vorobeychik, and C. Xiao, “Codeipprompt: Intellectual property infringement assessment of code language models,” in International conference on machine learning, PMLR, 2023, pp. 40 373–40 389. W. Xu, K. Gao, H. He, and M. Zhou, “A first look at license compliance capability of llms in code generation,” arXiv preprint arXiv:2408.02487, 2024. M. Jahanshahi and A. Mockus, “Cracks in the stack: Hidden vulnerabilities and licensing risks in llm pre-training datasets,” in 2025 IEEE/ACM International Workshop on Large Language Models for Code (LLM4Code), IEEE, 2025, pp. 104–111. C. Vendome, D. M. German, M. Di Penta, G. Bavota, M. LinaresVásquez, and D. Poshyvanyk, “To distribute or not to distribute? why licensing bugs matter,” in Proceedings of the 40th International Conference on Software Engineering, 2018, pp. 268–279. T. Tuunanen, “Tool support for open source software license compliance: The first two decades of the millennium,” JYU dissertations, 2021. M. Jahanshahi, D. Reid, and A. Mockus, “Beyond dependencies: The role of copy-based reuse in open source software development,” ACM Transactions on Software Engineering and Methodology, vol. 34, no. 8, pp. 1–49, 2025. O. Fendt and M. C. Jaeger, “Open source for open source license compliance,” in Open Source Systems: 15th IFIP WG 2.13 International Conference, OSS 2019, Montreal, QC, Canada, May 26–27, 2019, Proceedings 15, Springer, 2019, pp. 133–138. S. Phipps and S. Zacchiroli, “Continuous open source license compliance,” arXiv preprint arXiv:2011.08489, 2020. D. M. German, M. Di Penta, and J. Davies, “Understanding and auditing the licensing of open source software distributions,” in 2010 IEEE 18th International Conference on Program Comprehension, IEEE, 2010, pp. 84–93. Y. Shagall and E. Breithaupt, “Jacobsen v. katzer: Federal circuit affirms economic interest of open source copyright holder,” Harvard Journal of Law & Technology, 2008, Accessed: 2024-09-27. [Online]. Available: https://jolt.law.harvard.edu/digest/jacobsen-v-katzer Software Freedom Law Center, On behalf of busybox developers, sflc files first ever u.s. gpl violation lawsuit, Accessed: 2024-09-27, 2007. [Online]. Available: https://softwarefreedom.org/news/2007/sep/20/ busybox/ A. Mockus, “Insights from open source software supply chains (keynote),” in Proceedings of the 2019 27th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering, 2019, pp. 3–3. A. Mockus, “Tutorial: Open source software supply chains,” in India Software Engineering Conference, 2022. [Online]. Available: papers/ SSCISEC22.pdf A. Mockus, Securing large language model software supply chains, ASE’23 LLMs in Software Engineering, Luxenburgh, Sep. 2023. [Online]. Available: papers/wocllm.pdf D. Yan, Y. Niu, K. Liu, Z. Liu, Z. Liu, and T. F. Bissyandé, “Estimating the attack surface from residual vulnerabilities in open source software supply chain,” in 2021 IEEE 21st International Conference on Software Quality, Reliability and Security (QRS), IEEE, 2021, pp. 493–502. P. Ladisa, H. Plate, M. Martinez, and O. Barais, “Sok: Taxonomy of attacks on open-source software supply chains,” in 2023 IEEE Symposium on Security and Privacy (SP), IEEE, 2023, pp. 1509–1526. S. Koch and G. Schneider, “Effort, co-operation and co-ordination in an open source software project: Gnome,” Information Systems Journal, vol. 12, no. 1, pp. 27–42, 2002. A. Mockus, “Large-scale code reuse in open source software,” in First International Workshop on Emerging Trends in FLOSS Research and Development (FLOSS’07: ICSE Workshops 2007), IEEE, 2007, pp. 7– 7. K. Crowston and J. Howison, The social structure of free and open source software development, 2005. J. Tsay, L. Dabbish, and J. Herbsleb, “Influence of social and technical factors for evaluating contribution in github,” in Proceedings of the
[22]
[23]
[24]
[25]
[26] [27] [28] [29] [30] [31] [32]
[33]
[34]
[35]
[36]
[37] [38] [39]
[40] [41]
[42]
13
36th international conference on Software engineering, 2014, pp. 356– 366. H. Borges, A. Hora, and M. T. Valente, “Predicting the popularity of github repositories,” in Proceedings of the The 12th international conference on predictive models and data analytics in software engineering, 2016, pp. 1–10. J. Gamalielsson and B. Lundell, “Sustainability of open source software communities beyond a fork: How and why has the libreoffice project evolved?” Journal of systems and Software, vol. 89, pp. 128– 145, 2014. T. F. Bissyandé, F. Thung, D. Lo, L. Jiang, and L. Réveillere, “Popularity, interoperability, and impact of programming languages in 100,000 open source projects,” in 2013 IEEE 37th annual computer software and applications conference, IEEE, 2013, pp. 303–312. Y. Kashima, Y. Hayase, N. Yoshida, Y. Manabe, and K. Inoue, “An investigation into the impact of software licenses on copy-and-paste reuse among oss projects,” in 2011 18th Working Conference on Reverse Engineering, IEEE, 2011, pp. 28–32. J. V. Brewer, “The effects of open source license choice on software reuse,” Ph.D. dissertation, Virginia Tech, 2012. A. M. S. Laurent, Understanding open source and free software licensing: guide to navigating licensing issues in existing & new software. ” O’Reilly Media, Inc.”, 2004. R. Stallman, Free software, free society: Selected essays of Richard M. Stallman. Lulu. com, 2002. L. Lessig, “How big media uses technology and the law to lock down culture and control creativity,” Retrieved December, vol. 5, p. 2004, 2004. L. Rosen, “Open source licensing,” Software Freedom and Intellectual Property Law, 2005. M. Välimäki, The rise of open source licensing: a challenge to the use of intellectual property in the software industry. Turre publishing, 2005. M. Di Penta, D. M. German, Y.-G. Guéhéneuc, and G. Antoniol, “An exploratory study of the evolution of software licensing,” in Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering-Volume 1, 2010, pp. 145–154. J. Wu, L. Bao, X. Yang, X. Xia, and X. Hu, “A large-scale empirical study of open source license usage: Practices and challenges,” in 2024 IEEE/ACM 21st International Conference on Mining Software Repositories (MSR), IEEE, 2024, pp. 595–606. X. Cui, J. Wu, Y. Wu, X. Wang, T. Luo, S. Qu, X. Ling, and M. Yang, “An empirical study of license conflict in free and open source software,” in 2023 IEEE/ACM 45th International Conference on Software Engineering: Software Engineering in Practice (ICSESEIP), IEEE, 2023, pp. 495–505. A. Mathur, H. Choudhary, P. Vashist, W. Thies, and S. Thilagam, “An empirical study of license violations in open source projects,” in 2012 35th annual IEEE software engineering workshop, IEEE, 2012, pp. 168–176. D. A. Almeida, G. C. Murphy, G. Wilson, and M. Hoye, “Investigating whether and how software developers understand open source software licensing,” Empirical Software Engineering, vol. 24, pp. 211–239, 2019. J. P. Moraes, I. Polato, I. Wiese, F. Saraiva, and G. Pinto, “From one to hundreds: Multi-licensing in the javascript ecosystem,” Empirical Software Engineering, vol. 26, no. 3, p. 39, 2021. S. Qiu, D. M. German, and K. Inoue, “Empirical study on dependencyrelated license violation in the javascript package ecosystem,” Journal of Information Processing, vol. 29, pp. 296–304, 2021. M. Feng et al., “Open-source license violations of binary software at large scale,” in 2019 IEEE 26th International Conference on Software Analysis, Evolution and Reengineering (SANER), IEEE, 2019, pp. 564– 568. M. Papoutsoglou, G. M. Kapitsaki, D. German, and L. Angelis, “An analysis of open source software licensing questions in stack exchange sites,” Journal of Systems and Software, vol. 183, p. 111 113, 2022. D. Reid and A. Mockus, “Applying the universal version history concept to help de-risk copy-based code reuse,” in 2023 IEEE 23rd International Working Conference on Source Code Analysis and Manipulation (SCAM), IEEE, 2023, pp. 1–12. T. Wolter, A. Barcomb, D. Riehle, and N. Harutyunyan, “Open source license inconsistencies on github,” ACM Transactions on Software Engineering and Methodology, vol. 32, no. 5, pp. 1–23, 2023.
[43]
[44]
[45]
[46]
[47]
[48]
Y. Wu, Y. Manabe, T. Kanda, D. M. German, and K. Inoue, “A method to detect license inconsistencies in large-scale open source projects,” in 2015 IEEE/ACM 12th Working Conference on Mining Software Repositories, IEEE, 2015, pp. 324–333. S. Xu, Y. Gao, L. Fan, Z. Liu, Y. Liu, and H. Ji, “Lidetector: License incompatibility detection for open source software,” ACM Transactions on Software Engineering and Methodology, vol. 32, no. 1, pp. 1–28, 2023. M. Jahanshahi, D. Reid, A. McDaniel, and A. Mockus, “Oss license identification at scale: A comprehensive dataset using world of code,” in 2025 IEEE/ACM 22nd International Conference on Mining Software Repositories (MSR), IEEE, 2025, pp. 144–148. Y. Ma, C. Bogart, S. Amreen, R. Zaretzki, and A. Mockus, “World of code: An infrastructure for mining the universe of open source vcs data,” in 2019 IEEE/ACM 16th International Conference on Mining Software Repositories (MSR), IEEE, 2019, pp. 143–154. Y. Ma, T. Dey, C. Bogart, S. Amreen, M. Valiev, A. Tutko, D. Kennard, R. Zaretzki, and A. Mockus, “World of code: Enabling a research workflow for mining and analyzing the universe of open source vcs data,” Empirical Software Engineering, vol. 26, pp. 1–42, 2021. T. Fry, T. Dey, A. Karnauch, and A. Mockus, “A dataset and an approach for identity resolution of 38 million author ids extracted from
[49]
[50] [51] [52] [53] [54] [55] [56]
14
2b git commits,” in Proceedings of the 17th international conference on mining software repositories, 2020, pp. 518–522. A. Mockus, D. Spinellis, Z. Kotti, and G. J. Dusing, “A complete set of related git repositories identified via community detection approaches based on shared commits,” in Proceedings of the 17th International Conference on Mining Software Repositories, 2020, pp. 513–517. M. Jahanshahi and A. Mockus, “Dataset: Copy-based reuse in open source software,” in Proceedings of the 21st International Conference on Mining Software Repositories, 2024, pp. 42–47. B. Fitzgerald, “The transformation of open source software,” MIS quarterly, pp. 587–598, 2006. E. Moglen, “Free software matters: Enforcing the gpl, ii,” Column in LinuxUser Magazine (August 2001), 2001. A. Agresti, Categorical data analysis. John Wiley & Sons, 2012, vol. 792. S. K. Thompson, Sampling. John Wiley & Sons, 2012, vol. 755. C. F. Dormann et al., “Collinearity: A review of methods to deal with it and a simulation study evaluating their performance,” Ecography, vol. 36, no. 1, pp. 27–46, 2013. K. P. Vatcheva, M. Lee, J. B. McCormick, and M. H. Rahbar, “Multicollinearity in regression analyses conducted in epidemiologic studies,” Epidemiology (Sunnyvale, Calif.), vol. 6, no. 2, 2016.
A PPENDIX
GPL-2.0, GPL-3.0+, GPL-CC-1.0, OSL-3.0 Weak Copyleft: Artistic-1.0-Perl, Artistic-2.0, CDDL-1.0, deprecated LGPL-2.1, eprecated LGPL-3.0, EPL-1.0, EPL2.0, LGPL-2.0+, LGPL-3.0, MPL-1.1, MPL-2.0-no-copyleftexception Conditional Open: CC-BY-3.0, CC-BY-4.0, CC-BY-SA3.0, CC-BY-SA-4.0, ODC-By-1.0, OFL-1.0, OFL-1.1 Public Domain: CC0-1.0, libtiff, Unlicense
List of SPDX license identifiers aggregated by their respective license types: Permissive: 0BSD, AFL-3.0, Apache-2.0, BSD-2, BSD-2Clause, BSD-3-Clause, BSL-1.0, ISC, Libpng, MIT, MIT-0, MITNFA, MIT-Wu, MS-PL, OpenSSL, PHP-3.01, Pixar, PSF2.0, Ruby, SGI-B-2.0, TCL, WTFPL, Zlib Copyleft: deprecated AGPL-3.0, deprecated GPL-3.0+,
15