Hi all,
We currently have the problem that the REUSE tool which you can download from pypi [^1] actually is not REUSE compliant although the source code itself is. This might also be true for many other projects who distribute their releases through similar services.
The reason is that by compilation files are being created, e.g. binaries or documentation, which do not carry license information nor are accompanied with corresponding .license files. How shall we deal with those?
Carmen and I discussed several options, but didn't find something completely convincing. So please share your opinion to find a good solution:
1. Ignore the whole problem and assume that people interested in reusing source code will find the source repo and start from there anyway. This would ignore the few cases in which FOSS projects do not have a publicly accessible VCS and are only published via tarballs containing such problematic files.
2. Recommend projects to always link to the source code repo in the README file so interested parties will always find the REUSE compliant code somewhere and do not reply on the released tarball.
3. Recommend projects to put the problematic files in the .gitignore file. REUSE will not take these files into consideration anyway. The problem is that people will probably remove this file from a packed release, and sites like pypi might to so as well.
4. Recommend projects to add the problematic files to a DEP5 file which is also shipped with the product.
What do you think?
Best, Max
[^1]: https://pypi.org/project/fsfe-reuse/
TL;DR:
• for source code VCS – REUSE already works as intended • for source code tarballs – reuse already works as intended, but we might want to mention that they should double-check if the tarballs have all the needed info in it as well • for packages of any other sort – outside the scope of REUSE
Die 18. 04. 19 et hora 18:38 Max Mehl scripsit:
We currently have the problem that the REUSE tool which you can download from pypi [^1] actually is not REUSE compliant although the source code itself is. This might also be true for many other projects who distribute their releases through similar services.
The reason is that by compilation files are being created, e.g. binaries or documentation, which do not carry license information nor are accompanied with corresponding .license files. How shall we deal with those?
This will be a common and probably inevitable problem with all packaging and building.
In general, I would say that the biggest question is to what do we want the REUSE spec to apply to.
I think we aleardy established, that its goal is to apply to source code. So binary packages are not a target.
I don’t remember REUSE being limited to just VCS repositories. Sure, the “REUSE compliant” badge would show on the repo, but in the real world, that badge would likely be tied to a CI/CD anyway, so it would be dependent on the repo.
For source tarballs, no-one is preventing anyone to add extra REUSE info when they add extra files. Maybe we should just put it in the FAQ that if they change the tarball, they need to double- check if they need to update the info required by REUSE.
For other packages (source-ish, or binary), one could implement hooks into the build system to look at the REUSE-compliant source code that they are building and then generating the needed extra info for the output build.
Such build tool would be a wet dream for many compliance officer, but I think it’s far from what REUSE needs to concentrate on right now. What REUSE wants to ensure is that the source code – which is the input for everything else – carries all the needed info. Then others – SPDX, others tools – can build on top of that. In fact, I would think this is exactly where REUSE stops and SPDX takes over. We are not trying to duplicate work here.
I like the link to (ultimate upstream) source code repo idea in general for different reasons. But it will carry the same problem as the “attribution through VCS” in SFLC best practices – namely, that history teaches us that the repo URL is likely to change in the future. So that’s not going to be a reliable source in the long term. (still useful info in the short term though)
cheers, Matija