Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] Clarify authorship and copyright #1920

Open
j-stephan opened this issue Feb 15, 2023 · 10 comments · May be fixed by #2177
Open

[RFC] Clarify authorship and copyright #1920

j-stephan opened this issue Feb 15, 2023 · 10 comments · May be fixed by #2177

Comments

@j-stephan
Copy link
Member

j-stephan commented Feb 15, 2023

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
Copy link
Member

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
Copy link
Member Author

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
Copy link
Member

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
Copy link
Contributor

fwyzard commented Feb 19, 2023

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
Copy link
Member

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
Copy link
Member Author

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
Copy link
Member

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
Copy link
Member

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

@bernhardmgruber
Copy link
Member

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

LLAMA is a mix of 2 and 4.

@j-stephan
Copy link
Member Author

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

@j-stephan j-stephan linked a pull request Sep 26, 2023 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants