My 2c from the peanut gallery...
Having the license file IN the folder is consistent with the repo and package scenarios where the license file(s) are at/near the root of the content being licensed. Also helps ensure the license info stays near the files it targets in copy/paste scenarios.
I would try to find some symmetry from the top down rather than bottom up.
Jeff
On Mon, Mar 9, 2020 at 10:47 AM Carmen Bianca Bakker carmenbianca@fsfe.org wrote:
Hi Lars, all,
Je ven, 2020-03-06 je 15:41 +0000, Geyer-Blaumeiser Lars (IOC/PDL4) skribis:
Some thoughts here
You propse to have the file right beside the folder. I understand this
due to the similarity to the mechanism for files, but I would rather prefer to have the file inside the folder. Why, because it makes the connection to the folder clearer, if the file is beside the folder it might be difficult to see the association because, e.g., dependending on the browser the files might be shown separately from the folders and the association for a human looking at the parent folder is difficult.
This makes sense as an accessibility/discoverability feature. It also, however, removes the most attractive feature of `folder.license`, which is that it would be equivalent to `file.license`.
Will the license file allow to reflect multiple licenses, it could be
that the copyright holder and even the licenses differ for the different files referenced? Or which mechanism would allow to make as few license references as possible but allowing the possibility of different information for different sets of files?
As written, it wouldn't. The file would contain a simple REUSE header that indiscriminately applies to all files in the directory.
I'm more inclined to slowly deprecate DEP5 and replace it with a format that was built for purpose. We're currently kind of co-opting DEP5, which has a lot of features that we don't need, a syntax which is difficult to parse, and some instructions in its specification that contradict the REUSE Specification. Also, generally, the DEP5 specification is a bit of a drag to read.
On the tooling end, replacing DEP5 with something else would get rid of a dependency on `python-debian`. It would also enable people to write REUSE tooling in languages that do not have library support for DEP5.
There's an interesting choice that could be made here, though. Instead of having the configuration be *global*, what if we mixed the best of both worlds? So instead of having the configuration in `.reuse/dep5- replacement.json`, what if we put it in the directories?
This would have one very clear benefit: The closer that the file is to the source, the more detectable it is.
The disadvantage is that scattered configuration can be a pain in the behind.
There are some more design things that need to be figured out:
- The format should probably be able to handle globs ("*", "*.png",
etc.)
- Should the format be able to handle individual files? ("README.rst",
".gitkeep")
- Should the format allow licensing of files that are deeper in the
directory tree? ("**/*.png", "resources/vid/*.mp4")
- Should the format allow "overriding" of existing notices? (e.g., it
contains ".gitignore" even though ".gitignore" already contains a REUSE header. Currently with DEP5, the licensing information is simply combined)
... Probably some more things that I'm forgetting. Maybe another time :)
Yours with kindness, Carmen
REUSE mailing list REUSE@lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/reuse
This mailing list is covered by the FSFE's Code of Conduct. All participants are kindly asked to be excellent to each other: https://fsfe.org/about/codeofconduct