search

mixxxdj / mixxx

Mixxx is Free DJ software that gives you everything you need to perform live mixes.
http://mixxx.org
Other
4.53k stars 1.28k forks source link

REUSE-compliance #10747

Open mixxxbot opened 2 years ago

mixxxbot commented 2 years ago

Reported by: Swiftb0y Date: 2022-06-13T18:01:04Z Status: Confirmed Importance: Wishlist Launchpad Issue: lp1978494 Attachments: 0001-pre-commit-Add-sourceheaders-hook.patch

Even though Mixxx is not a library we still highly value FOSS and properly complying with the associated licensing. REUSE-compliance can automatically validate we maintain proper licensing with mixxx. https://reuse.software/

mixxxbot commented 2 years ago

Commented by: daschuer Date: 2022-06-13T21:42:41Z

Does this require a SPDX-License-Identifier and the SPDX-FileCopyrightText on every file?

We are still in the process of migration to a single license file and rely on git for the copyright owners.

I have just found https://www.gnu.org/licenses/gpl-howto.html.en

Put a license notice in each file.

So it looks like we are doing wrong.

While I am not very font of adding back these headers, it seems to be mandatory. Right?

mixxxbot commented 2 years ago

Commented by: daschuer Date: 2022-06-13T22:18:56Z

Who is the copyright owner of a file? I think every contributor owns his contributions.

However spdx has a contributor filed for "authors who might not be copyright holders"
https://spdx.github.io/spdx-spec/file-information/#⁠814-file-contributor-field

As Far as I know this is part of US law, and does not work in Germany where you cannot release something to the public domain and waive your copyright:

https://www.urheberrecht.de/verzichtserklaerung/

This means we will see a long list of names in each file.

mixxxbot commented 2 years ago

Commented by: daschuer Date: 2022-06-13T22:22:34Z

Is this a automatic process?

mixxxbot commented 2 years ago

Commented by: uklotzde Date: 2022-06-13T22:48:35Z

Multiple authors: https://reuse.software/faq/#many-copyright-statements

Keeping track of each contributor in every file would not be feasible.

mixxxbot commented 2 years ago

Commented by: Swiftb0y Date: 2022-06-14T13:54:18Z

So it looks like we are doing wrong.

While I am not very font of adding back these headers, it seems to be mandatory. Right?

Yes it is, but its only 5 lines which is ok IMO.

Keeping track of each contributor in every file would not be feasible.

Right, but can't we do the chromium team workaround then? We already have a list of every contributor in the contributor-agreement spreadsheet. (do we need to make that public then? I guess we'd need permission for that).

Is this a automatic process?

Can you elaborate? Checking for compliance can be automated with the reuse-tools (python-based). They also offer official pre-commit hooks which would be trivial to add.

As Far as I know this is part of US law, and does not work in Germany where you cannot release something to the public domain and waive your copyright:

You can still license your work using CC0 (which is also what REUSE recommends in this case).

We are still in the process of migration to a single license file and rely on git for the copyright owners.

https://reuse.software/faq/#vcs-copyright

mixxxbot commented 2 years ago

Commented by: daschuer Date: 2022-06-15T19:04:30Z

For my understanding the VCS paragraph does not really apply to us, because, there is no such thing as the public domain on the Internet.

See: https://en.wikipedia.org/wiki/Wikipedia:Public_domain

Every contributor has only partial copyright to files he has modified. We have nothing else than the git history to track these edits. Since a contributor cannot waive his copyright international and under the German law, it is a valid source for keeping track of copyright.

Everyone need to treat others work under its own copyright: https://en.wikibooks.org/wiki/FOSS_Licensing/Copyright_Basics#From_National_to_International

The Chromium Team workaround doe not work well, because this is no legal instance. A Contributor List in every file will cause conflicts and is a maintenance burden and privacy issue.

The other issue is that we do not have a pure GPL license, so a license tag "GPL-2.0-or-later" in every file would be not correct.

My conclusion, let's stick with the current situation unless we are forced to change something.

mixxxbot commented 2 years ago

Commented by: Swiftb0y Date: 2022-06-16T00:02:47Z

I'm really not familiar with copyright. I doubt that REUSE does not apply to us though since its a project of the FSFE (emphasis on Europe) and used / endorsed by many German entities (KDE, Siemens) as well as the Linux kernel. https://reuse.software/supporters/

We can take a look KDE or the Linux Kernel to look how they deal with the issues you mentioned.

A Contributor List in every file will cause conflicts and is a maintenance burden and privacy issue.

I wasn't talking about one per file, but one per repository, yes the privacy implications have to researched first.

The other issue is that we do not have a pure GPL license, so a license tag "GPL-2.0-or-later" in every file would be not correct.

Yes, the fact that we have a custom license requires some more care, but thats not a deal-breaker.

mixxxbot commented 2 years ago

Commented by: daschuer Date: 2022-06-16T05:12:53Z

I doubt that REUSE does not apply to us ...

I have not written that! It is the argument against using Git for copyright that does not apply to us: https://reuse.software/faq/#vcs-copyrig

See also: https://reuse.software/faq/#copyright-holder-author

In our case the author is ALWAYS the copy right holder because no one is payed in Mixxx and there is no Public Domain International. That was my point.

mixxxbot commented 2 years ago

Commented by: Swiftb0y Date: 2022-06-17T01:12:23Z

I doubt that REUSE does not apply to us ...

I have not written that!

I'm sorry, I misunderstood. I didn't mean to put words in your mouth.

I still don't understand what the problem is though. Can we agree that REUSE-compliance (or otherwise making sure mixxx is properly open-source licensed) is something worth caring about? Since IANAL (and no one on the mixxx team either afaik), relying on a professionally vetted framework such REUSE would be a safe option.

Some arguments just don't make sense either. The contributor-list in every file is not a maintenance burden, it can be automated quite trivially. Its also not a concern privacy-wise because a contributor already publishes their name and email as part of the git commit, so putting the same info into the file header does not make a difference.

mixxxbot commented 2 years ago

Commented by: daschuer Date: 2022-06-17T07:51:07Z

Can we agree that REUSE-compliance (or otherwise making sure mixxx is properly open-source licensed) is something worth caring about?

Yes, if we keep the maintenance burden at a minimum.

To be "correct" we need to put the legal name of the copy right holders into the file. I don't think we can effort that. Copying the email address from the git commit to the file is a reference to the list of copyright holders.

Why not follow the pattern from: https://github.com/mixxxdj/mixxx/blob/main/COPYING

// SPDX-FileCoprightText: 2000-2022 The respective Mixxx authors

The maintanace burden is to advance the year when editing the file. That can be done by a commit hook

How will the licence identifier look like?

mixxxbot commented 2 years ago

Commented by: Swiftb0y Date: 2022-06-17T11:02:00Z

Yes, if we keep the maintenance burden at a minimum.

That should be trivial. The biggest issue would be the mass-change to introduce the license headers, but since those are always at the top of the file, they should not lead to many conflicts. After that, just enable the pre-commit hook and we should be good. Also we should probably split up the LICENSE file into a directory that contains each license in a single file.

// SPDX-FileCoprightText: 2000-2022 The respective Mixxx authors

The maintanace burden is to advance the year when editing the file. That can be done by a commit hook

Yes, that looks good, advancing the year can be automated.

How will the licence identifier look like?

I did some research and I'm not sure now. SPDX has a mechanism to combine exceptions with licenses, but there is no standard exception that would fit our purpose. I don't know if we can create our own exception while remaining compliant.

mixxxbot commented 2 years ago

Commented by: Swiftb0y Date: 2022-06-17T11:12:35Z

https://reuse.software/faq/#custom-license

This should work I guess.

mixxxbot commented 2 years ago

Commented by: Holzhaus Date: 2022-06-17T23:56:44Z

Adding the source headers and advancing the year can probably be automated using the sourceheaders hook. But I'm still unsure if it's worth adding all these license headers tbh, even to tiny config files that probably don't even cross the threshold of originality and hence cannot be copyrighted. All to solve a problem that simply does not exist for our project: The license is obvious and a copyright line "The Mixxx authors" does not add any value.

mixxxbot commented 2 years ago

Commented by: Holzhaus Date: 2022-06-18T00:03:59Z Attachments: 0001-pre-commit-Add-sourceheaders-hook.patch

But I don't really care about the headers, they don't hurt either.

You can use the "sourceheaders" hook to add license headers automatically to all files. This would also make it easier for contributors that add a mapping. The patch attached could provide a starting point if you want to go ahead with this.