Hi Patrick,

Thanks for your perspective!
But do you really want to break (German) laws, because the Geeko Foundation is not ready?

er, no? that wasn't my point - my point was that it depends you have the agreements that one might have with an employer. If you are employed by SUSE, or any other company) it is highly likely that your contract contains a clause that assigns or co-assigns copyright of any works to them.

I could be wrong though.

Björn has referenced the same as I have learned in AMOS (Agile Methods & Open Source) at the university.
There are SPDX headers available. That has been established as a standard for open source projects. This is a good example[0], how a good Copyright can look like:
# Copyright [year file created] - [last year file modified], [project founder] and the [project name] contributors
# SPDX-License-Identifier: [SPDX license expression]

Alternatively we can use something equal to that (based on our Commits): 
SPDXVersion: SPDX-2.1
DataLicense: CC0-1.0
PackageName: Foo
PackageOriginator: David A. Wheeler
PackageHomePage: https://github.com/david-a-wheeler/spdx-tutorial/
PackageLicenseDeclared: MIT

That is matching also the requirements of the German Urheberrechtgesetzes. But I have to agree, that OBS should not remove the names of the Authors.

And no Blockchain can help here. 

If required, I can translate also the special law to English for you. 

I am also surprised about SUSE LLC in the Copyright instead of SUSE Software Solutions GmbH. I know SUSE as a (former) German company.

Best regards,
Sarah

I just had a thought. If it's only the spec files in question, if could be argued that they are essential for the smooth build of a SUSE/openSUSE solution, and therefore ONLY the spec file is covered? After all, the SUSE header does say:

# All modifications and additions to the file contributed by third parties
# remain the property of their copyright owners, unless otherwise agreed
# upon.

Thoughts?

[0] https://github.com/david-a-wheeler/spdx-tutorial/blob/master/README.md

Gesendet: Freitag, 27. Dezember 2024 um 23:20
Von: "Christian Boltz" <opensuse@cboltz.de>
An: project@lists.opensuse.org
Betreff: Re: spec file copyright headers

Hello,

Am Freitag, 27. Dezember 2024, 17:54 schrieb Patrick Fitzgerald:

On 23/12/2024 11:21, Dominik George wrote:

Also keep in mind that copyright assignment to a company, or
replacing copyright holders with a company name, is outright
illegal if the original author is a German citizen.

I doubt that "outright illegal" is true.. It depends on the agreements
made between the original author and others - including companies.
For example if you are employed by a company then you may need to
check your employment contract - it may stipulated there that
copyrighted works are automatically assigned. (Look to any music
company to see that kind of behaviour.)

Sorry to disappoint you, but it's not that easy - different countries  
have different copyright laws.

The german Urheberrecht (roughly translated: author's right or creator's 
right) has exactly one way to transfer the Urheberrecht. Sorry if it 
sounds harsh (and it's not meant personal ;-)  - you have to die. 

See https://en.wikipedia.org/wiki/Copyright_law_of_Germany (especially 
the "Transfer" section) for a more verbose version (the german wikipedia 
page is more detailed, but the english one is probably good enough to  
get an overview).

You can of course license your work to someone else, including an 
exclusive license, for example for your employer. However, even with an 
exclusive license, some rights remain with the original author.

A company/organisation possesses, legally speaking, the same rights as
a person; they can be taxed, sued and bankrupted, so they can hold
patents and copyrights.

Yes, but - as I understand it - a company can NOT hold the german 
Urheberrecht because that's bound to a person (or that person's 
inheritor).

Obviously a macro assigning a copyright to a third party is...
questionable, 

I'm quite sure copyright laws around the world have stronger words for 
that. (No, I did not read these laws, and IANAL.)

Needless to say that the german Urheberrecht (and probably also 
international copyright laws) contain some penalties for copyright 
violations - for some cases they even offer a nice place in a jail.

unless there are is an agreement in place. (ie a
checkbox on every build "by using OBS you agree to SUSE Inc being
joint copyright holder")

That would be a CLA (Contributor License Agreement), and lots of 
companies have been bashed for forcing contributors to sign it.
Basically the only thing CLAs are good for is to scare away possible 
contributors.

That said - (luckily) we don't have such a CLA checkbox in OBS, which  
means SUSE has no right to add its copyright on packages no SUSE 
employee ever touched.


To make things even worse:

IIRC [1] the diff shown during   osc commit   does not show the addition 
or update of the SUSE copyright. Instead, this gets done behind my back. 
Still, "of course" if I look at the version history in OBS, it looks 
like it was part of my commit.

Alternatively, moving from overwrite-able text files to recording
copyright ownership, transfers and additions in a global public ledger
makes sense. Just don't call it blockchain. ;)

This is a "solution" for a totally different problem - for a problem we 
don't have.

It's not even a solution for the "partially accepted SR" (aka copy & 
paste from the original SR) that lead to this discussion.

That said, and just as an idea - let's call it, hmm... $package.changes?

No need for a blockchain.


Regards,

Christian Boltz

[1] It's been a while since I noticed that, so I'm not 100% sure if 
    it's still valid.
    I have package update on my TODO list which I'll delay for a few 
    days so that I can see if the SUSE copyright gets updated to 2025, 
    and if the diff shown by   osc commit   shows the change.

-- 
After a little bit of thinking* [...]
* yes, I do it sometimes and yes, it usually hurts and leads to bad
stuff, I'll try not to do it again [Jos Poortvliet in opensuse-factory]