[RFC] Clarify authorship and copyright

[j-stephan]

Preface: This issue is not about relicensing alpaka or stripping people / institutions of their (copy)rights. Its purpose is simply to be a clarification of the current legal state.

While working on #1917 I saw that the SPDX specification makes a distinction between copyright and authors. After a longer discussion in yesterday's VC I looked into the relevant legal frameworks for Germany (I believe this works more or less the same for all countries as well as CERN's special law) and arrived at this conclusion:

• An author is always a (human) person. An author can never lose this status or transfer the author rights to someone else (except when the author dies). If multiple people work on the same project they are equal co-authors. By default German law also assigns the copyright to the (co-)authors.
• Copyright is the right to economically exploit a project, i.e. copy / distribute / sell it to third parties.
• 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.

(Sources for the Germanophone crowd: §7, §8, §69b UrhG)

In my understanding, this means that our copyright information at the beginning of each source file is wrong:

/* Copyright 2022 Axel Huebl, Benjamin Worpitz, Erik Zenker, Matthias Werner, René Widera, Bernhard Manfred Gruber,
 *                Jan Stephan, Antonio Di Pilato
 * SPDX-License-Identifier: MPL-2.0
 */

and should be changed to:

/*
 * Copyright 2023 Helmholtz-Zentrum Dresden-Rossendorf e.V.
 * Copyright [year] CERN
 * Copyright [other year] TU Dresden
 * Copyright [another year] Benjamin Worpitz // example for someone who works on alpaka privately
 * Authors: Axel Huebl, Benjamin Worpitz, Erik Zenker, Matthias Werner, René Widera, Bernhard Manfred Gruber,
 *          Jan Stephan, Antonio Di Pilato
 * SPDX-License-Identifier: MPL-2.0
 */

Or, if we want to do this conforming to SPDX:

/*
 * /*
 * SPDX-License-Identifier: MPL-2.0
 * SPDX-FileCopyrightText: 
 *    - 2014 - 2023 Helmholtz-Zentrum Dresden-Rossendorf e.V.
 *    - 2019 - 2023 CERN
 *    - [other institutions / private persons]
 * SPDX-FileContributor: Benjamin Worpitz
 * SPDX-FileContributor: René Widera
 * SPDX-FileContributor: Bernhard Manfred Gruber
 * [and so on]
 */

What do you think? @alpaka-group/alpaka-maintainers

[bernhardmgruber]

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.

[j-stephan]

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.

[BenjaminW3]

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.

[fwyzard]

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).

[bernhardmgruber]

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.

[j-stephan]

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?

[bernhardmgruber]

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.

[psychocoderHPC]

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

[bernhardmgruber]

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

LLAMA is a mix of 2 and 4.

[j-stephan]

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