Can’t specify license for files in the LICENSES/ folder #410
Comments
|
Ah, you don't need to license your license files according to the REUSE spec:
I hope that clears things up :) |
I’m not sure that I agree. What do you mean by “to license”? The way I read the spec, Copyright and Licensing Information isn’t required for all files. The sentence you quoted explicitly excludes some files from that requirement. The License File requirement, however, is separate. The sentence I quoted doesn’t exclude any files. There probably should be an exclusion for both (I’ve opened an issue in the docs repo: fsfe/reuse-docs#84). While I agree that the spec doesn’t require me to include Copyright and Licensing Information for License Files, the spec doesn’t say that I can’t. The question here is: should reuse-tool allow me to do this, even though the spec doesn’t require it? |
|
Well, I understand your general point, but I'd find it extremely hard to distinguish between the licenses for the actual code files and potential licenses for license texts. Also see this line of the spec:
The benefit of just having license texts for licenses which normal files (ex |
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>
Context
Parts of CC0-1.0’s text are available under CC0-1.0. The rest of its text is licensed under CC-BY-4.0. See:
The spec says,
(“REUSE Specification – Version 3.0” by the Free Software Foundation Europe is licensed under CC BY-SA 4.0)
This means that if I want to use CC0-1.0 for any of the files in my project, then I have to also include CC-BY-4.0.
Problem
When I run
reuse lint, it tells me that CC-BY-4.0 is unused, even though I’m using it forLICENSES/CC0-1.0.txt.Minimum reproduction project.zip
The text was updated successfully, but these errors were encountered: