This repository has been archived by the owner on May 27, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 20
Spec’s comment header rule isn’t followed or enforced #122
Comments
Soft agree. Thanks for this issue. |
I also agree. The change proposed by @Jayman2000 should probably make it into the next version of the spec. |
Personally, as stated in #82 , I think the Spec is OK, but not perfect in that regard. If we change it, I’d still prefer if the language hinted at a strong preference to having the headers in the file comments. |
I agree. I feel like, based on RFC 2119, replacing “MUST” with “SHOULD” would indicate a strong preference to having the headers in the file comments. What do you think? Is just replacing “MUST” with “SHOULD” enough, or should additional language be added? |
Jayman2000
added a commit
to Jayman2000/reuse-docs-pr
that referenced
this issue
Feb 16, 2023
Dave Winer’s Rules for standards-makers says “If practice deviates from the spec, change the spec” [1]. If a spec says to do one thing but everyone does something else, then that rule in the spec is more of a distraction then anything else. Before this change, the REUSE Spec said “To implement this method, each Commentable File MUST contain comments at the top of the file (comment header) that declare that file's Copyright and Licensing Information.” As far as I know, there’s no piece of software that actually enforces that requirement. For example, try running “reuse lint” on this repository: <https://github.com/Jayman2000/reuse-compliance-test>. The REUSE Tool will tell you that you’re compliant with the REUSE Spec, even though there’s a .py.license file (The Python file itself could have just contained a comment header). This change aligns the REUSE Spec with actual practice by making this requirement a SHOULD instead of a MUST. For the avoidance of doubt, this change also explicitly says that “.license files MAY be used with Commentable Files”. The phrase “but it is still RECOMMENDED that comment headers be put inside Commentable Files” was inspired by this comment: <fsfe#122 (comment)> Fixes fsfe#122. [1]: <http://scripting.com/2017/05/09/rulesForStandardsmakers.html>
mxmehl
pushed a commit
to Jayman2000/reuse-docs-pr
that referenced
this issue
Mar 6, 2023
Dave Winer’s Rules for standards-makers says “If practice deviates from the spec, change the spec” [1]. If a spec says to do one thing but everyone does something else, then that rule in the spec is more of a distraction then anything else. Before this change, the REUSE Spec said “To implement this method, each Commentable File MUST contain comments at the top of the file (comment header) that declare that file's Copyright and Licensing Information.” As far as I know, there’s no piece of software that actually enforces that requirement. For example, try running “reuse lint” on this repository: <https://github.com/Jayman2000/reuse-compliance-test>. The REUSE Tool will tell you that you’re compliant with the REUSE Spec, even though there’s a .py.license file (The Python file itself could have just contained a comment header). This change aligns the REUSE Spec with actual practice by making this requirement a SHOULD instead of a MUST. For the avoidance of doubt, this change also explicitly says that “.license files MAY be used with Commentable Files”. The phrase “but it is still RECOMMENDED that comment headers be put inside Commentable Files” was inspired by this comment: <fsfe#122 (comment)> Fixes fsfe#122. [1]: <http://scripting.com/2017/05/09/rulesForStandardsmakers.html>
Jayman2000
added a commit
to Jayman2000/jasons-pre-commit-hooks
that referenced
this issue
Jan 10, 2024
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>
carmenbianca
pushed a commit
to carmenbianca/reuse-website
that referenced
this issue
May 21, 2024
Dave Winer’s Rules for standards-makers says “If practice deviates from the spec, change the spec” [1]. If a spec says to do one thing but everyone does something else, then that rule in the spec is more of a distraction then anything else. Before this change, the REUSE Spec said “To implement this method, each Commentable File MUST contain comments at the top of the file (comment header) that declare that file's Copyright and Licensing Information.” As far as I know, there’s no piece of software that actually enforces that requirement. For example, try running “reuse lint” on this repository: <https://github.com/Jayman2000/reuse-compliance-test>. The REUSE Tool will tell you that you’re compliant with the REUSE Spec, even though there’s a .py.license file (The Python file itself could have just contained a comment header). This change aligns the REUSE Spec with actual practice by making this requirement a SHOULD instead of a MUST. For the avoidance of doubt, this change also explicitly says that “.license files MAY be used with Commentable Files”. The phrase “but it is still RECOMMENDED that comment headers be put inside Commentable Files” was inspired by this comment: <fsfe/reuse-docs#122 (comment)> Fixes #122. [1]: <http://scripting.com/2017/05/09/rulesForStandardsmakers.html> Signed-off-by: Carmen Bianca BAKKER <carmenbianca@fsfe.org>
carmenbianca
pushed a commit
to carmenbianca/reuse-website
that referenced
this issue
May 21, 2024
Dave Winer’s Rules for standards-makers says “If practice deviates from the spec, change the spec” [1]. If a spec says to do one thing but everyone does something else, then that rule in the spec is more of a distraction then anything else. Before this change, the REUSE Spec said “To implement this method, each Commentable File MUST contain comments at the top of the file (comment header) that declare that file's Copyright and Licensing Information.” As far as I know, there’s no piece of software that actually enforces that requirement. For example, try running “reuse lint” on this repository: <https://github.com/Jayman2000/reuse-compliance-test>. The REUSE Tool will tell you that you’re compliant with the REUSE Spec, even though there’s a .py.license file (The Python file itself could have just contained a comment header). This change aligns the REUSE Spec with actual practice by making this requirement a SHOULD instead of a MUST. For the avoidance of doubt, this change also explicitly says that “.license files MAY be used with Commentable Files”. The phrase “but it is still RECOMMENDED that comment headers be put inside Commentable Files” was inspired by this comment: <fsfe/reuse-docs#122 (comment)> Fixes #122. [1]: <http://scripting.com/2017/05/09/rulesForStandardsmakers.html> Signed-off-by: Carmen Bianca BAKKER <carmenbianca@fsfe.org>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Dave Winer’s Rules for standards-makers says “If practice deviates from the spec, change the spec”. If a spec says to do one thing but everyone does something else, then that rule in the spec is more of a distraction then anything else.
The REUSE Spec says “To implement this method, each plain text file that can contain comments MUST contain comments at the top of the file (comment header) that declare that file’s Copyright and Licensing Information.” As far as I know, there’s no piece of software that actually enforces that requirement.
Try running
reuse lint
on this repository. The REUSE Tool will tell you that you’re compliant with the REUSE Spec, even though there’s a.py.license
file (The Python file itself could have just contained a comment header).The requirement should be changed to match the way people actually implement REUSE. The word “MUST” should be changed to “SHOULD”, and the spec should clarify that you MAY use a
.license
file with plain text files that can contain comments.Alternatively, the RUSE Tool could be updated to give an error if it detects that a plain text file can contain comments but doesn’t contain a license header. I have two concerns with that approach:
.license
file.The text was updated successfully, but these errors were encountered: