>> On the other hand, "reuse-tool" does not recognize "d/copyright" as a >> license file, so it warns if there is no license for that file. >> Therefore, "spdx2debian" currently generates a license file for it using >> "CC0-1.0" as license and "None" as copyright holder. It is also a >> workaround. > > Why not exclude debian/copyright from "reuse-tool" coverage, instead of > bogusly and confusingly inventing a licensing that noone granted? > > My guess is that your workaround was done to make the computed result > appear perfect. That seems to me to be the exact same reason for the > question raised in this thread.
Under what circumstances does spdx2debian "invent" the licensing for d/copyright? When the Debian source package is not itself REUSE compliant, [spdx2debian wouldn't even run][0]. The solution for this case, I [found to work well][1], is a REUSE.toml in debian/. I could only reproduce the described behavior locally, when running spdx2debian on a REUSE compliant upstream project (i.e. no debian/ directory) once to generate debian/copyright and *then re-running* spdx2debian. I agree with Jonas that coming up with a licensing for debian/copyright on the second run is misleading. The default behavior for spdx2debian should be that w/o additional work by the maintainer the project has just become not fully reuse compliant (no copyright information for d/copyright available) and therefore should error out accordingly. [0]: https://codeberg.org/buhtz/spdx2debian/issues/9 [1]: https://salsa.debian.org/python-team/packages/hyperorg/-/blob/debian/latest/debian/REUSE.toml?ref_type=heads > I maintain the tool "licensecheck" and chose to not invent licensing or > copyright, but instead add FIXMEs to the produces output. Other tools > has then emerged which takes the licensecheck output and "improves" it > by stripping those FIXMEs :-) xD - hope you didn't take that personally, Jonas! Thanks for your work on licensecheck.
signature.asc
Description: PGP signature
