On Fri, Nov 30, 2018 at 07:20:15PM -0500, Michael Dolan wrote:

The Common Cure Rights Commitment (CCRC) which was based on the KES also
applies to an indefinite pool of projects. If one or a few of the companies
own all the copyright, my recommendation would be to just relicense the
project with an appropriate additional permission as a license modifier and
require all new contributors to give the same license. Instead it could
apply to N number of projects, many of which we do not know about and for
each one it only applies to contributions from that company and it doesn't
change the project license. Even if the company wrote all the code in a
file today, what happens when NewContributor makes a contribution - now you
have to notify everyone to remove the "WITH CCRC-1.0" in the next SPDX
review? Unless someone is running cregit and reviewing each of those files
they would never know.

Note: Common Cure Rights Commitment was an earlier name for what Red
Hat later ended up branding the GPL Cooperation Commitment. As was
pointed out on the call, GPLCC now exists as three variants,
Corporate, Individual and Project. The Corporate version is a
commitment made by companies, not specifically tied to particular
projects or code. The Individual version is similar but is made by
individuals. The Project version is designed be used in a project
source repository. My original suggestion had been to have an SPDX
exception identifier for the Project version only (I will comment on
this issue in a separate posting).

The Project version of GPLCC serves exactly as what Mike calls "an
appropriate additional permission as a license modifier and require[s]
all new contributors to give the same license". It is designed to be
usable by existing as well as new projects, by applying prospectively
to all contributions as of the date of adoption of the commitment.

I think if communities want to do this, we should be guiding them to
revisit using a CLA or some other means to capture commitments from prior
contributors and change the project license itself to include these
exceptions in any future contributions.

With the GPLCC Project version, a CLA is not needed since it
contemplates that past contributions might not be covered by the
commitment while future ones will be. This may make an SPDX identifier
for GPLCC unusual, in that it describes a licensing fact for an entire
project that may not apply to all contributions made under the
underlying project license. Nonetheless, Red Hat considers it highly
desirable to have SPDX recognize GPLCC with an identifier.

As for the KES, I don't have any concerns about SPDX separately
recognizing an identifier for it. If it does, however, then I believe
it would be no less justifiable to have an identifier for GPLCC. I do
not think Red Hat itself would find any practical value in using a KES
identifier, especially if the kernel developers themselves don't use
it in individual source files, but admittedly we are making only
limited use of SPDX identifiers at present.

Richard