search

fsfe / reuse-docs

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

`.license` file for plain text file #82

Closed maltekliemann closed 3 years ago

maltekliemann commented 3 years ago

My project produces C++ code. I test the project using snapshot testing, where the output of the program is compared to a snapshot saved in a plain text file (C++ header file). This header file may not contain a copyright/license notice.

Unfortunately, the specification states that plain text files MUST contain such a notice and, in particular, may not use a .license file to store the notice. Is there a REUSE-compliant solution for this problem (other than rewriting the test to ignore the first couple of lines of the snapshot, etc.)?

If not, then I suggest:

maltekliemann commented 3 years ago

I made a mistake. In fact, reuse lint is okay with .license files for plain text. Nevertheless, (if you don't mind getting pedantic) the specification is not worded clearly in this regard (https://reuse.software/spec/#copyright-and-licensing-information, emphasis mine):

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.

If a file is not a plain text file or does not permit the inclusion of comments, the comment header that declares the file’s Copyright and Licensing Information SHOULD be in an adjacent file of the same name with the additional extension .license (example: cat.jpg.license if the original file is cat.jpg).

What do you mean by "can contain comments"/"does not permit the inclusion of comments"? A C++ header file can contain comments, it just can't in the context of the project that I'm working on.

silverhook commented 3 years ago

What do you mean by "can contain comments"/"does not permit the inclusion of comments"? A C++ header file can contain comments, it just can't in the context of the project that I'm working on.

So you are saying that in general a C++ header file is plain text and technically can contain comments, but in the case of your project it is not permitted to carry comments? If so, I think the wording in the spec is OK.

Perhaps it should instead say “[…] or is not permitted to include comments” in the passive form. But I’d err on the side of not changing the spec if it works.

maltekliemann commented 3 years ago

So you are saying that in general a C++ header file is plain text and technically can contain comments, but in the case of your project it is not permitted to carry comments? If so, I think the wording in the spec is OK.

Yes, that's the situation that I find myself in. I thought that "does not permit the inclusion of comments" refers to the technical capabilities.

Perhaps it should instead say “[…] or is not permitted to include comments” in the passive form. But I’d err on the side of not changing the spec if it works.

I find the phrasing to be slightly ambiguous (technical capabilities vs project demands), but, I agree, not meddeling with the spec has its own advantages.

silverhook commented 3 years ago

Perhaps it should instead say “[…] or is not permitted to include comments” in the passive form. But I’d err on the side of not changing the spec if it works.

I find the phrasing to be slightly ambiguous (technical capabilities vs project demands), but, I agree, not meddeling with the spec has its own advantages.

Yes. Because the spec should not care whether the cause for the inability of a file to carry plain-text comments is of technical or social nature. As your own example showed should be the case.