[REUSE] [EXTERNAL] Re: Introduce folder.license file

Jeff McAffer jeffmcaffer at github.com
Mon Mar 9 21:10:44 UTC 2020


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 at 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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fsfe.org/pipermail/reuse/attachments/20200309/912b68de/attachment.htm>


More information about the REUSE mailing list