Force exact license match

[scheibelp]

Previous license checks have allowed for significant deviation in the license header as long as a few parts of the license matched the general format.

This updates the license check to require almost an exact match, ignoring leading/trailing whitespace, or leading #/. characters (to account for python/bash and rst files).

The check is updated to print a debug message if a date mismatch is detected (e.g. if the copyright ends in 2018 vs. 2019 at this point). A mismatch on the upper end of the date range is not considered an error (so long as it falls within [2017, 2029]).

As an example of how much stricter this is, Copyright 2018 Lawrence... from the simgrid package was considered a mismatch, and had to be updated to Copyright 2013-2019 Lawrence. This could be relaxed to allow for matching on a single year.

The only other package considered noncompliant (which will cause this PR to fail testing) was aom, which updates the first line of the license:

Copyright 2013-2019 Trinity College Dublin and other Spack Project

[tgamblin]

Looks mostly good -- two minor requests. Thanks!

[tgamblin]

Make it ensure the year of the most recent commit, with a grace period of January (so if the commit is in January 2020, 2019 is still an ok year, so we have a month to get it updated). Taking commit date ensures that past commits will continue to pass tests when checked out.

[scheibelp]

So to be clear: it should fail if the date is not year of latest commit or (year-1 if latest commit is january)?

Right now it is less strict: it only prints a debug message if the end date doesn't match. About 20 files will have to change if "2018" is an error (which is fine, I'm just clarifying).

[becker33]

Someone could run this in a Spack instance stripped of its git history, I don't think we want to tie it to a commit.

[scheibelp]

I'll note that doing any checking at all on the date is entirely new, and possibly worth handling in another PR, especially since both of you make good points: for example perhaps it should try to use git, and be more lenient if git is not available. Another possibility is that it could parse the date from a single "official" file that's part of the Spack core, so as long as we remember to update that, then the packages will be handled (and all without invoking git).

Side note: running spack license requires git to be available, but git is never actually run, so Spack instances stripped of git history should be able to run spack license (that's not to say it must be supported).

[becker33]

Only one minor nitpick.

[scheibelp]

@smcgrat do you mind if I replace the modified license in https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/aom/package.py

# Copyright 2013-2019 Trinity College Dublin and other Spack Project
# Developers. See the top-level COPYRIGHT file for details.
#
# SPDX-License-Identifier: (Apache-2.0 OR MIT)

With the default license:

# Copyright 2013-2019 Lawrence Livermore National Security, LLC and other
# Spack Project Developers. See the top-level COPYRIGHT file for details.
#
# SPDX-License-Identifier: (Apache-2.0 OR MIT)

? Some authors have added an # Author:... comment just below, as in https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/perl/package.py - would that be an acceptable option?

[smcgrat]

@smcgrat do you mind if I replace the modified license in https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/aom/package.py

# Copyright 2013-2019 Trinity College Dublin and other Spack Project
# Developers. See the top-level COPYRIGHT file for details.
#
# SPDX-License-Identifier: (Apache-2.0 OR MIT)

With the default license:

# Copyright 2013-2019 Lawrence Livermore National Security, LLC and other
# Spack Project Developers. See the top-level COPYRIGHT file for details.
#
# SPDX-License-Identifier: (Apache-2.0 OR MIT)

No problem. Go for it. Sorry about that, I think I was just copying something else that was obviously incorrect.

? Some authors have added an # Author:... comment just below, as in https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/perl/package.py - would that be an acceptable option?

Would the following be acceptable:

# Author: Darach Golden <dgolden@tchpc.tcd.ie>,
# Institution: Trinity Centre for High Performance Computing, https://www.tchpc.tcd.ie/
# Date: May 09, 2019
# Author: Sean McGrath <smcgrat@tchpc.tcd.ie>
# Institution: Trinity Centre for High Performance Computing, https://www.tchpc.tcd.ie/
# Date: May 09, 2019

[scheibelp]

Would the following be acceptable:

Yes! I'll add that here.

Review comments addressed