search

fsfe / reuse-docs

REUSE recommendations, tutorials, FAQ and specification
https://reuse.software
19 stars 20 forks source link

Requirements apply to different sets of files #84

Closed Jayman2000 closed 2 years ago

Jayman2000 commented 2 years ago

The spec says,

A Project MUST include a License File for every license under which files in the Project are licensed.

This requirement applies to all flies in a Project. The spec also says,

Each file in the Project MUST have Copyright and Licensing Information associated with it, except the following files:

  • The License Files.
  • The files belonging to the Project’s version control system (example: .git/).
  • The files ignored by the version control system (example: Files listed in .gitignore).
  • The files in the .reuse/ directory in the root of the Project. This directory MUST contain only files relevant for the operation of the REUSE Tool.

This requirement applies to only some of the files in a Project.

This means that I can create a file that needs to have a License File, but doesn’t need to have Copyright and Licensing Information. This doesn’t seem intentional. It also makes it difficult for tools to determine if a License File is truly unused.

Attribution for the the quotes: “REUSE Specification – Version 3.0” by the Free Software Foundation Europe is licensed under CC BY-SA 4.0.

silverhook commented 2 years ago

A not-yet-existing .reuse/dep5 cannot be protected by copyright and therefore cannot be licensed.

The spec is released to the public under a license, yes.

A later file that conforms to the spec is not the spec. The FSFE does not hold copyright in a file it did not create, just because it is following a spec (Debian’s spec in DEP5’s case, at that). And BTW, I would argue that a DEP5 file is very likely not copyrightable at all.

This is a non-issue.

Jayman2000 commented 2 years ago

I don’t think that you got the message that I was trying to send, and I don’t understand what your saying. I was using .reuse/dep5 as an example. Would it change anything if I had mentioned one of the other types of files that don’t need Copyright and Licensing Information associated with it?

A not-yet-existing .reuse/dep5 cannot be protected by copyright and therefore cannot be licensed.

I don’t understand why you said this, but I agree with it. Specifically, how is a not-yet-existing .reuse/dep5 relevant to this issue?

A later file that conforms to the spec is not the spec.

What do you mean by “a later file”?

The FSFE does not hold copyright in a file it did not create, just because it is following a spec (Debian’s spec in DEP5’s case, at that).

I don’t understand why you said this, but I agree with it.

And BTW, I would argue that a DEP5 file is very likely not copyrightable at all.

OK, so let me rephrase what I think the issue is without mentioning a DEP5 file:

Let’s say that I have a project that automatically downloads copyrightable images as part of its build process. I puts those images in .gitignore. Since those images are a part of my project, I have to include a License File for each of their licenses. Since those images are ignored by Git, I don’t have to associate Copyright and Licensing Information with them.

Let’s say that I decide to include a License File for each license that the images are under, but not include Copyright and Licensing Information for those files. If I did that, then it would be difficult for a piece of software to determine that I’m compliant. If I did that then I wouldn’t be breaking the letter of the REUSE Spec, but I would be breaking the spirit of it. The spec says “[t]he goal of the specification is to have unambiguous, human- and machine-readable copyright and licensing information for each individual file in a project.” Including License Files that potentially don’t get used by any Copyright and Licensing Information seems like a way to introduce ambiguity. I also think that I would be breaking the spirit (but not the letter) of this sentence “A Project MUST NOT include License Files for licenses under which none of the files in the Project are licensed.”

silverhook commented 2 years ago

It does indeed seem there was a misunderstanding. I apologise for my part.

Perhaps it’s best to start anew and try to understand each other better. Reopening the issue until we get to the bottom of this.

What I understood was that you are implying that since REUSE spec is copyright by FSFE and contributors (which it is), and that it is released under CC-BY-SA-4.0 (which it also is), that therefore and .reuse/dep5 file would need to be under that license (and © FSFE?) as well, unless it is explicitly excluded in the spec. That is what I say is not true.

If I understand you correctly now, we are talking about two states where we are checking for REUSE compliance:

  1. in Git repo
  2. after build

In that case it makes sense to test the package twice:

  1. the Git repo to make sure anyone cloning the whole code base or copying parts of the source code has all the – at this stage the images are not part of the source code
  2. again during/after the build in order to make sure that the final product in its executable(?) form is also compliant – at this stage the images (and other dependencies) are pulled in

REUSE mainly focuses on 1., but can be used (as a separate step) also for 2..

Finally, looking at your pull request in #85 though, it seems what you mean is that the requirement to include licenses for files and the requirement to include license/copyright info for all files do not apply to the same files always. I.e. that one applies to more files than the other.

If that’s the case, that is not the intention, and you may have indeed found a better way to describe it. It would indeed be weird if some files needed to have a license text included, but not be identified that that license applies to them.

In this case, I think we really should look into it and #85 is a good start (perhaps already a solution).

Jayman2000 commented 2 years ago

It does indeed seem there was a misunderstanding. I apologise for my part.

Perhaps it’s best to start anew and try to understand each other better. Reopening the issue until we get to the bottom of this.

Thank you. I apologize for not explaining the issue more clearly in my original post. I should have explained it more thoroughly, but I’ve been filing a lot of issues (with various different projects) recently, and I was getting tired of writing and proofreading.

What I understood was that you are implying that since REUSE spec is copyright by FSFE and contributors (which it is), and that it is released under CC-BY-SA-4.0 (which it also is), that therefore and .reuse/dep5 file would need to be under that license (and © FSFE?) as well, unless it is explicitly excluded in the spec. That is what I say is not true.

I think part of the confusion came from the fact that I wrote

(“REUSE Specification – Version 3.0” by the Free Software Foundation Europe is licensed under CC BY-SA 4.0)

It’s not really normal for people to include something like that in an issue (you guys definitely know who created REUSE). Here’s why I did it: specifications are valuable. For example, the ISO charges 198 CHF for the C17 specification. I wouldn’t say that the REUSE Spec is that valuable, but it’s definitely worth something. Despite that, the FSFE gives away the spec for free! The only thing they ask for in return is that you follow the terms of CC BY-SA 4.0. From my perspective, this is very generous, so of course I’m going to uphold my end of the bargain!

Since I was sharing part of the spec, I decided to follow CC’s best practices for attribution. It possible that I don’t legally have to provide attribution in this scenario, but I did it anyway because I value the spec and want to respect the authors’ wishes.

That being said, it is kind of a pedantic thing to do. In the future, should I continue to provide attribution for small quotes like that?

If I understand you correctly now, we are talking about two states where we are checking for REUSE compliance:

1. in Git repo

2. after build

In that case it makes sense to test the package twice:

1. the Git repo to make sure anyone cloning the whole code base or copying parts of the source code has all the – at this stage the images are not part of the source code

2. again during/after the build in order to make sure that the final product in its executable(?) form is also compliant – at this stage the images (and other dependencies) are pulled in

REUSE mainly focuses on 1., but can be used (as a separate step) also for 2..

Finally, looking at your pull request in #85 though, it seems what you mean is that the requirement to include licenses for files and the requirement to include license/copyright info for all files do not apply to the same files always. I.e. that one applies to more files than the other.

If that’s the case, that is not the intention, and you may have indeed found a better way to describe it. It would indeed be weird if some files needed to have a license text included, but not be identified that that license applies to them.

In this case, I think we really should look into it and #85 is a good start (perhaps already a solution).

You understand me correctly now.

Jayman2000 commented 2 years ago

I just reworded this issue’s OP, the PR, and one of the PR’s commits. Hopefully, it will make my message clearer.

silverhook commented 2 years ago

Great that we’re on the same page now. I can totally relate with issue fatigue :)

As for mentioning the license etc. You do not need the license for a short quote – the right to citation is granted to you already by copyright law. As long as it’s clear (enough for a random human) where the original came from it’s fine.

As said in my previous comment and the PR, this sounds like an improvement (BTW, good catch!), but would really like to hear also from others (at least @mxmehl and @carmenbianca) about their thoughts as well.