Open delanym opened 2 weeks ago
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.
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?
@delanym IMHO, you cited many different levels that are interesting, each having its own approach:
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
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"?
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.
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:
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.
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/