Remove docheaders from all files

[henriquemoody]

I don't see much value on having those headers in the files, and I've seen that some packages (like Doctrine) are moving away from it.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.54%. Comparing base (bf5f6c0) to head (fe97b1d).

Additional details and impacted files

@@            Coverage Diff            @@
##               main    #1583   +/-   ##
=========================================
  Coverage     97.54%   97.54%           
  Complexity      999      999           
=========================================
  Files           211      211           
  Lines          2280     2280           
=========================================
  Hits           2224     2224           
  Misses           56       56           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[alganet]

I would like to keep them, and move to REUSE compliance.

https://reuse.software/spec-3.3/

It's important for things like automated SBOM, especially now in the age of AI.

The reuse command line can replace the docheader tool and automate most of the transition to REUSE compliant headers.

I can personally do that in a separate PR, as I am already used to the tool.

[henriquemoody]

The problem I see with having those copyrights is the same we have with the @author tag (and reason why I remove it in the past): if we want to be more fair, we'd need to add the proper header to all files.

That means lots of files would have your name and mine, some just yours, some just mine, and some just the contributors names. The trouble I find is how much is enough to add someone's name there?

I think it's an overhead, but I'd be happy if you want to take this on.

[alganet]

@henriquemoody

The SPDX-FileCopyrightText tag is related to the main project's license, which is still in my name. We could change that to something like "The Respect Project Team" to be less centered around me. This tar refers to the main terms in which the project is licensed. All we need is my permission (which I can grant since I'm still alive!)

There is also SPDX-FileContributor, which is suitable for adding individual acknowledgements.

Ideally, we should not require permission to add attribution to someone that commited in the past. For example, if we identify that some code came from some people X, we should be able to include that attribution. We would need to get explicit permission to remove attribution or simplify it.

So, the sober position here would be to remove all of our (Alexandre's individual copyrights and Henrique's individual copyrights) and replace with "The Respect Project Team", but keep all other git commiters attributed more explicitly.

For example, if Alan Turing contributed to a validator for Turing machines to our project, that validator would have a header like this:

SPDX-License-Identifier: MIT
SPDX-FileCopyrightText: (c) The Respect Project Team <therespectpanda@gmail.com>
SPDX-FileContributor: Alan Turing <aturing@example.com>

Doing that would be slightly harder than just use the reuse annotate CLI tool, but doable with a few dozen lines of shell script. The reuse annotate and reuse lint could still be used to maintain the headers afterwards.

We never provided guidelines for marking contributions, so we can't say "what is enough". In the lack of those guidelines, we should make a balanced effort to streamline what we can (our names -> "The Respect Project Team" to avoid verbosity) and keep other contributors intact.

The guidelines for new contributions, IMHO, should be "if you changed a file, add SPDX-FileContributor if you want to". Anything other than that is kind of hard to do legally. For example, some projects require contributors to send an email donating the changes to the main team, in order to keep those headers and license info more simple. If we did that, we could replace all headers for a simple "The Respect Project Team" one that is REUSE compliant, but we can't do it for past contributions (unless we contact all the previous contributors individually, or re-implement what they did from scratch).

The SPDX standard guarantees there is a consistency in how we annotate those contributions. If we change something, it's because REUSE made changes to the standard. In a sense, it prevents us from having to make hard decisions about this, instead delegating the responsibility of choosing the annotation format to a standards body.