Custom License Matchers – Apache RAT™ Plugin for Apache Maven
Fork me on GitHub
Custom License Matchers
RAT comes with a set of predefined license matchers, that can be used on typical licenses. However, they will not always be sufficient. In such cases, you may configure a custom license matcher.
The simplest way to create a license check is to create an XML file describing the new license and add it to the processing with the additionalLicenseFiles option.
The second option is to define the custom license directly in the POM. Unlike earlier versions (before 0.16) no custom implementations are required to define custom licenses.
There is a file that defines all the standard licenses:
default.xml
. The pom.xml implementations vary slightly from the configuration because the pom does not allow attributes on the configuration entries. For a full mapping of the command line options to the Maven options see the
Option Name Cross-Reference
Please be aware that custom licenses need to have
unique names
, otherwise a warning is issued and your custom definitions are ignored in favour of the standard license definitions.
The easiest solution for defining custom licenses is to use the
config
option. For this option write your custom configuration like you would for the command line and then include it. In the example below the custom configuration is called
myConfig.xml
...
...
However it is possible to define licenses directly in the pom file. Assume that the header below is an acceptable license.
/**
* Yet Another Software License, 1.0
* Lots of text, specifying the user's rights, and whatever ...
*/
A very easy way to search for such headers would be to scan for the string "Yet Another Software License, 1.0". And here's how to do that in the POM:
...
...
This is very similar to the XML format for defining the configuration.
Approved License Families
By default all POM defined licenses are considered approved, this is a change from pre 0.16 versions. If there are families that are defined in the pom but that should not be considered approved, then a list of approved license families must be provided.
In the following example, we define YASL1 and BAD1 and then indicate that BAD1 is bad by specifying that YASL1 is good.
...
...
Overview of configuration options
When defining custom licenses, remember the following architecture constraints:
Each license is associated with a family. Multiple licenses can be associated with a family.
Each license may have a notes element.
Each license has one matcher.
Matcher details
all
- A collection of matchers in which all enclosed matchers have to be true for the matcher to report true.
any
- A collection of matchers that will report true if any enclosed matcher is true.
- A matcher that matches Copyright text. This uses regular expressions and so should only be used when looking for copyrights with specific patterns that are not caught by a standard text matcher. This matcher will match
"(C)"
"copyright"
, or
"©"
. (text is not case-sensitive). It will also match things like
Copyright (c) joe 1995
as well as
Copyright (C) 1995 joe
and
Copyright (C) joe 1995
. Copyright has 3 child elements:
start
- the starting date of the copyright or the only date.
end
- the ending date of the copyright. Only valid if the starting date is provided.
owner
- the copyright owner.
not
- A matcher that wraps one matcher and negates its value. Not matchers require that the entire header be read before it can report true or false. This may significantly slow processing.
regex
- A matcher that matches a regex string.
spdx
- A matcher that matches SPDX tags. SPDX tags have the form:
SPDX-License-Identifier: short-name
, where short-name matches the regex pattern
"[A-Za-z0-9\.-]+".
spdx takes the short name as an argument.
Combining the examples together
Back to
examples