As stated multiple times, I am already annoyed by having to keep a single line of authors with a year up-to-date. I would prefer to rely solely on git for tracking authorship. As also discussed multiple times, other team members prefer to have names in the file headers to attribute people not writing papers and to guard against copying files from alpaka without the git history. I understand these concerns, so let's keep them.

However, I am strongly against complicating the situation further, which both of your suggestions do.

As also discussed multiple times, other team members prefer to have names in the file headers to attribute people not writing papers and to guard against copying files from alpaka without the git history. I understand these concerns, so let's keep them.

Which is what both suggestions do.

However, I am strongly against complicating the situation further, which both of your suggestions do.

The current situation is not reflecting the legal reality. This is why I opened this issue.

Personally I would vote for getting rid of those headers completely.
They do not prevent anyone from using the code against your intention. A rogue developer may simply remove or replace the license header.
A single file in the repository stating the license should be enough.
Everything you need for claiming your authorship and the copyright is stored within the git repository. In case of a copyright infringement, the code would have to be compared across the whole git history anyways.

I understand that this is not yet state of the art...

Therefore I am with @bernhardmgruber. We should not make it even more complex.

In the case of employed software developers, German law makes an exception to the first point: The copyright is automatically transferred to the employer unless the contract explicitly states something else.

This is only strictly true if the work has been done during working hours for an employer assigned project. There is some grey zone when you do changes outside of office hours even when related to your work projects or for non-work items during office hours.
There are also special rules when the employee is a contractor or is officially allowed to have a second business.

This is only strictly true if the work has been done during working hours for an employer assigned project. There is some grey zone when you do changes outside of office hours even when related to your work projects or for non-work items during office hours.
There are also special rules when the employee is a contractor or is officially allowed to have a second business.

For what is worth, CERN's contract states that it owns everything I write, even outside working hours, on vacation, etc. (no comment).

I found that article useful. It argues for:

SPDX-FileCopyrightText: © {$year_of_file_creation} {$name_of_copyright_holder} <{$contact}>

SPDX-License-Identifier: {$SPDX_license_name}

(I would skip the empty line)

I also really liked the argument against bumping the year in the copyright notice every time a file is touched or when a new year starts.

IMO we can leave out the year entirely. I'm basing this issue on the REUSE recommendations by the Free Software Foundation Europe. Quote:

Which years do I include in the copyright statement?

Generally, there are four options for you to choose:

1. The year of initial publication.
2. The year of the latest publication.
3. All years of publications, either as range (e.g., 2017-2019) or as separate entries (e.g., 2017, 2018, 2019).
4. Do not include any year.

Which option you choose is ultimately up to you.

So maybe we can agree on either option 1 or 4?

So maybe we can agree on either option 1 or 4?

I don't care much, because I don't bump the year when I touch a file. But 4 sounds appealing since it's the simplest.

In all other projects, we use option 3 with the range.

In all other projects, we use option 3 with the range.

LLAMA is a mix of 2 and 4.

In alpaka we also gradually moved to option 2 over the past years. Personally I'm in favour of abandoning the year entirely.