Clarify RegistryCI license-check API for REUSE/SPDX-compliant packages

[gwr-de]

Context

Related to #48137 and #140158, but narrower: this is not about accepting non-OSI packages, but about recognizing OSI-approved licensing evidence in REUSE/SPDX-compliant repositories.

Problem

The current check appears oriented toward a single root LICENSE file. That works for simple packages, but is imprecise for repositories where source code, docs, CI files, generated files, and vendored files may have different license expressions.

In such repositories, a full-text root LICENSE file can be misleading: it may suggest that the whole repository is under one license. REUSE/SPDX expresses this more precisely through SPDX headers, REUSE.toml / .reuse/dep5 metadata, and canonical texts under LICENSES/. A root LICENSE file may therefore deliberately be only a pointer to the machine-readable licensing information.

Reference case and possible tooling

I have published an early-development reference package:

https://github.com/bslMS/ReuseLicensing.jl

The package currently provides SPDX license-expression parsing and policy evaluation. It is itself REUSE-compliant and uses a pointer-style root LICENSE file with canonical license texts under LICENSES/.

The next development step is file-level and repository-level policy evaluation, likely consuming reuse lint --json and/or REUSE-generated SPDX/SBOM data.

A RegistryCI-facing API could be as simple as:

has_general_registry_approved_source_license(path)::Bool

or for diagnostics:

evaluate_package(path; policy = GeneralRegistryPolicy())

The intended policy would be narrow: verify that package-relevant Julia source files have an OSI-approved SPDX license path, while reporting non-source domains such as documentation, metadata, CI files, or media separately.

Questions

1. Would General be open to treating REUSE/SPDX evidence as an alternative to the traditional single root LICENSE heuristic?
2. Should such a check be repository-wide, or restricted to package-relevant source domains such as src/, ext/, generated Julia files, and files included in the package tarball?
3. Would a pointer-style root LICENSE file be acceptable if the authoritative license information is REUSE-compliant and machine-verifiable?
4. Would ReuseLicensing.jl itself be a useful reference case, or should I adapt its layout before attempting registration?

I would be happy to shape ReuseLicensing.jl so that it exposes a small, stable API for CLI suitable for RegistryCI, if there is interest in this direction.

---

Disclosure: I used AI assistance to improve the clarity and structure of this issue text.

[goerz]

Would General be open to treating REUSE/SPDX evidence as an alternative to the traditional single root LICENSE heuristic?

At least I personally would strongly endorse this idea, assuming it can be done with minimal maintenance overhead on RegistryCI. I believe that encapsulating the functionality in ReuseLicensing.jl would guarantee this ease of use.

Should such a check be repository-wide, or restricted to package-relevant source domains

I think all files in the repo need to be under a license that allows redistribution (however that's expressible as a SPDX query). Maybe we would like for at least part of the files (the source code) to be under an OSI-required license. Or maybe we'll want all files to be under at least one license that OSI-approved. TBD.

Would a pointer-style root LICENSE file be acceptable if the authoritative license information is REUSE-compliant and machine-verifiable

I would lean towards a policy where if REUSE is detected, there is no further check on LICENSE at all, and we delegate entirely to the ReuseLicensing.jl package. So, yes.

Would ReuseLicensing.jl itself be a useful reference case, or should I adapt its layout before attempting registration?

Assuming we agree that we want to adopt REUSE-based licensing as a possibility for registered packages (which I hope we will), then yes, the licensing of ReuseLicensing.jl should allow it to be registered.

If we also want to delegate to ReuseLicensing.jl to make the determination of whether packages meet the requirements for registration, then I think it might be good if the package was hosted under the JuliaRegistries organization. You would still be the maintainer of the project, of course.

[DilumAluthge]

I think all files in the repo need to be under a license that allows redistribution (however that's expressible as a SPDX query). Maybe we would like for at least part of the files (the source code) to be under an OSI-required license. Or maybe we'll want all files to be under at least one license that OSI-approved. TBD.

Without weighing in on the rest of this discussion, I wanted to address this part specifically.

The requirement for packages in the General registry is that every file in the package must be licensed under an OSI-approved license. This has been the requirement since the beginning of the General registry¹. I'm not interested in revisiting or loosening that requirement.

The discussion here seems to be about having different OSI-approved licenses for different files in the package, and using REUSE to store the licensing info in a machine-parseable way. It's fine to have that discussion.

But relaxing the OSI-approved license requirement (for every file) is a non-starter.

Footnotes

1. And in fact, it has been the requirement since METADATA, the precursor to the General registry. ↩

[gwr-de]

Thanks, that is helpful. It is also good to see that the need to discuss REUSE-compliant repositories is acknowledged.

I fully agree that relaxing the OSI-approved license requirement for Julia source code would be a non-starter for General. That is not what I am asking for.

The point I am trying to clarify is narrower: does General require an OSI-approved license for every file in the repository, or for the package-relevant software/source-code domain?

ReuseLicensing.jl may be a useful concrete case here. The repository contains Julia source code under an OSI-approved software license. But it also ships non-code assets, in particular:

• license texts used by the package itself to reason about license use and intended later for tooling such as a REUSE plugin for PkgTemplates.jl;
• documentation;
• an icon from EU Interoperable Europe.

These are not all software-code files. Some license texts are under CC0-1.0; one shipped license text is under CC-BY-4.0; the icon is under CC-BY-SA-4.0. These licenses are free/libre licenses in the FSF sense, but they are not OSI-approved software licenses.

As far as I understand the legal situation, I cannot simply relicense those files under the package’s software license, because I am not necessarily the copyright holder of those materials. The precise file-level license information is therefore part of the compliance story.

There is also a converse problem: software licenses are not necessarily the right tool for non-code assets. GNU/FSF distinguishes free software licenses from free documentation licenses and recommends the GNU FDL for manuals; Creative Commons likewise treats documentation, educational resources, music, photographs, databases, and separate artistic elements as suitable CC-licensed material, while discouraging CC licenses for software. This supports a domain-correct policy: OSI-approved licenses for software/source-code files, and appropriate free non-software licenses for documentation,
icons, license texts, and similar assets, provided the distinction is machine-readable.

This is also where the single-root-LICENSE model becomes problematic. If I put only the software license text into the root LICENSE file, that may suggest that the whole repository is under that license, although some non-code assets are not. REUSE/SPDX is attractive precisely because it avoids that ambiguity.

So the practical question is:

Should a General-compatible REUSE policy require OSI-approved licensing for all package-relevant software/source files, while allowing non-code files such as documentation, metadata, license texts, and icons to use appropriate non-software free licenses, provided that this is clearly declared and machine-verifiable?

That seems different from relaxing the OSI requirement for package code.

So I would like to understand whether your statement means:

1. every file in a General-registered repository must be under an OSI-approved license; or
2. every package-relevant software/source-code file must be under an OSI-approved license, while non-code assets may use appropriate free non-software licenses if declared via REUSE/SPDX.

If the intended policy is (1), then repositories containing CC-licensed documentation, icons, license texts, or other non-code assets would appear to be structurally problematic for General, even when the package code itself is OSI-approved. If the intended policy is (2), then this is exactly the kind of policy boundary that ReuseLicensing.jl could help make mechanically checkable.

[DilumAluthge]

appropriate free non-software licenses

This is part of the problem. Who defines which licenses count as a "free non-software license"? We don't want General registry maintainers to make those determinations, which is why we've kept things simple: a license is allowed if and only if it is in the OSI's list of OSI-approved licenses.

One idea (this isn't a promise, just a non-binding idea): We could maybe broaden the requirement to something like this:

1. Every file under src/ must be licensed under an OSI-approved license.
2. Every file in the package must be licensed under at least one of the following:
   • An OSI-approved license.
   • An FSF-approved free software license (where "FSF-approved free software license" means a license listed as a "free software license" on https://www.gnu.org/licenses/license-list.html ¹).
   • An FSF-approved free documentation license (where "FSF-approved free documentation license" means a license listed as a "free documentation license" on https://www.gnu.org/licenses/license-list.html ¹).

Would that broadening satisfy the use cases you have in mind?

The idea is that we specify sources of truth (in this example, OSI plus FSF) that make the determinations for us, so that General registry maintainers don't have to make determinations, we just check these lists maintained by the external sources of truth.

For this idea, I just picked the FSF because they're another notable source of info on FLOSS licensing. But we'd need to think and deliberate some more before we decided to use the FSF as a source of truth.

By "every file in the package", I mean every file that gets shipped in the package tarball. So if you download e.g. https://pkg.julialang.org/package/[package-uuid]/[treehash].tar.gz, and extract that tarball, every file you get from that tarball counts as a "file in the package", because that's what we distribute. For example, this URL (https://pkg.julialang.org/package/7876af07-990d-54b4-ab0e-23690620f79a/e1f0e1a832ccd8e97d6d0348dec33ee139a5aeaf.tar.gz) gives you the contents of the Example.jl package at version v0.5.5 (where I got the UUID from https://github.com/JuliaRegistries/General/blob/master/E/Example/Package.toml and the treehash from https://github.com/JuliaRegistries/General/blob/master/E/Example/Versions.toml).

---

One note: "package" and "repository" are not necessarily the same thing. Specifically, they differ in the case of "subdirectory packages".

For example, consider this repository: https://github.com/JuliaRegistries/RegistryCI.jl

That repo contains two "subdirectory packages":

1. AutoMerge.jl: https://github.com/JuliaRegistries/RegistryCI.jl/tree/master/AutoMerge
2. RegistryCI.jl: https://github.com/JuliaRegistries/RegistryCI.jl/tree/master/RegistryCI

The files under https://github.com/JuliaRegistries/RegistryCI.jl/tree/master/AutoMerge are all part of the AutoMerge.jl package. The files under https://github.com/JuliaRegistries/RegistryCI.jl/tree/master/RegistryCI are all part of the RegistryCI.jl package.

But, if I understand correctly (and please correct me if I'm wrong), files that are outside of those two paths are not included in either package.

Footnotes

1. Confusingly enough, this FSF page also lists non-free licenses. Obviously I'm excluding those, I'm only talking about the ones that the FSF explicitly categorizes as "free software licenses" or "free documentation licenses". ↩ ↩²

[gwr-de]

I think that is exactly the right direction: delegate the normative license classification to external sources of truth, rather than asking General registry maintainers to make ad-hoc determinations.

One implementation detail may be worth considering: the SPDX License List data already contains machine-readable metadata for this. In particular, SPDX license entries expose traits such as OSI approval and FSF free/libre status. So RegistryCI would not necessarily need to scrape or manually interpret OSI/FSF web pages; a tool can consume a pinned SPDX License List snapshot and evaluate SPDX license expressions against that snapshot.

That is also how I currently approach this in ReuseLicensing.jl: the package uses a curated SPDX License List snapshot and then reasons over SPDX license expressions using traits such as isOsiApproved and isFsfLibre.

Your proposed broadening almost works, but I think it may need to cover FSF-free/libre status more generally, not only the FSF “free software” and “free documentation” sections.

The reason is that the FSF license list also recognizes free licenses for works other than software and documentation. That category is relevant for assets such as icons, media files, license texts, datasets, and similar non-code material. In my concrete case, the relevant examples are CC0-1.0, CC-BY-4.0, and CC-BY-SA-4.0. These are not OSI-approved software licenses, and I would not use them for Julia source code. But they are free/libre licenses for suitable non-code works.

So a mechanically checkable policy shape might be:

1. Every package-relevant Julia source-code file, in particular files under src/ and ext/, must have an OSI-approved license path in its SPDX license expression.
2. Every file in the package tarball must be licensed under at least one externally accepted free/libre license path, for example one marked as OSI-approved or FSF-free/libre in a pinned SPDX License List snapshot.
3. The policy should still distinguish file domains, so that a license acceptable for an icon or documentation file is not thereby treated as acceptable for Julia source code.

This keeps the policy mechanically checkable and avoids asking General maintainers to make license judgments. The source of truth would be the external license classification, with SPDX providing the normalized identifiers and machine-readable metadata.

The clarification about package tarballs versus repositories is also very useful. I agree that the relevant object for RegistryCI should be the package tree that is actually distributed, not necessarily the whole repository.

[DilumAluthge]

[Thanks for disclosing the AI use in your original issue. I should have mentioned this earlier, but for this discussion, can I ask that you refrain from using AI assistance in writing/editing text?]

[gwr-de]

[Thanks for disclosing the AI use in your original issue. I should have mentioned this earlier, but for this discussion, can I ask that you refrain from using AI assistance in writing/editing text?]

I understand the concern, and thanks for raising it openly.

I would like to add some context: English is not my native language, and this discussion is both technically and legally subtle. I have used AI assistance mainly to improve clarity, structure, and English wording. I read, check, and edit every sentence myself, and I take full responsibility for what I post.

That said, I also do not want the tooling question to distract from the RegistryCI licensing discussion. I will keep future replies concise and make sure they reflect my own understanding and position.

[gwr-de]

Here is the gist of my last post in my very own words as a TL;DR:

• SPDX License List data provides the "traits" isOsiApproved and isFsfLibre and I am using that information ("external source of truth").
• To be able to deal with REUSE without restrictions, ReuseLicensing.jl parses SPDX license expressions, e.g., MIT OR LicenseRef-US-PublicDomain needs to be handled. This is why I propose approved license path as the foundation for approval.
• CC-BY-4.0, CC0-1.0 and CC-BY-SA-4.0 in the ReuseLicensing.jl repository have isFsfLibre but not isOsiApproved.
• I believe it to be prudent to distinguish code and non-code like documentation, assets, project artifacts (sidestepping a discussion on whether they are copyright-able material completely here).

So given that we can use such an SPDX license list snapshot for reasoning about license expressions and files I propose this policy as "in line with General's demands" and good for tool-based checking:

1. Every package-relevant Julia source-code file, in particular files under src/ and ext/, must have an OSI-approved license path in its SPDX license expression.
2. If a file is Julia code, then it should have a clear OSIApproved() path (e.g., MIT OR LicenseRef-US-PublicDomain works) and other non-code files or documentation files should have one of OSIApproved() or FSFLibre().
3. If I understand you correctly, then we only need to worry about files in a package tarball.

[goerz]

Requirement for Multiple Licenses

I had thought that CC-BY-4.0 etc. were OSI approved, but turns out they're not… OSI focuses on code licenses exclusively. So if we take licensing seriously, we simply cannot require OSI for all files. Whether a markdown file in docs can be MIT licensed is debatable: strictly speaking, it treats the .md as code, which works for redistribution and normal software development, but would be violated if someone wanted to include the documentation in an online tutorial. It would have to rely on "fair use", which doesn't exist (at least not in the same form) in European jurisdictions. More clearly, there is no way a .PNG file can be MIT licensed; that just doesn't make sense. I'm also not sure a Project.toml can be MIT licensed. The REUSE FAQ, the How and why to properly write copyright statements in your code essay, and the Copyright and license of Julia packages Discourse thread make these arguments in depth. The upshot: I don't think "a single license can cover the whole project" is really a defensible position.

[goerz]

Which Licenses to Allow

As for which licenses to allow, we might want to distinguish practical concerns (does the license permit the registry to redistribute code and assets without restrictions) from ideological concerns (keeping the Julia ecosystem "open"). I'm fine with including ideological concerns — OSI licenses only for source code files. But @ViralBShah has argued for broader permissiveness in #140158. Regardless, we have to accept non-code licenses for non-code files. I'm not entirely sure isFsfLibre covers free documentation licenses in addition to free software licenses. We definitely want CC-BY-4.0 and CC-BY-SA-4.0, and probably also CC-BY-ND, CC-BY-NC, CC-BY-NC-SA, CC-BY-NC-ND (not OSI approved, not FSF-free, but presumably sufficient for distribution through the General registry). The full SPDX license list is too broad — it includes some very non-free licenses.

[goerz]

Issues with a main LICENSE

Up until recently, my position was that it's fine to have fine-grained licensing and just put a "main" LICENSE in the repo root that covers the bulk of the code in src. But @mbauman finally convinced me that this doesn't really make sense. This is the current situation, and what we would stick to if we don't adopt something like what's proposed in this issue. I understand a lot of packages will still use a single simple LICENSE, and that may be fine in the context of academic open source. But it's basically saying "we haven't really thought about licensing in a serious way", combined with a pinky-swear not to sue anyone for some very broad notion of "fair use". But it's confusing, and it also puts the registry in legally murky waters:

• If we just blindly assume the LICENSE actually covers the entire tarball, that's an illusion that wouldn't hold up under legal scrutiny
• There might be an MIT license for the code, but that tarball might contain assets (commercial datasets, maybe) under a highly restrictive license, and we probably don't want to put such files on registry servers. It would be nice if we could catch that and prompt the author to obtain a suitable dual (non-code) license

We already have registered packages that include files not actually covered by whatever the main LICENSE claims. I actually have used REUSE directly, e.g. in GRAPE.jl. Technically, that package is not registerable under a "all files are OSI approved" rule. And we have pently of packages where even if they claim to have a single LICENSE, that license is can't logically apply to all the files in the repo.

If we rely on a "gentlemen's agreement" that "all files are properly licensed", that may be fine, but at that point, we're just using the main LICENSE to make the bot happy. It makes a lot more sense to have a LICENSE explaining REUSE, as ReuseLicensing.jl does. Of course, that currently fails the detection, but I think that ReuseLicensing.jl is a package that should 100% be in the registry (independent or not of whether we use it in RegistryCI), and also that we shouldn't force @gwr-de to essentially lie in their LICENSE file. We could detect REUSE and then just ignore all licensing concerns for automerge, but this isn't necessary: The REUSE tooling as exposed by the ReuseLicensing allows us to do things properly.

Dual-licensing is another concern, e.g., to get around Title 19 licenses. Right now, the registrator will reject LICENSE files that include dual licensing; and, putting just one of the licenses in the LICENSE file seems like actively lying, and a generally bad idea.

[goerz]

Policy for registered packages

This is why I propose approved license path as the foundation for approval.

@gwr-de: Do you have specific suggestions for what "policy queries" should count as "acceptable" for registration? (Pseudo-code is fine.)

This logic should live in RegistryCI — I don't think we want ReuseLicensing to have an is_registry_approved function. That's a policy matter that should be entirely under the registry maintainers' control. I think we can rely on functions like OSIApproved() and FSFLibre() to be accurate, but regardless, I think the package should be hosted in the JuliaRegistries org so that registry maintainers can guarantee its accuracy, fix critical bugs, and make releases when necessary.

[DilumAluthge]

But @ViralBShah has argued for broader permissiveness in #140158 (comment).

I'm beating a dead horse here. I want to emphasize that any policy change that would allow non-FLOSS Julia source code is, in my opinion, a non-starter, because (as I've written multiple times), the General registry has always required Julia code to be licensed under an OSI-approved license (which thus means that the Julia code is FLOSS, at least according to the OSI Open Source Definition).

Please, can we contain the discussion in this thread only to policies that retain the status quo of all files in a Julia package being licensed under a FLOSS license.

[goerz]

Subdirectory Packages

One important complication is subdirectory packages. Currently, subdir packages must contain their own LICENSE file, because only the subdirectory gets tar-balled for distribution and must be self-contained.

@DilumAluthge: What context does the registrator have when it runs the check. Is it looking a full repo checkout, or literally just the subdir?

@gwr-de: Does the REUSE toolchain (and ReuseLicenses.jl) support a completely self-contained subfolder? It would need its own LICENSES subfolder and potentially its own REUSE.toml. Can the tooling handle how that might interact with the LICENSES folder at the top level of a monorepo?

[goerz]

Please, can we contain the discussion in this thread only to policies that retain the status quo of all files in a Julia package being licensed under a FLOSS license.

I'm totally on board with that. OSI for all source file seems like a good idea to me.