reuse spdx should exclude the tag from FileCopyrightText

[Tachi107]

(Mentioned in #59 (comment), but opening as a separate issue because the request is not the same)

The REUSE spec states that

The SPDX-FileCopyrightText tag MUST be followed by a copyright notice.

Instead of the SPDX-FileCopyrightText tag, the symbol ©, or the word Copyright MAY be used, in which case a colon is not needed.

As SPDX-FileCopyrightText, ©, and Copyright are followed by the copyright notice, it means that they are not part of the notice itself, and shouldn't be part of the outputted FileCopyrightText.

In #59 (comment), @carmenbianca mentioned that "It'd be fairly trivial to only take everything AFTER the copyright tag".

Of course this is only my opinion, and I may be failing to see why including the various tags is important and not superfluous.

[mxmehl]

Makes sense. To extend, Carmen was referring to everything after the matched copyright string (Copyright, C-symbol, SPDX etc), but that it's harder for just SPDX-FileCopyrightText. But it's certainly something that should be fixed in the long run.

[mxmehl]

@silverhook could we please ask for your legal opinion here?

In today's call we were unsure what role SPDX-FileCopyrightText: has. Is it equally important as, say, Copyright © ?

Asked the other way round: If we removed SPDX-FileCopyrightText from the reuse spdx output in the FileCopyrightText fields, shouldn't we also remove e.g. Copyright (c) or ©?

Our gut feeling, also stemmed from experiences with how sensible companies treat these copyright lines, was that the SPDX tag does not count to the actual copyright statement but just introduces it, unlike the "traditional" copyright statements.

Depending on your assessment we'd treat the SPDX as a special case here and remove it, or would try to find a more general solution.

[silverhook]

@mxmehl , you mean from the theoretical copyright law PoV or from the practical compliance PoV?

From the copyright law PoV, as I wrote in my blog post, the only copyright notice formality that can be found in several copyright laws in the world is the actual © sign. Some (esp. English speaking) jurisdictions will also allow for the word “Copyright”, but others won’t. Due to the Berne convention though, everyone recognises the © sign.

From the practical compliance PoV, the SPDX-FileCopyrightText in the file should be translated into FileCopyrightText into the SPDX Document – with the exception of SPDX-LicenseIdentifier the way SPDX “file tags” work according to the SPDX spec is that you just find an SPDX tag, prefix it with SPDX- and you can use them in a source code file then.

Everything after the tag is the copyright notice and should be kept intact by a tool.

The SPDX Document’s curator can (later) decide whether to normalise, fix typos or otherwise change the copyright texts, if they feel so (e.g. like through FOSSology, OpossumUI or other auditing tool), but I would argue that should not be automated. Some people take the “keep the copyright notices intact” requirement very (maybe even too) seriously.

[Tachi107]

Hi @silverhook, thanks for your comment (and for linking your article, it's really interesting!)

Everything after the tag is the copyright notice and should be kept intact by a tool.

My point is that the REUSE spec states that © and Copyright, when used by themselves, are not part of the copyright notice, and have the same function as behaviour as the SPDX-FileCopyrightText tag - in other words, they are tags too (that's my interpretation of the spec).

To make my point clearer, here's an example of what reuse spdx should output based on my interpretation of the spec:

1. SPDX-FileCopyrightText: 2022 Andrea Pappacoda <me@host.org> → FileCopyrightText: 2022 Andrea Pappacoda <me@host.org>

2. SPDX-FileCopyrightText: © 2022 Andrea Pappacoda <me@host.org> → FileCopyrightText: © 2022 Andrea Pappacoda <me@host.org>

3. © 2022 Andrea Pappacoda <me@host.org> → FileCopyrightText: 2022 Andrea Pappacoda <me@host.org>

4. Copyright 2022 Andrea Pappacoda <me@host.org> → FileCopyrightText: 2022 Andrea Pappacoda <me@host.org>

The SPDX-FileCopyrightText tag should never be part of the copyright notice, and everything after it should always be copied as-is in the output - this means that a © sign after the tag will be preserved.

The last two examples show how © and Copyright, when used without any SPDX-FileCopyrightText: before them, are aliases to SPDX-FileCopyrightText: itself, and thus shouldn't be copied to the reuse spdx output.

While I think that the behaviour of point 1 and 2 is pretty uncontroversial, I can see how we could discuss whether or not point 3 and 4 represent the correct thing to do or not.

If we want to preserve © and Copyright when used without the SPDX-FileCopyrightText tag I think that the spec should be clarified a bit:

diff --git a/spec.md b/spec.md
index 94b2dfe..52d4b4b 100644
--- a/spec.md
+++ b/spec.md
@@ -118,7 +118,7 @@ a text value, and terminated by a newline.
 The `SPDX-FileCopyrightText` tag MUST be followed by a copyright notice.
 
 Instead of the `SPDX-FileCopyrightText` tag, the symbol `©`, or the word `Copyright` MAY
-be used, in which case a colon is not needed.
+be used, in which case a colon is not needed, and they'll be part of the notice too.
 
 The `SPDX-License-Identifier` tag MUST be followed by a valid SPDX License
 Expression describing the licensing of the file (example:

(the diff above is just an example, the wording could be much better)

[silverhook]

I agree with @Tachi107 , if we’re to keep © and Copyright as valid alternative tags, they should be treated as copyright statements, not just tags.

That being said, I think it’s time we deprecate (i.e. mark as such in spec and let reuse tool produce warnings) any option that is not SPDX-FileCopyrightText

The reason for keeping the two as valid “tag” alternatives was to ease the adoption for projects that already have their own copyright notices and did not want to change them. I think it’s time we can be a bit more strict when it comes to best practices. Both SPDX and REUSE have gotten quite some traction by now. And if anyone really can (or will) not use SPDX-FileCopyrightText, we can still let keep those deprecated options as a legacy support for some time.