arXiv:2606.31032v1 [cs.SE] 30 Jun 2026
Partially ordering software licenses Hamidah Oderinwale*
David Atkinson
McGill University
Georgetown University
Rachel Hong
Art Abal
Ben Laufer
University of Washington
Open Data Labs
Cornell Tech
July 1, 2026 Abstract Licenses are legal instruments that inventors may use to protect the technologies they build and regulate how they are used—however, the nature of their authorship and selection means that how they are interpreted, chosen, and enforced is largely unstructured. In practice, this makes it difficult to compare licenses at scale—when is one license considered more permissive than the other, and when are their terms incomparable to each other? Currently, there is a growing list of licenses that are introduced and used, but there is no systematic way to study their relationships. This matters for platforms such as Hugging Face, GitHub, and the Python Package Index, where developers publish or build upon technologies that each have their own licenses. Using large language models (LLMs), we introduce methods for comparing licenses at scale: first, in a pairwise fashion to construct a partial ordering based on permissiveness, and second, by drawing on existing taxonomies of software licenses. The former allows us to trace restrictiveness, and the latter allows us to understand license selection as a combination of shared provisions. Our analysis recovers certain interpretable attributes that correspond to stricter licenses, with legal implications for the open-source ecosystem.
1
Introduction
Innovation hinges on developers’ ability to protect the technologies they build. Yet today’s legal instruments have not been reconsidered in light of an increasingly AI-driven software ecosystem. In this work, we look specifically at today’s software licenses which, due to their decentralized and unregulated nature, are chosen ad-hoc and have proven difficult to enforce. The lack of authorship norms for new licenses or frameworks for reasoning about existing ones means that developers are at higher risk of implicating themselves and others without the ability to reason about the potential stakes. 1
By nature, generative AI has made it easier than ever to produce new technical artifacts and build on top of existing ones; as such, the AI supply chain is notably complex (Hopkins et al., 2025) with diverse technologies. Software repositories can import other packages, model derivatives are fine-tuned from foundation models (Laufer et al., 2025), and datasets are composed of other datasets. When the developer of a technology chooses a license, they adopt its terms. When a user uses the software for which the license is chosen, they enter into an agreement to abide by those terms (Saint-Laurent, 2004). If the terms require attribution to the source, the user must provide it; otherwise, they violate the license terms and may be in breach of contract. Likewise, if the terms state that any derivative of the software must be made available under the same license as the source, ignoring that requirement may constitute a breach of contract. Because of the uncoordinated nature of the machine learning ecosystem and the range of artifacts being produced (e.g. models, datasets, source code, benchmarks, etc.), developers are left to interpret and contextualize license terms that were not written with their artifact in mind. They may inadvertently fail to address the implications of their license choices on other developers, thus exposing themselves and others to legal risk (Duan et al., 2025).
1.1
Toward (computable) software license governance
The challenge with governing license selection beyond institutional factors—such as the lack of a centralized authority or established protocols to adjudicate violations and mediate license publishing—is that licenses are much more expressive than typical legal artifacts. While you can consider a software license a contract because it specifies terms under which users may use a given software, there are no established restrictions on what terms can be written or how. As a corollary, the mechanisms by which these terms are enforced are similarly ill-defined. New licenses are written for several reasons, but enforcement mechanisms are rarely described within them and typically have to be inferred. For example, while there are terms of use which govern what an end user of a technology may do with it, it is less clear what terms apply to a derivative developer building on that technology who wants to apply their own protections. Furthermore, for all the terms in a license, it is not immediately clear which party they apply to. Take, for instance, OpenClaw, an open-source agent project with a user-controlled, sovereign technology narrative and released with an MIT license that meant companies like OpenAI could adapt the project and release it under more closed terms that were seemingly misaligned (Gupta, 2026). Given the arbitrariness of the landscape, downstream artifacts also do not always comply with the licenses of the artifacts they are built on, leading to potential legal consequences. In 2022, the class-action lawsuit DOE 1 v. GitHub alleged that the creation of the Codex and Copilot AI systems constituted a breach of contract of open-source software licenses (Machines, 2025). This legal challenge implies that downstream artifact licenses may need to be compatible with upstream license restrictions, yet the current free-for-all of license attachments challenges our ability to make such comparisons. Despite challenges in enforcing these protections, software licenses are considered contracts and should thus be treated as such (Reddy, 2009). This motivates our work to address the following questions about the ML artifact ecosystem more broadly: how can we characterize and compare license 2
restrictions despite their lack of structure, and how do licenses interact across an artifact and its derivatives? By doing so, we aim to analyze the ad-hoc practices of ML artifact licensing and inform effective policies for governing creative expression in this space.
1.2
Contributions
This work presents methodology for reasoning about licenses and unstructured legal texts more broadly, and demonstrates its use in practice. To do so, we: • Present a dataset of 747 licenses (and a subset of 93 exclusive to Hugging Face) with text and metadata (author, version, etc.) and use existing software license taxonomies to characterize them. • Present novel methods to use LLMs to compare and characterize legal texts in a pairwise fashion. We validate these methods by examining inter-model agreement, license incomparability, and model rationale. • Employ pairwise comparisons to produce a partial ordering that forms the basis of computationally evaluating licenses—ranking them, filtering through them, and tracing their permissiveness through downstream derivatives. • Survey the open-source software ecosystem using our partial orderings, studying 7.2B dependency relationships across five major software library ecosystems covering a total of 11.9M packages from 2010–2025 (npm, PyPI, Cargo, Maven, and conda-forge), and find that inconsistent license choice—where a downstream artifact uses a more permissive license than an upstream dependency—happens at rates ranging from 12.3%– 57.4%.
2
Related Work
Licenses are the primary instrument through which innovators govern access to the technologies they develop, though software and new kinds of digital artifact exist in a gray zone of governance (Reuel et al., 2025). This raises the question of whether license choice within a technological ecosystem can be optimally designed, and how the externalities of the choices made by its actors can be measured (Jewitt et al., 2026; Heller and Eisenberg, 1998). (White et al., 2024) put forth a framework for assessing openness and the relationships of artifacts in the model ecosystem. Others have tried to map the interactions of technology developers, in particular the AI supply chain—where interactions are particularly sprawling due to the diversity of interacting components (Hopkins et al., 2025)—and have empirically documented the license landscape across the ecosystem of ML models (Longpre et al., 2023; Laufer et al., 2025). Additional previous work has framed open-source licenses as infrastructure for governing the technological commons (Choksi and Grimmelmann, 2024; Ostrom, 2010), where each license reflects the values of its inventors and their design constitutes collective deliberation over the needs of downstream developers. One reason why the optimal licensing regime is hard to conceive is that technologies are built in tandem and on top of each other within 3
a broader supply chain; understanding what rules apply to whom, especially when they are often vaguely specified, is a difficult task.
3
A dataset of software licenses
Together, we collected a total of 747 licenses with 383 being license version variants.1 For every license, we retrieve its text, its source, and any additional metadata offered by the provider. The majority of the licenses had their data retrieved from the Software Package Data Exchange (SPDX) (SPDX Project, 2024), which offers a canonical list of licenses used for published software. A number of licenses have multiple versions and we consider every version a unique license. For the licenses that are not on SPDX, such as newer licenses authored by major model developers like Google, Meta, and Mistral—we sourced their licenses from their own hosted sources (notably on GitHub). A number of licenses do not have publicly available text or were excluded from the analyses below because their texts were trivial, they were duplicates, or wrongly listed as a license. From these licenses, we count 360 unique authors, of which 82 (22.78%) are authors of two or more licenses—contributing to 57.7% of the total collection.
3.1
Who writes licenses?
A sizeable fraction of licenses are written by non-profits and foundations such as the Creative Commons and the Free Software Foundation (FSF); both have relatively large (552 and 62, respectively) and popular suites of licenses that contribute to their share. The second largest demographic of license authors are individuals, examples including Donald Arsenau, the author of a number of LaTeX packages and three related licenses (e.g. the Dotseqn introduced in 1995); Henry Spencer, developer of regex libraries and the author of one corresponding license (the Spencer license), and Larry Wall, the developer of the Perl programming language and the author of the Artistic License family (Brand, 1994; Houston, 1999; Open Source Initiative). The author dynamics of individuals reinforce Choksi and Grimmelmann’s thesis, built on ideas from Brand, which presents licenses and infrastructure more broadly are built in live ecosystems and out of adapting needs (Choksi and Grimmelmann, 2024; Brand, 1994). To classify organization types we use Wikidata and use their database of assignable properties to color code 4. For the breakdown of author demographics we use the Research Organization Registry (ROR) which consists of ten categories and a category for individuals. Out of the ten, eight are represented, as archive and funder organizations were not classified as authors in the dataset, but we identify them as relatively ambiguous types.3 1
A license version variant is a license with a version number in its SPDX ID. We combine counts from Creative Commons (49) and the Creative Commons Corporation (6). 3 *From Sonnet 4.6 (v4 prompt). 2
4
4
Arriving at a partial ordering
We introduce methods for assessing the relative permissiveness of licenses by using LLMs to produce a partial ordering over the licenses in our set (Gu et al., 2025). Recognizing that LLM outputs are non-deterministic and legal analysis is a domain without clear ground truth, we rely on a consensus between models to address divergent model judgments and further validate a random subset by hand. For every pair from a total of 278,631 ( 747 ), 2 we instruct models to select the more permissive license out of the two, or identify them as equal or incomparable. Formal definitions To denote the relationships more formally, let L = {ℓ1 , ℓ2 , . . . , ℓn } denote the set of licenses in the ML ecosystem; our goal is to characterize the relationships between these licenses. We define two relations: the first, represents a relationship where one license ℓi is therefore more permissive (less strict) than another license ℓj : ℓi < ℓj
(1)
where ℓi → ℓj in a graph. Strictness is defined by a logical entailment relationship: If ℓi < ℓj then any work that complies with ℓj must also comply with ℓi , and there exists works that comply with ℓi but not ℓj . The second represents a relationship where both licenses are equally as restrictive: ℓi ∼ ℓj (2) The third, is the lack of relation where both a pair is deemed incomparable due to a lack of consensus or certainty. ℓi ∥ ℓj
(3)
This is the most ambiguous relation, and we ask that models select it in addition to one of the above so we can analyze its determinants and the nature of conflicting verdicts across raters.
5
Comparatively characterizing licenses
5.1
How license text changes with permissiveness
Given the partial orderings we produce, we explore the relationship between textual features and permissiveness. Past work has investigated the complexity of legal literature over time (Jeong et al., 2026) and has found that legal texts have gotten more complex and long, with vocabularies staying increasingly dominated by a few popular terms. We observe similar findings in our dataset looking at lexical features of licenses as they get more permissive. For every pair of licenses in which one is deemed more permissive than the other, we note whether a feature is true (‘appears’) or false (‘disappears’) as a license becomes permissive (is chosen as the more permissive one in the ordered pair). We look at license word counts as 5
they become more restrictive. For diversity—the linguistic novelty and variation of a license’s text—we employ Shannon entropy (Shannon, 1948), which studies how evenly distributed vocabulary terms are within a corpus. This is used over other measures like type-token ratio because it allows us to understand the distribution of terms in a single license and is less sensitive to license length. We observe that licenses from the same author or ‘family’ are more similar in terms of how they are written and semantically than random pairs.
All directed pairs Within-family directed pairs Cross-family directed pairs Random baseline
n
Cosine Similarity
TF-IDF
∆ words
∆ entropy
|∆| features
259,906 2,319 257,587 527,802
0.422 0.754 0.419 0.423
0.927 0.578 0.930 0.926
+522 +117 +525 +1,304
+0.31 +0.10 +0.31 +1.14
2.05 1.83 2.05 2.05
Table 1: Semantic similarity for license pairs. Similarity is calculated using cosine of sentencetransformer embeddings (all-MiniLM-L6-v2). Directed pairs represents the delta of the feature subtracting the value of the more permissive license from the less permissive license. Cross-family directed pairs represents directed pairs, where within a pair, each license comes from a unique family. The random baseline represents all pairs regardless of the ordering. The within-family directed pairs represents directed pairs from the same license family (e.g. Creative Commons license family). Lastly, we represent the set of binary features as a string where each position’s value represents whether the feature is applicable or not. We count the number of positions that diverge and write them as the ‘feature difference.’ Then, with our features, we introduce a framework for comparing licenses by their functional signatures, that is, a computable representation of their legal implications. Each license can be represented with a binary string, where every position corresponds to a proposition from our predefined vocabulary of features. Each position is evaluated depending on whether the assigned proposition is applicable or not. In the context of a mechanism where developers use these functional signatures to decide what license to pick, a meaningful extension could involve adding weights to different features depending on how important they are to the developer or how strongly they are correlated to permissiveness (as computed in Table 10)—but for simplicity, we consider their weights as equal. And while we present this methodology with a set of ten features from Nordlander’s taxonomy, we imagine that any number of features could be studied in a similar way. Future work could more formally explore the selection of features themselves, where each feature captures a legally distinct dimension.4 While the partial ordering helps us understand the degree of restrictiveness across licenses, this framework allows us to compare licenses at a functional level (Table 3). 4
For this framework, a feature needs to be a proposition: a claim that can be argued for or against. For example, “commercial use” is a topic, but “derivatives of this license are allowed to be distributed for commercial use” is a proposition because it is possible to verify whether the claim is true or false. More formally, we can describe a feature as a predicate that returns true or false (Mayo-Wilson, 2017), where a lack of a positive determination, or an explicit description, is considered false.
6
5.2
License traits
Notably, a shortcoming of the aforementioned is that it does not consider the nature of the license provisions themselves. For example, two licenses could have an equal number of claims but correspond to distinct areas of law. That is, a license could be more structurally restrictive but contextually incomparable. To address this, we extract binary features derived from existing taxonomies that characterize software licenses by their terms (Nordlander et al., 2004; Kapitsaki and Charalambous, 2021).
(a) Nordlander features
(b) Kapitsaki features
Nord.
Feature Requires attribution Requires ShareAlike Prohibits derivatives Allows commercial use Prohibits commercial use Requires source disclosure Allows binaries* Copyleft
Description Derivative works must credit the original author Derivatives must be released under the same license No modified versions may be distributed Use in commercial products is explicitly permitted Use in commercial products is explicitly forbidden Source code must be made available with distributions Compiled binary distributions are permitted Any derivative work must also be open-licensed
Kap.
Figure 1: How often features appear across licenses.
Patent use State changes Network use is distribution
License contains an explicit grant of patent rights to users Modifications must be documented when distributing Providing network access triggers source disclosure obligations
Table 3: License features from existing taxonomies (Nordlander et al., 2004; Kapitsaki and Charalambous, 2021). * Binaries refer to compiled, machine-executable files (e.g. .so, .bin, .exe, .dll files), distinct from source code in human-readable form.
5.3
How features correlate with permissiveness
We look at how features change with permissiveness. Below, we plot the direction that each feature changes in as licenses become more restrictive. Out of the 110,342 ordered 7
pairs where copyleft has a different value between the more permissive and less permissive license, it appears in the less permissive license 75% of the time, showing a mean drift of +0.507. Given the absolute mean drift we can produce an ordering of features in the direction of restrictiveness. As seen in the plot, requiring attribution offers the weakest signal for restrictiveness while allowing commercial use is the strongest signal of permissiveness.
Figure 2: Barbell plot showing how Nordlander features change in directed pairs, where licenses get less permissive. A feature gained is represented as +1 and a feature removed is represented as -1. We only count flips, where a feature is either gained or lost in a directed pair. The plot shows the features that are associated with restriction in purple (positive values) and the features associated with permissiveness (negative value) in blue. For a given feature, its order is determined by its score that is calculated accordingly: mean direction =
appears − disappears appears + disappears
With the feature profiles that we produce, we also categorize the most common feature changes as licenses get more restrictive. We group directed pairs by the number of features that differ. Then, we see the most common changes for each of them. For example, when there is a single feature change, the most common is GPL compatibility (50%) followed by attribution (25%). Next, with our features, we introduce a framework for comparing licenses by their functional signatures, that is, what they actually enforce. Each license is represented as a binary string, where every position corresponds to a proposition from our predefined vocabulary of features. Each position is evaluated depending on whether the assigned proposition is true or false.5 While the partial ordering helps us understand the degree of restrictiveness across licenses, this framework allows us to compare licenses at a functional level (Table 3). 5
For this framework, a feature needs to be a proposition: a claim that can be argued for or against. For example, “commercial use” is a topic, but “derivatives of this license are allowed to be distributed for commercial use” is a proposition because it is possible to verify whether the claim is true or false. More formally, we can describe a feature as a predicate that returns true or false (Mayo-Wilson, 2017), where a lack of a positive determination, or an explicit description, is considered false. Nordlander’s features follow the original taxonomy, while Kapitsaki’s features were adapted as propositions.
8
While single features can be directionally more permissive or restrictive, licenses are composed of multiple features and we also study them in combination. We can understand the ecosystem of licenses and what restrictions are most common by producing license profiles. With the 10 features in the Nordlander taxonomy, we characterize each license by its value for each feature in a string. Given these licenses, there is an upper bound of 210 combinations (when null is not treated as a unique value, otherwise it is 310 ). Yet, we find only 50 unique feature combinations when the features are considered with binary values (or 75 when they are considered with ternary values), with 87.3% of licenses sharing the same 10 combinations. In Table 4, we look at the most common feature combinations. Licenses Attr SA Mod Der CDer CRed GPL Bin Src CL Example licenses 190 (25.4%) 101 (13.5%) 77 (10.3%) 66 (8.8%) 44 (5.9%) 39 (5.2%) 19 (2.5%) 16 (2.1%) 13 (1.7%) 11 (1.5%)
✓ ✓ ✓ ✓ ✓ × ✓ ✓ ✓ ✓
× × × ✓ ✓ × ✓ ✓ × ×
✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ · ×
✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ×
✓ × · × ✓ ✓ × × × ×
✓ ✓ ✓ ✓ ✓ ✓ · ✓ ✓ ✓
× × × ✓ ✓ × ✓ × × ×
× × × ✓ ✓ × ✓ ✓ × ×
MIT-style, ANTLR-PD, Beerware AAL, 3D-Slicer-1.0 AdaCore-doc, ADSL AGPL family CECILL family 0BSD, Adobe-2006 GFDL family BSD-Protection, CC-BY-SA v2 Artistic-1.0 family CC-BY-NC v1/v2
Table 4: Top 10 most popular feature combinations from the 747 license dataset. In the first column, we include the number of licenses with a given feature combination and its fraction of the total combination pool. Acronyms represent the different features from Nordlander’s (Nordlander et al., 2004) typology: requires attribution (Attr); requires sharealike (SA); user can modify (Mod); user can create derivatives (Der); allows commercial use of derivatives (CDer); allows commercial redistribution (CRed); GPL-compatible (GPL); allows binaries (Bin); requires source disclosure (Src); copyleft (CL). A ✓ means true, and × means false, and · represents null values.
6
Tools for license selection
License selection is one application of the permissiveness framework introduced in this paper. While we attempt to classify permissiveness in this work, interpretations of permissiveness often depend on context, including: 1) developers’ own openness preferences, 2) the artifacts from which their work is derived, 3) the artifacts that may be derived from their technology, and 4) the technologies with which their system interacts. We showcase different methods throughout this work based on these contexts and suggest that the relational, comparative nature of pairwise preferences strikes an appropriate balance between capturing the tacit decision-making heuristics developers employ and providing the explicitness required for a generalizable framework To be able to gauge the permissiveness of a license relative to others in the list, we would generally need to redo all pairwise comparisons. However, given the Bradley–Terry model we 9
can use our pairwise orderings and transform them into a total order, where all the licenses can be assigned a latent score (the degree of permissiveness) driven by how much they are preferred across comparisons. We can then produce a ranked list of licenses based on these scores, where the probability that one license is more permissive than another, P (i ≻ j), is calculated as P (i ≻ j) =
exp(βi ) exp(βi ) + exp(βj )
(4)
We use the Bradley–Terry model on our pairwise data to give us a total order to reference, which forms the basis of a lookup table, where i and j index two distinct licenses. P̂ = P (i ≻ j) 1≤i,j≤n This model helps us order new licenses without having to compare them against every previously compared license (Bradley and Terry, 1952). One application of this total order is a ranked list of licenses that serves as the backbone of a tool to filter licenses based on developer preferences. We define the permissiveness rank as follows. For a given license L, let |L| denote the number of ecosystem licenses it is strictly more permissive than, and severity is δ = rank(Ldownstream ) − rank(Lupstream ) In the context of a developer choosing a license based on the degree of burden on a downstream developer and the number of licenses they can select, you can use this total ordering to produce a decision tree; where each node represents a feature, which in this case corresponds to a restriction. Starting with the root node, which if selected alone filters out the fewest licenses from our list, a developer can traverse the tree and add restrictions. As you go down the tree, the number of licenses available generally decreases as restrictions are applied. From this set of licenses, a developer can then choose any one of them and see its rank based on how many licenses below it are more restrictive. We determine the order of features in the tree based on their permissiveness, as determined by the linear regressions in Table 10.
10
Feature
β
Remaining
Lost
All licenses
—
747
—
Allows commercial use of derivatives? GPL-compatible? Allows commercial redistribution? Allows modification? Allows binary distribution? Allows derivative works?
+0.86 +0.49 +0.49 +0.24 +0.15 +0.07
651 255 255 255 253 253
96 396 0 0 2 0
No source disclosure required? No attribution required? No copyleft?
−0.47 −0.70 −0.83
200 36 36
53 164 0
Table 5: License features as preferences, with the number of licenses meeting each requirement. The correlation between a feature and restrictiveness (β) typically narrows the set of licenses available to a downstream developer. The second column shows the latent permissiveness score associated with each feature, the middle column shows the number of licenses remaining given a chosen term, and the rightmost column shows licenses lost from the total pool. A developer can consider license choice as a set of preferred restrictions, where for every combination of chosen restrictions a a hypothetical license exists. In practice, the lack of such a license would suggest that a license with that combination could be seen as functionally distinct compared to the existing ones in the list. This tool allows a developer to understand how the decisions they care about affect what licenses are available to them and how this affects developers who build on top of their technologies. Many licenses have similar combinations as observed in Table 4, and these licenses can be interpreted as functionally equivalent based off the features we investigate. However, this framework can be applied to a broader set of features and an interesting line of future work involves using real-world license selection rates to produce more discriminative orderings even when licenses are functionally similar. Another use-case of this tool is then allowing one to discover all the cases where this is true.
11
Figure 3: Lattice diagram of sequential feature selection over license space. Three features are shown as an illustrative example: Attribution, Share-Alike, and Non-Commercial with latent scores of β = 0.12, 0.28, and 0.31 respectively. With our total ordering, we use the author demographic classifications from earlier to classify how author type relates to license permissiveness. We observe that the most permissive licenses are authored by education organizations (e.g. the MIT licenses) while non-profits and companies write the least permissive licenses (Table 6)—given that these licenses tend to be bespoke and born out of specific technological development with specific protections in mind, this seems like a reasonable trend. Author type
n
Median permissiveness rank
education individual facility government company nonprofit
43 189 16 42 167 260
151 247 358 430 475 478
Table 6: License types ranked by permissiveness via Bradley-Terry pairwise comparison scores. Author types with less than 10 licenses were omitted from this table (e.g. healthcare).
7
Case studies
Previous work has explored incompatible license choices for models on Hugging Face, where downstream models (i.e. finetunes, quantizations, merges, and adapters) often had licenses less permissive than their parent model or did not follow share-alike or copyleft terms, though no systematic means of formally classifying these behaviors existed (Laufer et al., 2025). We take these observations as motivation and study a snapshot of five popular software library ecosystems, covering 33M+ packages: npm (∼11M), Maven (∼640K), PyPI (∼420K), Cargo (∼133K), and conda-forge (∼31K), from 2010 to 2025.
12
Compliant
Violation
scikit-learn (BSD-3-Clause)
qats (MIT)
scipy (BSD-3-Clause)
pyqt5 (GPL-3.0)
numpy (BSD-3-Clause)
pyqt5-qt5 (LGPL-3.0)
Figure 4: Example software library dependency chains in PyPI. Each node is a package and its declared license. A violation occurs when a downstream package carries a more permissive license than a transitive dependency: qats (MIT) depends on pyqt5 (GPL-3.0), a more restrictive license, whereas the scikit-learn chain is uniformly BSD-3-Clause. Here, we set out to investigate similar patterns in the open-source software ecosystem. To do this, we first need to map relationships between software packages. We use deps.dev— a Google service which has dependency graphs for software packages, we then classify the edges representing dependencies from a snapshot of the dataset (Google). We only look at licenses that exist within a chain and do not look at isolated packages. Cargo (∼83%) has the highest ratio of compliant license relations, followed by PyPI (∼54%), Maven (∼53%), then npm (∼48%) and conda-forge (∼41%).
Figure 5: Severity of license inconsistencies (violations of permissive ordering) by software package depth. Cargo’s high compatibility can be attributed to the tools the community gives its developers, cargo-deny and cargo-about give software maintainers executable governance at build time to check if the dependencies they have chosen for a project abide by the terms of the license they choose. More formal license fields are promoted for use in Cargo.toml files which are structured and machine-readable and can be seen as programmatic documentation that can be more easily verified. The rates of inconsistent license choice have grown steadily over the years in tandem with overall ecosystem growth. Across software packages we see that the most popular license is overwhelmingly the MIT license and more broadly license authors overwhelmingly pick 13
permissive licenses. For npm, the license tree of longest depth is 199, for Maven it is 15, for Cargo it is 14, and for PyPI it is 17. We find that severity of violation of the total ordering varies with the depth of the dependency trees (as detailed in Table 7). We compute the severity of a ‘violation’ as a function of permissiveness rank, where a license’s rank is determined by counting how many licenses are less permissive than it. For each violating pair, we quantify severity as the difference in permissiveness rank between the downstream and upstream licenses.
Figure 6: Top 6 most common license inconsistencies over time across software packages, plotted with the total violation weight for npm, PyPI, and Cargo on a log scale. Over time, there has been a steady increase in license inconsistencies between upstream and downstream packages, with the exception of Cargo, which shows an initial increase followed by a decline.
8
Discussion
When considering the applications of a formal means to compare licenses, we see software platforms such as GitHub and Hugging Face as a key setting to apply this work, given that they host platforms where developers publish their work and select licenses to govern it. Platforms have a unique ability to build interfaces that support the selection of licenses that are compatible, or as restrictive as, a derived or complementary technology, and we have used this paper to describe the methods that are available, building on pairwise judgments. Studying platforms gives a unique aerial view into developer choice, it would be interesting to use human selections as the basis of license recommendation interfaces, that are not only informed by structural permissiveness but other factors as well. To add, while we rely on existing license taxonomies to inform the features we look into, the space of possible features is large. For example, we broadly refer to license terms as features, but legal scholars have explored the different types of legal relations encoded in licenses, and a more granular treatment of these obligations and restrictions remains an avenue for future work Hohfeld (1913). We see the choice of features in this paper more as a case study into what is possible, and expect that the method can apply to a wider range of features, especially in domainspecific settings. 14
9
Conclusion
In this work, we studied the structural order of licenses, which are authored in a distributed and largely ungoverned way. Because of this, they are heterogeneous and typically hard to compare, which has implications for technology developers trying to navigate license selection. To date, license choice and authorship has been ad-hoc, but this work considers how it may be done more systematically by presenting methods for reasoning about licenses in relation to one another. Our work demonstrates the nature of developer needs by breaking down licenses into a set of preferred terms, which we find to be common across licenses, suggesting that while licenses are written independently of one another, there is a concentration of desired conditions and that a number of licenses are relatively redundant. We view this work to be most applicable to platforms that host software technologies where individuals can publish and build upon others’ work, and hope it serves as a foundation for more systematic approaches to license governance.
Acknowledgements We would like to thank James Grimmelmann, Jon Kleinberg, and Anna Kazlauskas for their helpful comments and feedback. We also thank Taste Labs and Open Data Labs for their in-kind support.
References Aspen Hopkins, Sarah H. Cen, Isabella Struckman, Andrew Ilyas, Luis Videgaray, and Aleksander Mądry. Ai supply chains: An emerging ecosystem of ai actors, products, and services, 2025. ISSN 3065-8365. URL http://dx.doi.org/10.1609/aies.v8i2.36628. Benjamin Laufer, Hamidah Oderinwale, and Jon Kleinberg. Anatomy of a machine learning ecosystem: 2 million models on hugging face, 2025. URL https://arxiv.org/abs/2508. 06811. Andrew M. Saint-Laurent. Understanding open source and free software licensing - guide to navigation licensing issues in existing and new software. 2004. URL https://api. semanticscholar.org/CorpusID:106668315. Moming Duan, Mingzhe Du, Rui Zhao, Mengying Wang, Yinghui Wu, Nigel Shadbolt, and Bingsheng He. Position: Current model licensing practices are dragging us into a quagmire of legal noncompliance. In Forty-second International Conference on Machine Learning Position Paper Track, 2025. URL https://openreview.net/forum?id=1rh8iTehBc. Rohit Gupta. Is OpenClaw really free to use, and how can you confirm costs and license terms — c-sharpcorner.com. https://www.c-sharpcorner.com/article/ is-openclaw-really-free-to-use-and-how-can-you-confirm-costs-and-license-terms/, 2026. [Accessed 27-05-2026].
15
Knowing Machines. Doe 1 v. GitHub — knowingmachines.org. https://knowingmachines. org/knowing-legal-machines/legal-explainer/cases/doe-1-v-github, 2025. [Accessed 25-05-2026]. Hersb R. Reddy. Jacobsen v. katzer: The federal circuit weighs in on the enforceability of free and open source software licenses. Berkeley Technology Law Journal, 24(1):299–320, 2009. ISSN 10863818, 23804742. URL http://www.jstor.org/stable/24121345. Anka Reuel, Ben Bucknall, Stephen Casper, Tim Fist, Lisa Soder, Onni Aarne, Lewis Hammond, Lujain Ibrahim, Alan Chan, Peter Wills, Markus Anderljung, Ben Garfinkel, Lennart Heim, Andrew Trask, Gabriel Mukobi, Rylan Schaeffer, Mauricio Baker, Sara Hooker, Irene Solaiman, Alexandra Sasha Luccioni, Nitarshan Rajkumar, Nicolas Moës, Jeffrey Ladish, David Bau, Paul Bricman, Neel Guha, Jessica Newman, Yoshua Bengio, Tobin South, Alex Pentland, Sanmi Koyejo, Mykel J. Kochenderfer, and Robert Trager. Open problems in technical ai governance, 2025. URL https://arxiv.org/abs/2407. 14981. James Jewitt, Gopi Krishnan Rajbahadur, Hao Li, Bram Adams, and Ahmed E. Hassan. Permissive-washing in the open ai supply chain: A large-scale audit of license integrity, 2026. URL https://arxiv.org/abs/2602.08816. Michael A. Heller and Rebecca S. Eisenberg. Can patents deter innovation? the anticommons in biomedical research. Science, 280(5364):698–701, 1998. ISSN 0036-8075. doi: 10.1126/ science.280.5364.698. Matt White, Ibrahim Haddad, Cailean Osborne, Xiao-Yang Yanglet Liu, Ahmed Abdelmonsef, Sachin Varghese, and Arnaud Le Hors. The model openness framework: Promoting completeness and openness for reproducibility, transparency, and usability in artificial intelligence, 2024. URL https://arxiv.org/abs/2403.13784. Shayne Longpre, Robert Mahari, Anthony Chen, Naana Obeng-Marnu, Damien Sileo, William Brannon, Niklas Muennighoff, Nathan Khazam, Jad Kabbara, Kartik Perisetla, Xinyi Wu, Enrico Shippole, Kurt Bollacker, Tongshuang Wu, Luis Villa, Sandy Pentland, and Sara Hooker. The data provenance initiative: A large scale audit of dataset licensing & attribution in ai, 2023. URL https://arxiv.org/abs/2310.16787. Madiha Zahrah Choksi and James Grimmelmann. How licenses learn. Lewis & Clark Law Review, 28(2):249–298, 2024. URL https://ssrn.com/abstract=4728592. Forthcoming; earlier version available at SSRN. Elinor Ostrom. Beyond markets and states: Polycentric governance of complex economic systems. American Economic Review, 100(3):641–672, 2010. doi: 10.1257/aer.100.3.641. SPDX Project. System package data exchange (SPDX) specification version 3.0.1. Technical Report 3.0.1, Linux Foundation, December 2024. URL https://spdx.dev/use/ specifications/. Official SPDX specification, version 3.0.1.
16
Stewart Brand. How Buildings Learn: What Happens After They’re Built. Viking, New York, 1994. Gary Houston. regex – Henry Spencer’s regular expression libraries. GitHub Pages, 1999. URL https://garyhouston.github.io/regex/. Accessed: 2026-04-28. Open Source Initiative. Artistic license 1.0 (perl). Open Source Initiative. URL https: //opensource.org/license/Artistic-1.0-Perl. Accessed: 2026-04-28. Jiawei Gu, Xuhui Jiang, Zhichao Shi, Hexiang Tan, Xuehao Zhai, Chengjin Xu, Wei Li, Yinghan Shen, Shengjie Ma, Honghao Liu, Saizhuo Wang, Kun Zhang, Yuanzhuo Wang, Wen Gao, Lionel Ni, and Jian Guo. A survey on llm-as-a-judge, 2025. URL https: //arxiv.org/abs/2411.15594. Dawoon Jeong, James Holehouse, Jisung Yoon, Christopher P Kempes, Geoffrey B West, and Hyejin Youn. A dataset showing a century of evolution in the complexity of the united states legal code. Sci. Data, 13(1):13, January 2026. Claude Elwood Shannon. A mathematical theory of communication. The Bell System Technical Journal, 27:379–423, 1948. URL http://plan9.bell-labs.com/cm/ms/what/ shannonday/shannon1948.pdf. Conor Mayo-Wilson. A somewhat quick introduction to predicate logic. Course handout, Introduction to Philosophy of Mathematics, University of Washington, 2017. URL https://faculty.washington.edu/conormw/Teaching/Files/PhilMath/ Winter_2017/Readings/Predicate_Logic.pdf. Accessed April 19, 2026. Erik Nordlander, Daniel Loreto, Adam Oliner, and Ram Woo. Software licenses: Taxonomy and analysis. Technical report, Massachusetts Institute of Technology, May 2004. URL https://dspace.mit.edu/bitstream/handle/1721.1/34962/6-901Fall2003/ NR/rdonlyres/Electrical-Engineering-and-Computer-Science/6-901Fall2003/ 5DA43C1A-3307-48BF-B23F-B4CE8261E682/0/Final_Project_Oliner.pdf. Final project, MIT Course 6.901 Inventions and Patents. Georgia M. Kapitsaki and Georgia Charalambous. Modeling and recommending open source licenses with findosslicense. IEEE Transactions on Software Engineering, 47(5):919–935, 2021. doi: 10.1109/TSE.2019.2909021. Ralph Allan Bradley and Milton E. Terry. Rank analysis of incomplete block designs: I. the method of paired comparisons. Biometrika, 39(3/4):324–345, 1952. ISSN 00063444, 14643510. URL http://www.jstor.org/stable/2334029. Google. Open Source Insights — deps.dev. https://deps.dev/. [Accessed 26-05-2026]. Wesley Newcomb Hohfeld. Some fundamental legal conceptions as applied in judicial reasoning. Yale Law Journal, 23(1):16–59, 1913. Kenneth J. Arrow. Social Choice and Individual Values. Yale University Press, 2012. ISBN 9780300179316. URL http://www.jstor.org/stable/j.ctt1nqb90. 17
Alexander Lex, Nils Gehlenborg, Hendrik Strobelt, Romain Vuillemot, and Hanspeter Pfister. Upset: Visualization of intersecting sets. IEEE Transactions on Visualization and Computer Graphics (InfoVis), 20(12):1983–1992, 2014. doi: 10.1109/TVCG.2014.2346248.
18
A
Appendix
A.1
Limitations
A.1.1
License dataset
To the best of our ability, we note and acquire a list of licenses and their text, but recognize that the diffuse nature of license authorship means that there are likely licenses on smaller platforms that may have been missed. A.1.2
Understanding incomparability
Additionally, in the incomparability summaries we ask the model to explain the dimensions of tension in 1-2 sentences, but there could have been benefit to eliciting this rationale in more structured ways (having a token limit, etc.) especially given we attempt to compare different models and their outputs. Moreover, given the generally unpredictable nature of model behavior, we believe that further exploring the nature of model biases in comparative settings is meaningful future work, especially given the contexts we suggest these methods be applied. A.1.3
Ordering bias
Given a pair of licenses to be compared, it is possible that a model would have a tendency to assign a judgment based on the order in which they are presented. We explored this independently on a small sample and find that there is 76% consistency on a set of 50 randomly selected license pairs, where 12 out of 50 verdicts flipped when the order of licenses flipped. We find that the majority of the flips favored the license that appeared first. Of the 12 flips, 11 were marked as incomparable, suggesting that when the model is less confident this bias is a stronger influence, and that when a model reasons and commits to a confident verdict, positional bias is less of a factor. Future work could explore these tendencies in more depth (e.g. at a larger scale with order-balanced presentation). A.1.4
Software libraries as a case-study
As part of our case-studies, we look to the software package ecosystem as a way to apply this work but note that there are shortcomings of processing data at scale. We assume that all SPDX identifiers are unique and that all packages have a corresponding license where applicable, but realize that if they are not, there may be duplications and sparsity in the dataset. The deps.dev MinimumDepth parameter represents the shortest path from a library to a dependency across all dependency trees, but we acknowledge that it does not show the full depth of the tree.
19
Ecosystem
Max depth
p50
p99
npm PyPI Cargo Maven conda-forge
199 17 14 15 6
4 2 3 2 1
12 5 7 7 2
Table 7: Length of compatible dependency chains across software packages.
Ecosystem
Compliant
Incomparable
Violation
n edges
npm PyPI Cargo conda-forge Maven
47.7% 54.2% 83.1% 40.9% 52.9%
39.8% 3.8% 4.6% 1.6% 0.0%
12.6% 42.0% 12.3% 57.4% 47.1%
2.5B 53.1M 30.5M 122K 66.2M
Table 8: License relations across software package ecosystems. Incomparability is relatively low across all packages (≤5%), with the exception of npm (∼40%).
A.2
Prompt iterations
We iterated on prompts in later runs, but the plots in the main paper use an earlier version without an explicit definition of logical entailment; we compare prompt results and intermodel agreement below. We run the most recent prompt version with Sonnet and DeepSeek on a smaller, selectable subset of Hugging Face licenses (93 licenses). Improvements include removing model self-confidence as an unnecessary measure, a simplified output schema, instructing models to assess incompatibility as a separate, additional step from determining the main verdict, and an enhanced definition clarifying that incompatibility refers to restrictions operating on distinct dimensions (or those that are “orthogonal” to one another). While we believe these improvements are justified, the plots and findings in the main paper reflect earlier iterations; we find the reported findings stay consistent on the HF set and hope the improved versions can be used and shared publicly for future analysis.
A.3
Prompts used for LLM analysis
Pairwise ordering prompt Step 1. Ordering (required). • A > B indicates A is strictly more permissive. • A = B indicates equivalent in scope (same net obligations and permissions, possibly different wording, for example MIT vs. ISC, CC0 vs. Unlicense). • A < B indicates B is strictly more permissive.
20
Figure 7: The agreement between models (Sonnet and DeepSeek) and prompt iterations for pairwise verdicts for the HF-93 dataset (93 licenses selectable on Hugging Face). Equivalence is a positive determination, not an abstention. Step 2. Incomparability (orthogonal obligations only). Set incomparable=true when each license is materially heavier than the other on at least one distinct dimension. Set incomparable=false when the licenses are equivalent (verdict A = B); equivalence is not incomparability. Output schema. {
}
" o r d e r i n g _ v e r d i c t " : "A > B | A = B | A < B" , " incomparable " : true | f a l s e , " incomparability_summary " : "<one o r two s e n t e n c e s >" o r n u l l , " insufficient_information ": true | f a l s e
Feature extraction prompt System. You extract boolean features from license texts. Return only a JSON object, no explanation, no markdown, no code fences. Use true, false, or null (only when genuinely impossible to determine from the text). User. Answer the following 10 questions verbatim from the Loreto, Oliner & Woo (2004) software license taxonomy. Use the license text as your sole source of truth. 1. requires_attribution. “Copyright Notice Must Be Attached?” TRUE if the license requires preserving copyright notices, author credits, or any acknowledgement on redistribution. FALSE only if attribution is explicitly waived. 2. requires_sharealike. “Same License For Larger Work?” TRUE if modifications or distributions must use the same or a compatible license (any copyleft). FALSE for permissive licenses with no license propagation requirement. 3. user_can_modify_code. “User Can Modify the Code?” TRUE if the license permits modification. FALSE only if modification is explicitly prohibited.
21
4. user_can_create_derivatives. “User Can Create Derivative Works?” TRUE if derivative works are permitted. FALSE only for explicit No Derivatives restriction. Copyleft licenses that require sharealike still permit derivatives; TRUE. 5. allows_commercial_use_derivatives. “User Can Ask Money For His/Her Derivative Works?” TRUE if the user may commercially distribute derivatives. FALSE if explicitly prohibited (for example, any NC Creative Commons variant). 6. allows_commercial_use_redistribution. “User Can Ask Money For Redistribution of Software Code?” TRUE if the user may charge for redistribution. FALSE only on explicit prohibition. Treat silence as TRUE. 7. gpl_compatible. “GPL Compatible?” TRUE if this license can be combined with GPL code and the result distributed under the GPL. Reason from the text’s obligations only. Return null if insufficient to determine. 8. users_can_create_binaries. “User Can Create Binary Applications?” TRUE if users may compile or embed in binary applications without special restrictions. 9. requires_source_disclosure. “Must Distribute Modified Source Code?” TRUE if distributing modifications requires making source available. 10. copyleft. “Copyleft?” TRUE if any copyleft or sharealike requirement exists. The model is given the license name and license text, and returns a flat JSON object with all ten fields.
A.4
Model calibration
We use multiple models to calibrate our confidence in LLM verdicts. To study coherence, we use a lookup table with every license pair and a corresponding verdict. To study whether there are contradictions, we look for cases where a model judges license A as more permissive than B in one instance but less permissive in another. We find no such contradictions. Moreover, we check for cycles, where A > B and B > C but C > A. We find none. In other words, we find no Condorcet cycles, indicating that the judgments are transitive and coherent, as they form a consistent ordering of verdicts (Arrow, 2012). We also report the inter-rater agreement (between models) for the extracted binary features. We compute Cohen’s κ, where each feature has three possible values (True/False/null), and find that the average score is 0.70, suggesting relatively strong agreement between the models (Sonnet and DeepSeek). The anomaly is the GPL compatibility feature, where we see relatively low agreement. We believe this is because GPL compatibility is usually stated outside of the license text and listed as an FSF tag when a license is uploaded to the SPDX registry.
22
Figure 8: Cohen’s κ analysis for features between Sonnet 4.6 and DeepSeek. For all extractions, temperature was set to 0.
23
n
Agreement
κ
Sonnet 4.6 vs GPT-4o Sonnet 4.6 vs Qwen3 GPT-4o vs Qwen3
4,271 4,271 4,264
77.6% 84.7% 83.7%
0.577 0.700 0.681
v7.1
Sonnet 4.6 vs DeepSeek V3
4,278
79.9%
0.611
v4
Sonnet 4.6 vs GPT-4o Sonnet 4.6 vs Qwen3 Sonnet 4.6 vs Gemini 2.5 Pro Qwen3 vs Gemini 2.5 Pro
10,932 144,457 37,761 37,761
81.0% 80.5% 76.5% 87.6%
0.623 0.618 0.538 0.751
v7.1
Sonnet 4.6 vs DeepSeek V3
89,799
72.5%
0.481
Corpus
Prompt
Model pair
HF-93
v4
SPDX-747
Table 9: We calculated inter-model agreement on pairwise comparisons for HF-93 (a subset of licenses selectable on Hugging Face, evaluated under prompt version v7.1) and SPDX-747 (the full set of licenses, evaluated under prompt version v4). Cohen’s κ is listed on the rightmost column and agreement computed from the percentage of pairs where models produce the same verdict (A > B, A < B, or A = B) is listed on the 5th column. In our prompt, we give models the ability to independently deem two licenses incomparable, instructing them to do so only after determining a verdict so that we can study the nature of incomparability itself. In earlier experiments, models were liberal in flagging incomparability when given the opportunity upfront, which motivated this order of operations. To extract the most common themes from model rationales, we prompt an LLM to identify core themes for each rationale separately, then canonicalize the resulting themes by passing the joint list to another model instance that groups semantically similar ones, which we then count. Below (Figure 9), we plot the most common themes by frequency across incomparability rationales. We count 3,718 incomparable pairs out of 4,278 total ( 93 from 2 the HF-93 license set) and plot the top 15 of 28 categories.
24
Figure 9: Breakdown of incomparability rationales. Haiku 4.5 is used for canonicalization phase of theme extraction due to its efficiency and the simpler task of classifying themes against a fixed list compared to initial parsing which requires deeper reasoning where Sonnet 4.6 is used. Phase 1: Taxonomy derivation (Sonnet 4.6) You are analyzing descriptions of why pairs of software licenses are legally incomparable. Each description explains which specific legal dimensions put the two licenses in tension — e.g., one imposes copyleft obligations the other does not, or one grants patent rights while the other restricts patent use. Below are 80 representative descriptions: {descriptions} Task: Derive a canonical taxonomy of 20–28 categories covering the legal dimensions that make licenses incomparable. Each canonical category should: - Have a short, precise label (3–7 words, title case) - Represent a coherent, distinct legal dimension or obligation type - Be specific enough to be informative Return ONLY a JSON array of canonical category label strings, nothing else.
Phase 2: Mapping (Haiku 4.5) Canonical legal dimension categories: {taxonomy} Each item below is a 1–2 sentence description of why two software licenses are incomparable. Map each to the single most relevant canonical category. Return ONLY a JSON object mapping the exact input string to the canonical category label. If none fit, use “Other”.
25
Descriptions: {descriptions}
A.5
Feature analyses β̂
Taxonomy
Feature
Nordlander
Allows commercial use of derivatives Allows commercial redistribution GPL-compatible Allows modification Allows binary distribution Allows derivative works Requires source disclosure Requires attribution Copyleft
+0.79 +0.52 +0.38 +0.37 +0.13 +0.03 −0.48 −0.69 −0.80
Kapitsaki
State-changes obligation Network use = distribution
−0.04 −0.34
ML
Has AI-use restrictions
−1.43
Table 10: Linear regression coefficients (β̂) for license features across three feature taxonomies. Positive values indicate features associated with more permissive licenses; negative values indicate features associated with more restrictive ones.
Figure 10: Features plotted based on logistic regression on permissiveness. When looking at the barbell plot in the main paper (Figure 2), we can study which individual features appear the most commonly and whether this signals permissiveness or restrictiveness. With a combinatorial view, we can do the same with the group of features that define 26
Figure 11: Upset plot depicting differences in ordered license pairs grouped by the number of features that differ (Lex et al., 2014). For every group, there is a bar plot showing the frequency of every divergence type. Gray cells mean that a feature is common between the pair. A blue cell means that given that this feature disagrees in a pair, it is because it was present in the less permissive license. An olive cell means that given this feature disagrees in a pair, it was not present in the less permissive license. This plot is a complement to 1. a license. In this upset plot, we can visualize the features that differ and show the rate of divergence, where across all the pairs, we compare the less permissive license to the more permissive license, and see how many features differ and which ones. We can then count the rates of the different forms of divergence across all the instances.
27