add option for (C) and (c) copyright strings

[vladh]

"Copyright" is English-specific, while the copyright symbol can be difficult to type. These are good reasons to use (C) or (c), and I've seen many projects use these. This pull request adds the option of using either string in place of ©.

The corresponding reuse-tool PR is here: https://github.com/fsfe/reuse-tool/pull/563

[silverhook]

TBH, I’d prefer the other direction and simply remove © and Copyright in favour of just SPDX-FileCopyrightText. You can have whatever after the SPDX tag anyway.

[mxmehl]

I am also not entirely convinced that we need to support all sorts of copyright styles. And I don't really buy the English-specific argument, as we mandate the use of SPDX-License-Identifier, a very English expression without the possibility to localise.

Could you please share some real-world examples where this is used?

I'd also have some technical concerns that I will post in the tool issue.

[silverhook]

To clarify my point, I have “nothing” against (c) or (C), but I think all such copyright notices should simply be part of the SPDX tag, as such:

SPDX-FileCopyrightText: © 2022 me
SPDX-FileCopyrightText: (c) 2022 you
SPDX-FileCopyrightText: (C) 2022 her
SPDX-FileCopyrightText: 2022 that other guy
SPDX-FileCopyrightText: Copyright MMXXII Cato

That way everyone can use whichever style they prefer after the tag. It also makes grepping for copyright notices much easier.

[vladh]

Could you please share some real-world examples where this is used?

Do you just mean examples where the (C) or (c) style is used? I think these are plentiful enough: git, the Linux kernel, the Hare programming language, the Ruby programming language…

To clarify my point, I have “nothing” against (c) or (C), but I think all such copyright notices should simply be part of the SPDX tag, as such:

I see what you mean. I believe the most common ways of writing the copyright line, which (c) and (C) are absolutely included in, should be allowed — whether that is with or without the SPDX-FileCopyrightText header is a decision I gladly leave to the maintainers. I think always using the header for consistency makes sense.

And I don't really buy the English-specific argument, as we mandate the use of SPDX-License-Identifier, a very English expression without the possibility to localise.

The page linked by @silverhook expresses what I meant to say better than I could.

[mxmehl]

Could you please share some real-world examples where this is used?

Do you just mean examples where the (C) or (c) style is used? I think these are plentiful enough: git, the Linux kernel, the Hare programming language, the Ruby programming language…

Thanks. Most of them use Copyright (C) which is already supported by the tool (Copyright (C) <year> <statement>). The Hare language would match your request though.

To clarify my point, I have “nothing” against (c) or (C), but I think all such copyright notices should simply be part of the SPDX tag, as such:

I see what you mean. I believe the most common ways of writing the copyright line, which (c) and (C) are absolutely included in, should be allowed — whether that is with or without the SPDX-FileCopyrightText header is a decision I gladly leave to the maintainers. I think always using the header for consistency makes sense.

Again, Copyright (c) would already be supported. I think we're speaking about just (C) <year> <statement>, right?

[silverhook]

SPDX-FileCopyrightText: © 2022 me
SPDX-FileCopyrightText: (c) 2022 you
SPDX-FileCopyrightText: (C) 2022 her
SPDX-FileCopyrightText: 2022 that other guy
SPDX-FileCopyrightText: Copyright MMXXII Cato

To clarify some more, all of the above is already in line with current REUSE spec, since they all use the SPDX tag.

[vladh]

Again, Copyright (c) would already be supported. I think we're speaking about just (C) <year> <statement>, right?

Right, yes, sorry — I confused myself by looking through the list of supported formats too much.

For clarity, I will call this “the © form”:

// © 2020 Alice

and this “the (C) form”:

// (C) 2020 Alice
// (c) 2020 Alice

My bigger point is that all these forms are basically equivalent. I also claim (despite my faulty evidence) that all of these forms are common. If the © form is allowed, then the (C) form should be allowed as well.

However, the current status quo is a bit confusing: if the © form is allowed, but not the (C) form, it might make more sense to mandate the usage of SPDX-FileCopyrightText and remove support for the © form, allowing only the following:

SPDX-FileCopyrightText: © 2020 Alice
SPDX-FileCopyrightText: (C) 2020 Alice
SPDX-FileCopyrightText: (c) 2020 Alice

Does that make sense?

[silverhook]

However, the current status quo is a bit confusing: if the © form is allowed, but not the (C) form, it might make more sense to mandate the usage of SPDX-FileCopyrightText and remove support for the © form, allowing only the following:

SPDX-FileCopyrightText: © 2020 Alice
SPDX-FileCopyrightText: (C) 2020 Alice
SPDX-FileCopyrightText: (c) 2020 Alice

Does that make sense?

I agree with this ;)

[carmenbianca]

I want to agree with you @silverhook, but I think that mandating the SPDX tag is just a smidge too exotic to help drive adoption :sweat_smile:

[silverhook]

We already mandate the SPDX tag for the license, so it would make it more consistent ¯\_(ツ)_/¯

BTW, the option to use Copyright etc. was in the early days of REUSE thought as an exception to give pre-existing projects a leeway so they could more easily convert to REUSE without needing to care about the copyright statements they already use, and as such help speed up the adoption.

As such, maybe it would be time to explicitly put in the spec (or at least faq/instructions) that the SPDX tag is much preferred, but for legacy code it’s OK (even though undesired) to use the other means.

[mxmehl]

Yes, making our preference clear would be fine with me, but certainly not mandating its use. There are too many projects that still prefer the traditional styles, both for new projects and existing ones.

[silverhook]

@vladh, I realise this discussion changed in the opposite direction from what you initially asked for, but is that something that works for you, or would you still need to add the two c’s?

[vladh]

@silverhook I will try to use SPDX-FileCopyrightText in my projects to avoid this issue. However, I do still think that, if // © 2020 Alice is supported, // (c) 2020 Alice should be too.

[linozen]

As discussed in our coordination meeting this would probably lead to too many false positives.