Hello there,
during our submission to JOSS of our software AMIRIS we encountered the following issue:
Automated license crawlers (e.g. at JOSS or gihub) do not identify our LICENSES storing individual license files as required by the REUSE software specifications.
Putting an additional LICENSE file in the root of the repository is not allowed by REUSE specs.
Do you have any idea how to make the project licenses detectable by crawlers?
Thank you in advance
In the meantime, this documentation, directly related to GitLab, might be of use:
You can then try running the REUSE helper tool manually and perhaps address any issues that arise?
(subsequent edit) I see you do that anyway as part of your continuous integration (CI) process…
Dear @robbie.morrison, thank you for asking around. Regarding your advice on the GitLab documentation: We already implemented that some time ago (it works nicely). However, it just checks the REUSE-compatibility in our CI-Pipeline. However, based on this tool I think it should be fairly easy to enhance license detection bots (albeit probably out of our scope).
@Schimi: my request as follows, will report back as appropriate.
The Journal of Open Source Software (JOSS) is currently reviewing the AMIRIS codebase: Agent-based Market model for the Investigation of Renewable and Integrated energy Systems.
REUSE compliance checks, undertaken as part of continuous integration (CI), necessarily provide passes.
The JOSS editorialbot however fails to discover a valid software license.
Is anyone familiar with this problem? Should I file a bug report with JOSS?
A bit more background here:
â–˘
@Schimi: Three (was two) cross‑posting under the Chatham House rule (CHR), so I cannot cite my sources. Note too that some of the discussion drifted to GitHub rather than GitLab. HTH, R
I think there is a fundamental misunderstanding in the forum entry you posted:
“Putting an additional LICENSE file in the root of the repository is not allowed by REUSE specs.”
This is not correct. While the REUSE specification 3.0 does require the existence of a LICENSES/ directory and mandates the format license texts are stored, it does not disallow having a LICENSE or COPYING file at the root of the project.
Please see the spec and a corresponding FAQ item:
Now, the real question: why can GitHub not interpret the LICENSES/ directory? We (as in the REUSE team) tried a few times to make it happen but there wasn’t much interest by GitHub, see this issue. The last status, to my knowledge, is that they would like to have a Pull Request for this feature in licensee, the software they use to detect licenses. However, whether the feature would then also be implemented into the GitHub UI was not certain at all.
If GitHub (and also other software forges such as GitLab or Gitea) would truly like to improve this situation and adapt best practices for communicating licenses and copyright, I am positive that they would receive support by the REUSE team and its wide community.
I will note that https://sr.ht does support the LICENSES/ directory just fine from what I can tell.
As proof, look at:
which properly lists all of the different licenses the project is under in the upper right corner, based on parsing the LICENSES/ directory.
In contrast, as you point out, GitHub does not understand this at all:
Last year, GitHub pushed an update so you can have multiple files at root level, for instance LICENSE-MIT and LICENSE-GPL:
The repo they show as an example is:
Of course, this does not match REUSE’s best practices. However, the UI seems to exist so GitHub could just start to also look in LICENSES/ for license text files.
Dear @robbie.morrison ,
thank you for your efforts!
We placed an additional LICENSE file at the project root which resolved the issue at JOSS despite our understanding of the REUSE 3.0 specifications stating:
Each License File MUST be placed in the
LICENSES/directory in the root of the Project.
It would be cool if GitLab / Github / JOSS would support REUSE by default. We discovered the corresponding issue at GitLab.
HI @Schimi, I sensed that would be the solution but did not want to say so directly. Good luck with the rest of the review. R