Re: [gentoo-dev] Re: [RFC] Adding 'GPL-2-only', 'GPL-3-only' etc. license variants for better auditing

[Kent Fredric]

On Sat, 21 Sep 2019 22:58:03 +0200
Ulrich Mueller <ulm@g.o> wrote:

> If the goal of this exercise is to do an audit of ebuilds labelled as
> "GPL-2", then a less intrusive approach (which I had already suggested
> when this issue had last been discussed) would be to add a comment to
> the LICENSE line, either saying "# GPL-2 only" for packages that have
> been verified. Or the other way aroung, starting with a comment saying
> that it is undecided, which would be removed after an audit. This would
> have the advantage not to confuse users, and have no impact on their
> ACCEPT_LICENSE settings. (For example, some people exclude AGPL and
> would have to add entries for AGPL-3-only.)

An adjuct idea: 

Given things like "License" can get changed by upstream, and is prone
to deviating from what we have in the ebuild, and given the only way to
automate testing that requires being unable to unpack the archive and
grep for various things ...

Maybe we instead should be considering a per-package file that
indicates some kind of audit trail?

< dev-qt/qtwebengine/audit >
------------
# audit_ident  aduit_param [....]
license 2019-09-22 5.12.5
------------

Where for example,  the license audit is: 

   @NAME: license
   @PARAMS: DATE VERSION
   @DESCRIPTION:
      Certify a UTC DATE and VERSION used as reference, that you explicitly
      and intentionally carefully reviewed upstreams sources against
      the LICENSE field, ensuring you used the appropriate license and
      combinations, for instance: ensuring you wrote "GPL-2" only when
      upstreams license clearly omits the "or later" clause, and using
      "GPL-2+" in where the clause is present.

Where you specify the version of the package at the time you carefully
audited it last.

At least that way, you can automate doing spot checks for license being
current and then yell at somebody to re-check it.

This seems like a more reliable approach than hoping the right value
was used and nothing has changed without anyone noticing in the interim.

And this tool could be used to expand the sort of scope of things QA
can check for, by ensuring that things that can't be checked
automatically, can at least have some sort of record indicating when
they were checked last (where git commit log will indicate who
performed the check)

Though there's lots of bikeshed potential here.

Just planting seeds :)