Use SPDX license header

[vit9696]

Currently we use quite a lot of different formatting for license types and copyright holders, and while it is not really important for a hobby project, such as ours, I believe it is reasonable to update things for simplicity and to reduce the bureaucracy.

From there on I request us to use BSD-3-Clause everywhere as before with the following formatting for file headers.

Notes:

• I am not positive whether to use <BR> between copyright holders, as in my opinion it reduces readability, but may be required by doxygen.
• I am not sure about additional description, most likely it should go after SPDX-License-Identifier separated by an empty line.
• I am not positive whether we want more empty lines.

C-like languages:

/** @file
  Copyright (c) 2015-2019, vit9696. All rights reserved.
  Copyright (c) 2016, Download-Fritz. All rights reserved.
  Copyright (c) 2019, SomeOtherPerson. All rights reserved.
  SPDX-License-Identifier: BSD-3-Clause
**/

or

/** @file
  Super duper protocol implementation on XYZ firmware.

  Copyright (c) 2015-2019, vit9696. All rights reserved.
  Copyright (c) 2016, Download-Fritz. All rights reserved.
  Copyright (c) 2019, SomeOtherPerson. All rights reserved.
  SPDX-License-Identifier: BSD-3-Clause
**/

inf/python/perl:

## @file
# Copyright (c) 2015-2019, vit9696. All rights reserved.
# SPDX-License-Identifier: BSD-3-Clause
##

or

## @file
# Super duper protocol implementation on XYZ firmware.
#
# Copyright (c) 2015-2019, vit9696. All rights reserved.
# SPDX-License-Identifier: BSD-3-Clause
##

nasm:

;------------------------------------------------------------------------------
; @file
; Copyright (c) 2015-2019, vit9696. All rights reserved.
; SPDX-License-Identifier: BSD-3-Clause
;------------------------------------------------------------------------------

or

;------------------------------------------------------------------------------
; @file
; Super duper protocol implementation on XYZ firmware.
;
; Copyright (c) 2015-2019, vit9696. All rights reserved.
; SPDX-License-Identifier: BSD-3-Clause
;------------------------------------------------------------------------------

[mhaeuser]

Is it intended inf/... are the only ones with the description to have a different offset than the copyrights?
Should we align it with NASM to be 1 space for either?

[vit9696]

Merely an overlook. Fixed consistency, no idea whether 1 or two spaces are better.

[mhaeuser]

I think one space is more consistent with the rest. Two spaces for a prefix-less C comment and one space for those with a prefix is how it's done everywhere.

[mikebeaton]

I had a look on https://opensource.stackexchange.com/ and found this answer (which, while directly on topic, actually does not seem very helpful) and this answer (which seems both on topic and helpful).

The reason I mention it because the second answer specifically recommends putting the newest copyright notice at the top. Having just tried it, that works quite well: it naturally looks as if the top line is the most recent contribution, built on top of the earlier contributions - as it is. Whereas putting the newer line lower actually makes it look less clear what the relative precedence of contributions is. I know that there's no clear (or just no) reason for this to logically be the case, but anyway, I just wondered, since there's a fairly clear recommendation from a fairly authoritative (seeming?) source, whether OC was certain about keeping most recent last?

[vit9696]

EDK II consistently does it otherwise to be honest, e.g.:

/** @file
  ACPI 5.1 definitions from the ACPI Specification Revision 5.1 Errata B January, 2016.

  Copyright (c) 2014 Hewlett-Packard Development Company, L.P.<BR>
  Copyright (c) 2014 - 2018, Intel Corporation. All rights reserved.<BR>
  (C) Copyright 2015 Hewlett Packard Enterprise Development LP<BR>
  Copyright (c) 2020, ARM Ltd. All rights reserved.<BR>
  SPDX-License-Identifier: BSD-2-Clause-Patent
**/

Not sure what to choose here, @mhaeuser?

[mikebeaton]

I wasn't taking that into account - given how uniformly OC tries to stick to EDK II style, I think I'd revise my preference, and agree that it makes sense to go newest last in OC too.