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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.