Allow to configure the mapping of authors to copyright holders

[sschuberth]

Currently, ORT unconditionally uses author information from package meta-data to amend copyright holder information for that package. However, there might be cases where this is undesirable, see the discussion in #4294. As such it would be nice if interpreting authors as copyright holders would be configurable.

Some historic context: Originally, the feature to map authors to copyrights arose from the need to curate (add previously missing) copyright holders. As ORT's curation system can only curate meta-data that is tracked as part of a package, we decided to

1. start tracking the author, and
2. use authors information as copyright holders.

That way, by creating a curations.yml entry that sets authors, copyrights holders can be injected (in addition to copyright holders found by the scanner).

[sschuberth]

As such it would be nice if interpreting authors as copyright holders would be configurable.

A simple idea to address this would be a "mapAuthorsToCopyrights" configuration flag to completely turn the feature on or off. However, that would not work for users who don't want the general mapping, but still need to be able to curate copyright holders.

So another idea would be to add something like an "origin" enum to CopyrightFinding, and be able to configure the author origins which you'd like to map to copyrights. That way you could reject origins "PACKAGE_META_DATA" and "LICENSE_SCANNER", but accept origin "CURATION".

A third idea is to introduce a dedicated "copyright" field into PackageCurationData. That would require to also add a "copyright" field to the Package class, even if no package manager implementation would ever populate it; that field would only ever be populated via curations. That way, we'd also have a clear split between authors and copyrights, and still could (combined with the simple idea from above) optionally map authors to copyrights.

Opinions?

/cc @porsche-rishisaxena, @hyandell

[sschuberth]

Note that it might need to be configurable to which licenses a curated copyright applies.

[nikpete]

@sschuberth I would like to double check on the current ORT behaviour (Copyright / Author) vs To-Be so that we are on the same page:

According to my understanding ORT is functioning the following way when it comes to Copyright holders (see description + Screenshot):

As-IS

1. For example, there is a parent library in the project structure which has a license.txt file with Copyright (c) 2015-2017 Evgeny Poberezkin
2. This parent library has a sub-module where another license.txt file was found with Copyright (c) 2012 Julian Berman
3. ORT detected both license.txt files and merged into one license text combining copyright (c) holder names. This could be due to common SPDX expression i.e. MIT
   Conclusion: The sub-module license information will be merged and is part of the parent license information.

To-Be:
Based on your note / statement my conclusion would be that the copyright (c) holder name(s) of the sub-module won't be merged with the parent anymore....and copyright holders of sub-modules / files can be indicated separately, correct? Or do I mix up things?

Thanks,
Nik

[sschuberth]

ORT detected both license.txt files and merged into one license text combining copyright (c) holder names. This could be due to common SPDX expression i.e. MIT

The "consolidation" of copyrights only happens if the licenses are the same, yes.

Or do I mix up things?

I believe you do mix up things 😀 The mapping (or not) of authors to copyrights has nothing to do with the subsequent consolidation of copyrights to licenses.