Introduce check goal

[delanym]

I propose a goal that will fail the build if licenses are not following a policy.

For example, fail if any licenseConcluded is "NOASSERTION" or "AGPL-1.0-only".

Or even check that all licenses are "OSI Approved" as per https://spdx.org/licenses/

[goneall]

I could see this being a very useful goal, but I would suggest this be implemented in a separate maven plugin since it would involve quite a bit of work to configure policies.

A separate policy plugin could leverage some of this plugin's implementation.

Also note the related Apache Creadur project which implements some license policy related functionality. Also licensed under the Apache 2.0 license - it could provide some support for such a plugin.

[delanym]

I don't see your point about placing the policy check in another plugin. What is the benefit of that?

The jacoco-maven-plugin has separate goals to produce a test coverage report and fail the build when code coverage metrics are not met.

Checkstyle plugin also has goals to produce a report and check the build.

@hboutemy do you see a case for a profile plugin other than the enforcer-maven-plugin?

[hboutemy]

@delanym IMHO, you cited many different levels that are interesting, each having its own approach:

1. reporting, as in site reporting: this one is usually another (reporting) goal in the same plugin (the few cases where it has become a separate plugin makes it complex, IMHO: see for example https://maven.apache.org/surefire/maven-surefire-report-plugin/ or https://maven.apache.org/plugin-tools/maven-plugin-report-plugin/)
2. enforcer: here, the typical case is when there are many ways to configure the checked rules, based on project's very specific taste
3. fail parameter in pre-existing goals, either the main one or the reporting one: here, it's more when there are some basic minimum level of expectation, that is really considered as an error when they are not met at build time
4. I don't remember case where plugin creates a separate check goal: I now see how Rat maven plugin has a reporting goal and a check goal, but no third one = what I called previously the "main" goal https://creadur.apache.org/rat/apache-rat-plugin/index.html

Rat case seems caused by the fact that rat is a control tool per-se, not a tool to generate an output, where a level of check could be added as a parameter.

SPDX maven plugin is a tool that has a main goal of generating content (the SPDX description), then its natural way of adding a simple level of check would be adding parameters to that goal: option 3 instead of option 4; Creating a separate plugin looks really overkill, but creating a reporting goal could make sense.

Should checks for SPDX license info be kept as parameters (of the main goal and/or the new reporting goal) or extracted as an enforcer rule: it really depends on the level of complexity/flexibility you expect

I suppose checks that currently are discussed about license could also happen for other aspects of the generated SPDX doc

I don't get yet what type of checks are envisioned, and how adding them to the generation configuration would just make too much: spdx-maven-plugin already has many many parameters to configure the generation of SPDX doc http://spdx.github.io/spdx-maven-plugin/createSPDX-mojo.html#optional-parameters

[hboutemy]

taking another additional approach to the question:

For example, fail if any licenseConcluded is "NOASSERTION" or "AGPL-1.0-only".

I see how failing on "NOASSERTION" would make sense as parameter fo existing goal, because NOASSERTION means that the generation of SPDX file is not done properly, parameters need to be added to better extract data from source files

"AGPL-1.0-only": here I see more a choice of consumption

perhaps I misread the example: it would be "when generating the SPDX, fail if licenseConcluded is not in the expected list of licenses = what the project owner thought his project was licensed under"?

[delanym]

Its more a case of a project owner who needs to distribute third-party dependencies. The SPDX file is proof that the owner is not distributing anything he shouldn't, and the build check is there to prevent an invalid distribution going out and to provide a regular notification that everything is in order.

[goneall]

Thanks @hboutemy and @delanym for the additional context.

I could see value in adding a goal to this plugin. One of my objectives for starting this plugin was to make it easier for project maintainers to use SPDX and comply with licensing.

I still have a couple concerns with this approach:

• The check goal would require extensive configuration. Since there is already a lot of configuration documentation we're requiring the users to read through, I'm concerned adding extensive configuration options would make the usage more complex and reduce adoption. This may be solvable through documentation.
• License policies vary significantly from organization to organization, from my experience as an auditor of license compliance, I don't think we can predict and encode options for all the variations. There are several commercial tools out there that manage license compliance with rather sophisticated rules and configuration options. I wouldn't want to try to duplicate all of this in a plugin.
• SPDX as an organization has made a decision not to encode what may be considered legal opinion into its standards or its tools. This won't impact options like "must be an OSI license" or "Not AGPL", but it would disallow implementing features like "disallow license conflicts with license X".

When I've written tools to manage policies, I've typically created a license "good list" and license "bad list". Any license on the good list will pass, and license on the bad list will fail. Any license not on either list is flagged for review and subsequently moved to the good or bad list. We could support this process by having good and bad list configurations for a check goal.

I'm a little hesitant on an OSI flag as the license flag can change over time (be removed or added) and many of the companies I've worked with would like an extra review. That being said, it isn't a difficult option to implement - it would just increase the complexity for the user.