Change copyright headers

[erikbosch]

Fixes #632

As discussed in the issue, this PR intends to unify and simplify copyright handling. It is inspired by https://www.eclipse.org/projects/handbook/#ip-copyright-headers. One difference is that we are not referencing to a NOTICE.md file. Eclipse often do so, in that the file they state:

All content is the property of the respective authors or their employers.
For more information regarding authorship of content, please consult the
listed source code repository logs.

As this concerns copyright statements we should possibly consult TST or Board (FYI @paulboyes ) and get their approval before merging, but the first step is to discuss if we from a technical/practical perspective thinks this a reasonable change.

[SebastianSchildt]

Alway choosing the oldest, is that by intention, or should it be newest or "oldest"-"last touched"

[erikbosch]

Yes, reusing what Eclipse writes at https://www.eclipse.org/projects/handbook/#ip-copyright-headers. But I am open to any policy

The {year} is the year in which the content was created (e.g. “2004”).

The year is expressed either as a single year or a range spanning the year of the initial creation and that of the most recent change.

Do we need to specify a range of years in the copyright statement?

No. In the past, legal advice was that the year of the initial creation of the content and the year of the last change should be reflected in the copyright header. This is no longer the case. Specify the year that the content was initially created in the copyright statement.

Do I need to update the year in the copyright statement when I make changes to the file?

No. The year in the copyright header should be the year that the content was created.

[SebastianSchildt]

I guess it is by intention, that they notices just point to "a LICENSE in this repo", but it would be much more robust (distribution or code-scanning wise), if there were an SPDX header in each individual file

Generally speaking I am in favour of this change: Generic copyright headers

[erikbosch]

I guess it is by intention, that they notices just point to "a LICENSE in this repo", but it would be much more robust (distribution or code-scanning wise), if there were an SPDX header in each individual file

Generally speaking I am in favour of this change: Generic copyright headers

I have no problems changing to something like this, but maybe board (FYI @paulboyes ) needs to be involved giving their view

/********************************************************************************
 * Copyright (c) {year} Contributors to COVESA
 *
 * This program and the accompanying materials are made available under the
 * terms of the Mozilla Public License 2.0 which is available at
 * https://www.mozilla.org/en-US/MPL/2.0/
 *
 * SPDX-License-Identifier: MPL-2.0
 ********************************************************************************/

[erikbosch]

Meeting notes:

• Paul: The TST to be involved, possibly board.
• Erik: AP @paulboyes to bring it up at TST
• please review

[ppb2020]

I am in favour of using the "Contributors to COVESA" approach. I would like to see some consistency in the way the comments are coded (I saw some differences where sometimes "## Copyright" is used and "# Copyright" is used elsewhere).

I also think having a license statement of reference to a license is a good idea. It can either specify the license, point to where to find it, etc. I have no personal preference on how to do this, as long as it is consistent and as a developer I can simply get this from an existing file or developer guide document.

Lastly, my understanding (and I am not a lawyer) is that if a file is modified, the year of the copyright does not need to be updated (that is, the year can remain to be the year of the original creation). However, given that the files can in some cases be shown independently than in a repository, some lawyers have a preference for the year to be updated each time a file is changed. Although not necessary, there are some lawyers who also wish the year reference to be a range from creation year to year of the most recent change.

Personally, I think all this is too complicated for developers to remember to do the updates, for developers to know what the copyright update rules area, to automate commit checks, and manage situations such as files being renamed (in that case, do they retain the original year or, since its a new file it takes the new year, or you have to use a range?).

Much simpler is a single year, the year of the most recent change. In this manner, simple commit checks can be implemented to find the copyright line and validate that the year matches the current year and inform the develoepr they forgot to update it or even to automatically update it as part of the commit.

[erikbosch]

Concerning last comment - yes, it would be quite easy to to add checks to check that the header looks as expected, we have as an example a check that files specifies SPDX in KUKSA.val at https://github.com/eclipse-kuksa/kuksa-actions/tree/main/spdx

Concerning layout of the header - it will look different for different file types as different file types have different syntax for comments. We may need to discuss for which files we want to consider copyright/license files as mandatory, but that is a later discussion

[ppb2020]

Concerning the format, indeed each style of comment may vary, but the actual text for the Copyright notice, including the year and use of "(c)" can be prescribed, facilitating recognition and parsing by the commit hooks.

[erikbosch]

Based on comments I did some changes to include SPDX identifier for all files and a basic checker that for now checks that changed *.py and `.vspec files contains copyright and SPDX headers.

[SebastianSchildt]

This is much cleaner than before, and finally contains industry standard/machine-readable SPDX header, and IANAL license-wise speaking it does not change anything, just more unambiguously/thoroughly marked.

We might however want to decide to wait for feedback from TST or board for a while, to see if they concur.

Once this is in, we should do the same in vss-tools

[erikbosch]

Topic discussed and aligned within TST and Board. Merging!