Standard Business Rules
The processing of business rules is organized in different phases. Each phase might consist of multiple decision tables to be processed in order.
Phase 1: Determining assigned Licenses
In this phase the license data imported via the readers is cleaned and normalized. At the end of this phase the internal data model should clearly represent all components and their assigned licenses in normalized form.
The phase itself consists of two decision tables / rule groups:
Decision Table: Explicitly setting Licenses
With this decision table is is possible to explicitly assign NormalizedLicenses to components. This will be used if the imported RawLicense data is either incomplete or incorrect. Items which have been processed by rules of this group will not be reprocessed by the next rule group.
Decision table data: LicenseAssignmentV2*.xls/csv
-
LHS conditions:
-
Engagement.clientName
-
Engagement.engagementName
-
Application.applicationName
-
ApplicationComponent.groupId
-
ApplicationComponent.artifactId
-
ApplicationComponent.version
-
RawLicense.origin
(new with "V2" version of rules) -
RawLicense.declaredLicense
-
RawLicense.url
-
-
RHS result:
-
NormalizedLicense.normalizedLicenseType
-
NormalizedLicense.normalizedLicense
-
NormalizedLicense.normalizedLicenseUrl
-
NormalizedLicense.comment
-
: On these fields the Extended comparison syntax might be used
All RawLicenses which are in scope of fired rules will be marked so that they do not get reprocessed by the following decision table.
With the "V2" version of rules the additional field/condition origin was introduced.
This can be used to fire rules only if the raw license data was obtained from a specific data source.
Its primary intention is to distinguish between data obtained via normal readers or from Scancode data.
Decision table data for the new data structure is named LicenseAssignmentV2*.xls/csv .
The old decision table structure LicenseAssignment*.xls/csv is deprecated but for compatibility reasons still supported.
|
Decision Table: Detecting Licenses from Imported Data
With this decision table the license info from the RawLicense is mapped to the NormalizedLicense. This is based on the name and/or URL of the license as imported via the readers.
Decision table data: LicenseNameMapping*.xls/csv
-
LHS conditions:
-
RawLicense.declaredLicense
-
RawLicense.url
-
-
RHS result:
-
NormalizedLicense.normalizedLicenseType
-
NormalizedLicense.normalizedLicense
-
: On these fields the Extended comparison syntax might be used
Phase 2: Selecting applicable Licenses
Within this phase the actually applicable licenses will be selected for each component.
This phase consists of two decision tables.
Choosing specific License in case of Multi-Licensing
This group of rules has the specialty that it might match to a group of NormalizedLicenses associated to an ApplicationComponent. In case that multiple licenses are associated to an ApplicationComponent one of them might be selected as "effective" license and the others might be marked as Ignored
.
Decision table data: MultiLicenseSelection*.xls/csv
-
LHS conditions:
-
ApplicationComponent.groupId
-
ApplicationComponent.artifactId
-
ApplicationComponent.version
-
NormalizedLicense.normalizedLicense
(licenseToTake; mandatory) -
NormalizedLicense.normalizedLicense
(licenseToIgnore1; mandatory) -
NormalizedLicense.normalizedLicense
(licenseToIgnore2; optional) -
NormalizedLicense.normalizedLicense
(licenseToIgnore3; optional)
-
-
RHS result
-
license matching "licenseToTake" will get this value assigned to
effectiveNormalizedLicense
-
licenses matching "licenseToIgnoreN" will get
IGNORED
assigned toeffectiveNormalizedLicenseType
Ignored
assigned toeffectiveNormalizedLicense
-
: On these fields the Extended comparison syntax might be used
It is important to note that the rules only match, if all licenses given in the conditions actually exist and are assigned to the same ApplicationComponent.
Selecting / Overriding applicable License
The second decision table in this group is used to define the effectiveNormalizedLicense
(if not already handled by the decision table before).
Decision table data: LicenseSelection*.xls/csv
-
LHS conditions:
-
ApplicationComponent.groupId
-
ApplicationComponent.artifactId
-
ApplicationComponent.version
-
NormalizedLicense.normalizedLicenseType
-
NormalizedLicense.normalizedLicense
-
-
RHS result:
-
NormalizedLicense.effectiveNormalizedLicenseType
(if empty in the decision table then the value ofnormalizedLicenseType
will be taken) -
NormalizedLicense.effectiveNormalizedLicense
(if empty in the decision table then the value ofnormalizedLicense
will be taken) -
NormalizedLicense.effectiveNormalizedLicenseUrl
(if empty in the decision table then the value ofnormalizedLicenseUrl
will be taken)
-
: On these fields the Extended comparison syntax might be used
Phase 3: Legal evaluation
The third phase is the legal evaluation of the licenses and the check, whether OSS usage is according to defined legal policies. Again this phase comprises two decision tables.
Pre-Evaluation based on common rules
Within the pre evaluation the license info is checked against standard OSS usage policies. This roughly qualifies the usage and might already determine licenses which are OK in any case or which need to be further evaluated. Furthermore, they qualify whether the license text or source code needs to be included in the distribution. The rules in this decision table are only based on the effectiveNormalizedLicense
and do not consider any project, application of component information.
Decision table data: LegalPreEvaluation*.xls/csv
-
LHS condition:
-
NormalizedLicense.effectiveNormalizedLicenseType
-
NormalizedLicense.effectiveNormalizedLicense
-
-
RHS result:
-
NormalizedLicense.legalPreApproved
-
NormalizedLicense.copyLeft
-
NormalizedLicense.licenseCompliance
-
NormalizedLicense.licenseRefUrl
-
NormalizedLicense.includeLicense
-
NormalizedLicense.includeSource
-
Final evaluation
The decision table for final legal evaluation defines all rules which are needed to create the result of the legal evaluation. Rules here might be general for all projects or even very specific to a project if the rule can not be applied to other projects.
Decision table data: LegalEvaluation*.xls/csv
-
LHS condition:
-
Engagement.clientName
-
Engagement.engagementName
-
Engagement.customerProvidesOss
-
Application.applicationName
-
ApplicationComponent.groupId
-
ApplicationComponent.artifactId
-
ApplicationComponent.version
-
ApplicationComponent.usagePattern
-
ApplicationComponent.ossModified
-
NormalizedLicense.effectiveNormalizedLicenseType
-
NormalizedLicense.effectiveNormalizedLicense
-
-
RHS result:
-
NormalizedLicense.legalApproved
-
NormalizedLicense.legalComments
-
: On these fields the Extended comparison syntax might be used
Amending the builtin decision tables with own rules
The standard process as described before consists of 6 decision tables / rule groups to be processed in sequence. When using the builtin default base configuration all those decision tables use the internal sample data / rules as contained in Solicitor.
To use your own rule data there are three approaches:
-
Include your own
rules
section in the project configuration file (so not inheriting from the builtin base configuration file) and reference your own decision tables there. -
Create your own "Solicitor Extension" which might completely redefine/replace the builtin
Solicitor
setup including all decision tables and the base configuration file. See Extending Solicitor for details. -
Make use of the optional project specific decision tables which are defined in the default base configuration: For every builtin decision table there is an optional external decision table (expected in the filesystem) which will be checked for existence. If such external decision table exists it will be processed first - before processing the builtin decision table. Thus is it possible to amend / override the builtin rules by project specific rules. When you create the starter configuration of your project as described in Starting a new project, those project specific decision tables are automatically created.