Skip to content
This repository has been archived by the owner on May 27, 2024. It is now read-only.

Spec’s comment header rule isn’t followed or enforced #122

Closed
Jayman2000 opened this issue Feb 1, 2023 · 4 comments · Fixed by #123
Closed

Spec’s comment header rule isn’t followed or enforced #122

Jayman2000 opened this issue Feb 1, 2023 · 4 comments · Fixed by #123

Comments

@Jayman2000
Copy link
Contributor

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:

@carmenbianca
Copy link
Member

Soft agree. Thanks for this issue.

@linozen
Copy link
Member

linozen commented Feb 2, 2023

I also agree. The change proposed by @Jayman2000 should probably make it into the next version of the spec.

@silverhook
Copy link
Collaborator

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.

@Jayman2000
Copy link
Contributor Author

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.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants