Reduce license header

[MarcelKoch]

This PR changes how we handle our license declaration. It moves from the current block of license (~30 lines) to 3/4 lines as defined by https://reuse.software/. The new license header will now read as:

// SPDX-FileCopyrightText: 2017-2023 The Ginkgo authors
//
// SPDX-License-Identifier: BSD-3-Clause

It also updates the add_license.sh script accordingly and changes the top-level license file. The latter might lead to issues with githubs automatic license detection.

Todo:

• check github's license detection - will just use the current license file

[yhmtsai]

does the structure allow the beacon?
I am wondering about some scripts that rely on the BEACON detection.

[MarcelKoch]

Sorry, I didn't realize that other scripts also use the beacon. I will adjust them.

[greole]

REUSE provides a python tool to verify reuse compliance. We could also add this to our CI pipeline. However, this will additionally require to:

• add some license information to our cmake files.
• I think reuse allows to specify a .license file for a folder of binary data, like our assets folder

[MarcelKoch]

@greole I'm very much in favor of that. Here is the old pr for that: #1390. This PR is a first step towards that.

[greole]

LGTM

[MarcelKoch]

Note: Since the format CI is based on the jobs defined in develop, that job will always fail. I will mirror this PR in my fork to check if the CI behaves as expected.

[MarcelKoch]

See MarcelKoch#10 for CI check. The new license header is used properly in the CI. It was necessary to change the develop branch in my fork to already enable the changes to check-format as they are in this PR.

[yhmtsai]

I saw you change some script to adapt the changes of beacon
Does SPDX allow the following? With the following, we do not need to change many scripts

/*******************************<GINKGO LICENSE>******************************
* SPDX-FileCopyrightText: 2017-2023 The Ginkgo authors
*
* SPDX-License-Identifier: BSD-3-Clause
******************************<GINKGO LICENSE>*******************************/

With // approach, it require all script recognize the SPDX fully. Previously, it is only handled through add_license.sh and others only detect or add beacon.

[MarcelKoch]

I would like to keep the new license as short as possible, that's why I'm using //. Also, I think don't think the beacon approach is supported by the reuse tool, to which I will move to in the next step.

[upsj]

LGTM! As the license is always the first part of the file, and much more structured, I also tend to agree we no longer need the beacon

[yhmtsai]

I do not fully agree with it's more structured. beacon way does not hurt the structure but gives easy way to detect the block. something like https://github.com/fsfe/reuse-example/blob/main/src/main.c

[MarcelKoch]

I meant that the reuse tool doesn't support it for adding new license header. Also, I don't see why we need to detect the block. Adding the license will be handled by reuse, which can detect it correctly, and the formatting by clang.

[yhmtsai]

I consider it maybe from another side.
We need to pay additional attension on changing beacon to //. handling license in two or three places may not be good for reuse/consistense.
I originally think it only need to change or create another file (SPDX...)for add_licences/format_header. Other scripts work smoothly.
beacon way is widely used by tranditional license in my mind, so I am also suprised reuse tool may not support it.
request changes mainly for the wrong script and the inconsistence between "the" and "The"

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

0.0% Coverage
0.0% Duplication

The version of Java (11.0.3) you have used to run this analysis is deprecated and we will stop accepting it soon. Please update to at least Java 17.
Read more here

[yhmtsai]

I do not hold the concern for beacon now.