-
Notifications
You must be signed in to change notification settings - Fork 314
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Apply license choices specified for a package defined in the repository configuration file #3713
Apply license choices specified for a package defined in the repository configuration file #3713
Conversation
e252711
to
b81fd6c
Compare
bdd054c
to
59722ad
Compare
59722ad
to
688e2f6
Compare
8e67f11
to
2b12afa
Compare
2b12afa
to
62ba93f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some minor remarks. Thumbs-up for the thorough testing!
val result = expression.applyChoices(choices) | ||
|
||
result shouldBe "b OR d".toSpdx() | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we have a test case where a single choice can be applied multiple times? E.g. we have something like (a OR b) AND (c OR d) AND (a OR e)
. When applying the choice a
to the whole expression I assume the result should be a AND (c OR d) AND a
, and this can probably be simplified to a AND (c OR d)
. Is this assumption correct and should this be tested as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your assumption is incorrect.
a
is not a valid choice for (a OR b) AND (c OR d) AND (a OR e)
, because the choice is not just a OR b
but always need to take the licenses from the AND
expressions into consideration.
To get your wanted result the user would need to configure something like this:
- given: a OR b
choice: a
- given: a OR e
choice: a
I added a test for this.
a7910fb
to
a4d08f0
Compare
@@ -135,7 +135,8 @@ open class PackageRule( | |||
* A DSL function to configure a [LicenseRule] and add it to this rule. | |||
*/ | |||
fun licenseRule(name: String, licenseView: LicenseView, block: LicenseRule.() -> Unit) { | |||
resolvedLicenseInfo.filter(licenseView, filterSources = true).forEach { resolvedLicense -> | |||
resolvedLicenseInfo.filter(licenseView, filterSources = true) | |||
.filter(ruleSet.ortResult.getLicenseChoices(pkg.id)).forEach { resolvedLicense -> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could this impact the performance of the evaluator for larger inputs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't think that this impacts the performance of the evaluator.
We renamed the function from filter
to applyLicense
as the functionality is different from the existing filters.
The peformance impact is basically to build the effective license and decompose it again which will lead to n additional loops for n Single SPDX licenses and if required to apply the choices.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If its clear that there is not performance impact fine, otherwise it'd make sense IMO to run a quick test with a large project.
/** | ||
* Return all [LicenseChoice]s for the [Package] with [id]. | ||
*/ | ||
fun getLicenseChoices(id: Identifier): List<LicenseChoice> = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assumed that in future we'll have license choices also defined elsewhere, so the license choices do not only come from the OrtResult. This is why I looked up how path excludes and license finding curations are retrieved.
I found that they get injected into DefaultLicenseInfoProvider
to be used by the LicenseInfoResolver
.
Have you considered processing license choices in a similar / analog way?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be ok for you to refactor this when other license choice configurations are added?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd actually like to also have @mnonnenmacher opinion on that as he has written the parts relevant here before diving deeper into this. I fear that it could be quite a bit of tech debt, but let's see.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, the design idea is that the LicenseInfoResolver
gets all required information from the LicenseInfo
and therefore it would make sense to also add the choices there. But I would be fine with changing this separately, because I currently cannot decide which would be the best way to integrate the choices there.
@@ -65,6 +66,23 @@ data class ResolvedLicenseInfo( | |||
) : Iterable<ResolvedLicense> by licenses { | |||
operator fun get(license: SpdxSingleLicenseExpression): ResolvedLicense? = find { it.license == license } | |||
|
|||
/** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIUC this resolved license info class has all configuration relevant for computing the needed information in its attributes. So, what's the reason for not adding an attribute for the applicable license choices to the data model?
For ResolvedLicenseLocation
there is appliedCuration
and matchingPathExcludes
there is the curations and path excludes already applied, and additionally there is the properties for what was applied. The analog thing for choices would be that choices are already applied and there is an applied choices
property?
Note: I'm haven't myself yet fully understood this area of the code, so I rather want to get the discussion going, but don't intent to say it's wrong as-is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes we thought about this.
But the license choice should only be applied to the licenses used in the evaluator and the reporter, and therefore make use of the specified LicenseView
s.
This implementation decision was a direct result of a discussion in the developers meeting on 2021-03-04, we developed it in pair programming with @mnonnenmacher.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Exactly, the problem is that the license choice can only be applied if the sub-expression matches, and if it does can depend on the used LicenseView
. So the available license choices could be provided by the LicenseInfo
as mentioned in another comment, but they can only be applied in combination with a LicenseView
, for example in the evaluator rules.
6fd7c65
to
4cddcb1
Compare
3d6b543
to
294245e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please also rebase you PR to make the new static analysis checks work.
This specifies the structure for license choices by packages in the repository configuration. Signed-off-by: Marcel Bochtler <marcel.bochtler@bosch.io>
Signed-off-by: Marcel Bochtler <marcel.bochtler@bosch.io>
The effective license filters all licenses from all sources by the LicenseView with the LicenseChoices applied. Signed-off-by: Stephanie Neubauer <Stephanie.Neubauer@bosch.io>
294245e
to
00a9507
Compare
For later use. Signed-off-by: Stephanie Neubauer <Stephanie.Neubauer@bosch.io>
The new filter applies the license choices from the ORT result to all licenses in the ResolvedLicenseInfo when using a licenseRule. Signed-off-by: Stephanie Neubauer <Stephanie.Neubauer@bosch.io>
Signed-off-by: Marcel Bochtler <marcel.bochtler@bosch.io>
Signed-off-by: Marcel Bochtler <marcel.bochtler@bosch.io>
Signed-off-by: Stephanie Neubauer <Stephanie.Neubauer@bosch.io>
00a9507
to
9a0f405
Compare
Apply license choices specified for a package defined in the repository configuration file.
The choices are used in the
licenseRule
and theStaticHtmlReporter
and applied in theeffectiveLicense
function ofResolveLicenseInfo
.Related to #3396.
CC: @neubs-bsi