-
Notifications
You must be signed in to change notification settings - Fork 149
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add option to pay attention to files named COPYING
or LICENSE
#881
Comments
reuse lint
pay attention to files named COPYING
or LICENSE
COPYING
or LICENSE
Thanks for the elaborate suggestion. However, I am afraid we live in two different worlds ;) In your world, software forges such as GitHub and naive license scanners respect the REUSE standard and its LICENSES directory. In my world, however, they don't. This is why the REUSE spec and the tool still assume that projects have a LICENSE or COPYING file so that they "main license" (whatever that is) is displayed and detected. I hope my world will become more like your world very soon which is when we can revisit this proposal. Until then, I am afraid my recommendation for REUSE will be to continue its practice as before to not break valid expectations and force developers into choosing between the REUSE best practices and the other practices and recommendations. |
I didn’t know that the REUSE Spec assumed that projects have a LICENSE or COPYING file. Where does the spec assume that projects have a LICENSE or COPYING file?
Well, if we’re concerned about not breaking valid expectations, then there’s another change that I think should be made. When the tool ignored my
I’m confused. Like I mentioned before, “Personally, I want an option to make the REUSE Tool not ignore files named |
The spec should probably mention that
|
I’ve decided to completely revamp how I do copying information. Going forward, this repo is going to be an exemplar. I’m going to (eventually) make all of my repos declare their copying information similarly to how this one does. My current system for declaring copying information is a big and inconvenient compromise. This new system for declaring copying information is less of a compromise In the past, I had considered complying with the REUSE Spec [1] for all of my repos. I had decided against doing that for several reasons: 1. REUSE requires that I call 🅭🄍 a license. 🅭🄍 is not a license, it’s a public domain dedication [2]. Confusingly, 🅭🄍 contains a public fallback license [3], and I’ve seen at least one person call 🅭🄍 a license to indicate that their work is available under that fallback license [4]. I don’t want to call 🅭🄍 a license because I want to make sure that the work is dedicated to the public domain as much as it possibly can be. 2. The REUSE Tool made it difficult to include proper attribution for 🅭🄍, and the developers of the REUSE Tool didn’t seem interested in making it easier [5]. 3. The REUSE Spec required that all Covered Files that could contain comments did contain comments [6]. Godot allows you to put comments in `.tscn` files, but it will delete them when you save the scene from the editor [7]. This made it really inconvenient to follow the REUSE Spec while working on a Godot project [8]. Those reasons are why I ended up using my current system. Unfortunately, my current system is kind of annoying. For one thing, there’s nothing quite like the REUSE Tool for my current system. I created assert_contains_regex [9] as a stopgap solution. Once I had a version of assert_contains_regex that worked well on Windows, I was going to create a tool for my system that was more comparable to the REUSE Tool. At this point, I still haven’t made assert_contains_regex work well on Windows, and I still haven’t created the tool that would replace it. A big problem with my current system is that it’s not standardized at all. It’s specific to me and only me. Theoretically, someone else could implement it for their projects, but that seems really unlikely. It would be nice if I could use something standardized like REUSE. Then, I wouldn’t have to create my own tools. I’ve been thinking about the three problems that I had with REUSE, and I’ve come up with solutions for all of them: 1. I can write some boilerplate text that makes my intentions clear. I can say that 🅭🄍 is a public domain dedication. I clarify that when I say “SPDX-License-Identifier: CC0-1.0”, I mean “dedicated to the public domain using 🅭🄍.” 2. Now that this annoying loophole [10] has been fixed, I no longer need to provide attribution for 🅭🄍 [11]. 3. Now that this issue has been fixed [12], unstable versions of the REUSE Spec no longer have that requirement. I’m still waiting for a stable release, though. Having solutions to those three problems makes using REUSE a legitimate option, and using REUSE is going to be much less work than maintaining tools for my current system. --- On an unrelated note, this commit creates a file named “copying.md”. Normally, I would create a file named “COPYING.md”, but the REUSE Tool ignores files whose names start with “COPYING” or “LICENSE”. If this feature request [13] gets implemented, then I’ll rename the file to “COPYING.md”. [1]: <https://reuse.software/spec/> [2]: <https://creativecommons.org/faq/#how-do-cc-licenses-operate> [3]: <https://creativecommons.org/publicdomain/zero/1.0/legalcode.en#fallback> [4]: <https://comment.ctrl.blog/discussion/creative-commons-unicode-fallback-font> [5]: <fsfe/reuse-tool#410> [6]: <fsfe/reuse-docs#122> [7]: <https://docs.godotengine.org/en/stable/contributing/development/file_formats/tscn.html#file-structure> [8]: <godotengine/godot-proposals#3509> [9]: <https://pagure.io/assert_contains_regex> [10]: <https://jasonyundt.website/posts/cc0-loophole-annoying-for-2-years.html> [11]: <https://github.com/creativecommons/cc-legal-tools-data/tree/7fe72a9f6c241f6ae8059751793e3471dd4fcebe#copying> [12]: <fsfe/reuse-docs#122 (comment)> [13]: <fsfe/reuse-tool#881>
A future commit will turn this command into a pre-commit hook. I wanted to have a pre-commit hook that forbids files with certain names in order to work around this problem [1]. Once this command gets turned into a pre-commit hook, I’ll use it to forbid files whose names begin with “COPYING” or “LICENSE”. [1]: <fsfe/reuse-tool#881>
I created forbid-paths-that-match in order to workaround a specific problem with the REUSE Tool [1]. That problem is relevant to all repos that use the REUSE Tool, and repo-style-checker makes sure that all repos use the REUSE Tool. [1]: <fsfe/reuse-tool#881>
Closed in #886, kind of. In the end the specification and the tool were changed to say |
The REUSE Tool ignores files whose names start with
LICENSE
orCOPYING
. I tried creating a repo like this one that contains aCOPYING.md
file that just says that the repo is REUSE compliant. When I runreuse lint
, it tells me thatCC0-1.0
is unused despite the fact thatCOPYING.md
containsSPDX-License-Identifier: CC0-1.0
:As far as I know, this is intentional. According to this comment from @mxmehl,
Max is right. The spec says
and
If you had a file in your project named
COPYING
orLICENSE
, and that file contained the text of a license, then it would be OK to ignore the contents of that file. After all, the file doesn’t need to have anSPDX-License-Identifier
or anSPDX-FileCopyrightText
tag because it’s a License File. That being said,reuse lint
should still report an error in this case because there should never be a file namedCOPYING
orLICENSE
that contains the text of a license. All files that contain the text of licenses need to be in theLICENSES/
directory, and they need to be named something other thanCOPYING
orLICENSE
. The spec says:Personally, I want an option to make the REUSE Tool not ignore files named
COPYING
orLICENSE
. Another possibility would be to just make the REUSE Tool just never ignore those files.If we want to keep assuming that those files contain license text, then we could make
reuse lint
give an error whenever it detects a file namedCOPYING
orLICENSE
. I’m personally not in favor of this possibility, but it would be better that what we have at the moment.The text was updated successfully, but these errors were encountered: