SPDX copyright: make project reuse-compliant

[aesteve-rh]

Make the whole project reuse-compliant and add
a lint job to check that all files have their copyright.

Signed-off-by: Albert Esteve [email protected]

[aesteve-rh]

Just an idea, since I noticed outdated copyright on recently updated files, and this is something generally difficult to maintain if we don't automate it.

Complemented with a script to update copyright automatically, could make keeping the copyright updated much easier.

Adding this to a CI may seem like extra burden for contributors, but take into account that this only will pop up at the beginning of each year, and relax later on.

[mz-pdm]

I'm not sure this change would be very useful. It would be better to replace the years and the whole copyright texts with short SPDX identifiers. If you'd like to take such an effort, there was some related discussion in comments to https://gerrit.ovirt.org/c/vdsm/+/116741 .

[aesteve-rh]

I did not know that this was discussed before.

In principle, I do not intend to replace the format, just have a simple check to ensure that the year is updated in the modified files in a branch. No global update, but incremental, depending on the files updated. No format check.

I mean, it could be just as simple as looking for the year string in the first two lines, and remove the regex, if we prefer it to be completely format agnostic.

But if there is no need to enforce/check for copyright updates, we can dismiss the PR.

[mz-pdm]

AFAIK the years do not have a significant legal meaning so although it's good to keep them up-to-date, it's not strictly necessary. It doesn't harm to have a tool to check them but I'm not sure it's worth to maintain it in automation, IMO the resources could be better spent towards the conversion to SPDX and to get rid of the problem completely (which I admit is more difficult but perhaps not that much if we can agree how to do it). Let's see what the others think.

[nirs]

The best way is to replace the copyrights (removing the years) and the license boilerplate using the ‘reuse’ tool, and add ‘reuse lint’ step to the ci.

https://reuse.software/

see how it integrated in blkhash:

https://gitlab.com/nirs/blkhash/-/blob/master/.reuse/templates/blkhash.jinja2

[aesteve-rh]

I have been playing with the reuse tool. It is really nice indeed. The branch needs some refinement (probably some copyright comments are in the wrong style), but is a very powerful tool.

[mz-pdm]

Cool, looks promising. It needs some polishing (it sometimes removes more than just the copyright notice) and explanations (do we keep the original copyright notices? will we still have years in SPDX identifiers?) but hopefully it will achieve the desired result.

Why to add LICENSES/ when we already have COPYING?

[aesteve-rh]

do we keep the original copyright notices? It respects the copyright line with year and company, but removes the rest of the surrounding header. An example of such behaviour (in https://github.com/oVirt/vdsm/blob/5292e3380d205d99ed5c9b650de79069d20ad066/Makefile.am):

# Copyright 2008-2020 Red Hat, Inc.
# SPDX-FileCopyrightText: 2022 Red Hat, Inc.
# SPDX-License-Identifier: GPL-2.0-or-later

Previously:

#
# Copyright 2008-2020 Red Hat, Inc.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
#
# Refer to the README and COPYING files for full details of the license
#

If we prefer to keep the full header, that is configurable (in the template).

will we still have years in SPDX identifiers? That is also configurable. In the current version, I have kept the years in the SPDX identifiers, which is the default behaviour. But we can omit them if it is preferred.

Why to add LICENSES/ when we already have COPYING? LICENSES is the name of the folder where the licenses are downloaded to make the repository reuse-compliant. I checked if it is configurable, but I didn't find anything, it always talks about the LICENSES folder. We may want to remove COPYING (and adapt the main README.md) if we opt for this solution.

[aesteve-rh]

Note for the CIs: https://github.com/marketplace/actions/reuse-compliance-check

[mz-pdm]

I think we needn't duplicate the copyright notices. So if we have

SPDX-FileCopyrightText: SOMETHING A
SPDX-FileCopyrightText: SOMETHING-B

then there is no need to keep

Copyright SOMETHING-A
Copyright SOMETHING-B

at the same place. But make sure all the copyright lines (I mean those single "Copyright XXXX YYYY" lines, not full headers) are copied to SPDX-FileCopyrightText entries, I could see some non-RH ones were missing.

As for years, I'm not sure what to do about them. We'd like to get rid of updating them, OTOH we should probably not discard the existing ones blindly. Examples in https://spdx.github.io/spdx-spec/v2.3/file-tags/ show entries both with and without dates, https://spdx.github.io/spdx-spec/v2.3/file-information/#8.8 suggests to keep the information as it is, including dates. So I'd keep the dates for now.

If LICENSES/ is required then OK. Whether to keep COPYING in such a case: It defines the default licence, which may be relevant for files without copyright information. So it's probably better to keep it.

IANAL so trying to be on the safe side with my suggestions. Maybe someone else can clarify it.

[nirs]

This is too big to review. Try to covert by in smaller parts (e.g. storage, virt, network, infra).

[nirs]

More cleanup needed before this.

[nirs]

reuse lint
make: reuse: Command not found

Please add reuse to the containers before you add reuse to the lint target.

[aesteve-rh]

Requirements are updated already in the first commit, and I built and tested the containers locally.

Once we integrate #311 and #294 I will rebase, build and push the containers, and this will be ready for review :)

[aesteve-rh]

After aligning with @nirs I postponed #294 to after this PR. I'll ready the PR up, should be good in its current status.
Waiting for #294.

[mz-pdm]

Why do we have so many files in Vdsm? :-) Looks OK to me as I skimmed through it. Let's preferably merge this before branching, to avoid troubles with future backports.

[mz-pdm]

/ost basic-suite-master el9stream