Skip to content
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

Closed
Jayman2000 opened this issue Dec 15, 2023 · 4 comments
Closed

Add option to pay attention to files named COPYING or LICENSE #881

Jayman2000 opened this issue Dec 15, 2023 · 4 comments
Labels
enhancement New feature or request pending/close The issues is marked for closing in the near future spec Requires specification change

Comments

@Jayman2000
Copy link
Contributor

Jayman2000 commented Dec 15, 2023

The REUSE Tool ignores files whose names start with LICENSE or COPYING. I tried creating a repo like this one that contains a COPYING.md file that just says that the repo is REUSE compliant. When I run reuse lint, it tells me that CC0-1.0 is unused despite the fact that COPYING.md contains SPDX-License-Identifier: CC0-1.0:

$ cd reuse-ignores-copying
$ cat COPYING.md
<!--
SPDX-License-Identifier: CC0-1.0
SPDX-FileCopyrightText: 2023 Jason Yundt <jason@jasonyundt.email>
-->

# Copying Information

This repo is [REUSE](https://reuse.software) compliant.
$ reuse lint
# UNUSED LICENSES

The following licenses are not used:
* CC0-1.0



# SUMMARY

* Bad licenses: 0
* Deprecated licenses: 0
* Licenses without file extension: 0
* Missing licenses: 0
* Unused licenses: CC0-1.0
* Used licenses: 0
* Read errors: 0
* files with copyright information: 0 / 0
* files with license information: 0 / 0

Unfortunately, your project is not compliant with version 3.0 of the REUSE Specification :-(
$ 

As far as I know, this is intentional. According to this comment from @mxmehl,

Ah, I didn't see the LICENSE.md file. Indeed, it's not checked by the tool because it's considered to contain a license text (which per definition is excluded from the obligation to contain copyright and licensing info).

Max is right. The spec says

  • Covered File --- any file in a Project, except for
    • The License Files.
    • […]

and

Each Covered File MUST have Copyright and Licensing Information associated with
it.

If you had a file in your project named COPYING or LICENSE, 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 an SPDX-License-Identifier or an SPDX-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 named COPYING or LICENSE that contains the text of a license. All files that contain the text of licenses need to be in the LICENSES/ directory, and they need to be named something other than COPYING or LICENSE. The spec says:

Each License File MUST be placed in the LICENSES/ directory in the root of
the Project. The name of the License File MUST be the SPDX License Identifier of the
license followed by an appropriate file extension (example:
LICENSES/GPL-3.0-or-later.txt).


Personally, I want an option to make the REUSE Tool not ignore files named COPYING or LICENSE. 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 named COPYING or LICENSE. I’m personally not in favor of this possibility, but it would be better that what we have at the moment.

@Jayman2000 Jayman2000 changed the title Add option that makes reuse lint pay attention to files named COPYING or LICENSE Add option to pay attention to files named COPYING or LICENSE Dec 15, 2023
@mxmehl
Copy link
Member

mxmehl commented Dec 19, 2023

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.

@mxmehl mxmehl added pending/close The issues is marked for closing in the near future enhancement New feature or request spec Requires specification change labels Dec 19, 2023
@Jayman2000
Copy link
Contributor Author

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 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?

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[…]

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 COPYING.md file, it would have been nice if it had told me. I really wasn’t expecting the tool to do that, and it was kind of frustrating.

[…]and force developers into choosing between the REUSE best practices and the other practices and recommendations.

I’m confused. Like I mentioned before, “Personally, I want an option to make the REUSE Tool not ignore files named COPYING or LICENSE.” How would adding a --dont-ignore-copying-or-license option force developers into choosing between the REUSE best practices and the other practices and recommendations?

@carmenbianca
Copy link
Member

carmenbianca commented Jan 2, 2024

The spec should probably mention that COPYING and LICENSE files are ignored completely by the tool, unless we want to undo that functionality. I'll create an issue for it in fsfe/reuse-docs. The reason these files are ignored is to allow people to stick to some old traditions while also adopting REUSE on top of them. And because the REUSE spec is not itself compatible with the putting licence texts in COPYING or LICENSE (and will never be compatible with that), we just ignore their contents to allow the two systems to live side-by-side.

COPYING.md and LICENSE.md (with the extensions) are not special files in any case.

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>
Jayman2000 added a commit to Jayman2000/jasons-pre-commit-hooks that referenced this issue Jan 10, 2024
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>
Jayman2000 added a commit to Jayman2000/jasons-pre-commit-hooks that referenced this issue Feb 5, 2024
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>
@carmenbianca
Copy link
Member

Closed in #886, kind of. In the end the specification and the tool were changed to say COPYING[.ext] and LICENSE[.ext] are ignored.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request pending/close The issues is marked for closing in the near future spec Requires specification change
Projects
None yet
Development

No branches or pull requests

3 participants