Conversation
a12d7f3 to
eed9a61
Compare
|
|
||
| val spdxExpression = processedLicenses.values.toSet().filter { | ||
| it.toString() != SpdxConstants.NONE | ||
| val spdxExpression = processedLicenses.values.toSet().filterNot { |
There was a problem hiding this comment.
Shouldn't this say filter {} to keep isPresent?
And while at it, how about simplifying this to .filterTo(mutableSetOf())?
eed9a61 to
2c24fc1
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #12465 +/- ##
=========================================
Coverage 59.21% 59.21%
Complexity 1892 1892
=========================================
Files 366 366
Lines 13839 13839
Branches 1462 1462
=========================================
Hits 8195 8195
Misses 5114 5114
Partials 530 530
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
It does not make sense to include `NOASSERTION` into the declared license. So, adjust the filter condition for clarity. `NOASSERTION` in detected licenses have only been observed for Cargo, see also the updated test expectations. While at it, simplify and clarify the deduplication by using `filterTo()`. Signed-off-by: Frank Viernau <frank.viernau@gmail.com>
2c24fc1 to
2de6736
Compare
| - "NOASSERTION" | ||
| declared_licenses_processed: | ||
| spdx_expression: "Apache-2.0 OR MIT OR NOASSERTION" | ||
| spdx_expression: "Apache-2.0 OR MIT" |
There was a problem hiding this comment.
Hmm. This required test change made me think about this again:
I agree that it's highly unlikely for someone to declare a license of NOASSERTION, and that it's not very meaningful to do so.
But if someone still does it, maybe to express "there is some license without an SPDX ID" (due to that someone being unaware of the LicenseRef mechanism), is it then really correct for us to omit that information?
I guess it's better to play safe and not omit this after all.
There was a problem hiding this comment.
This test failure also made me look into the code again.
I found that NOASSERTION and NONE can have two sources:
- Written in the definition file (I haven't seen this myself)
- Added by an ORT package manager, for the sake of indicating something.
Examples for 2 are:
ort/plugins/package-managers/cargo/src/main/kotlin/CargoDependencyHandler.kt
Lines 143 to 151 in 4f2651f
ort/plugins/package-managers/node/src/main/kotlin/NodeUtils.kt
Lines 95 to 103 in 4f2651f
Given that my commit does not make sense.
However, this seemed to uncover an are for improvement / clean-up.
Simply from reading the code, the following should not have any effect
// NPM does not mean https://unlicense.org/ here, but the wish to not "grant others the right to use
// a private or unpublished package under any terms", which corresponds to SPDX's "NONE".
declaredLicense == "UNLICENSED" -> SpdxConstants.NONE
as NONE gets filtered out by the DeclaredLicenseProcessor.
This has to do with NONE being also use as means for discarding a declared license, see
#3038.
There was a problem hiding this comment.
While mapping UNLICENSED to NONE makes sense to me,
mapping to NOASSERTION could be changed to keep the original string.
For node a single file is referenced, for example
SEE LICENSE IN LICENSESEE LICENSE IN Readme.md
For Cargo also a single file can be referenced.
I wonder if it would be cleaner to introduce dedicated fields and use them in Package.kt
data class RawDeclaredLicense(
val licenses: List<String>,
val fileReferences: List<String>,
val operator: SpdxOperator = SpdxOperator.AND
)
This would have clearer semantics, but it would require means to map a file reference to a license using a curation (which should not be hard to do). Furthermore, adding the operator would allow to re-compute the
processed license without this hack:
ort/model/src/main/kotlin/PackageCurationData.kt
Lines 157 to 169 in 4f2651f
What do you think about this @sschuberth ?
Or instead of fileReferences we could by convention use the current List<String> approach and
use the from SEE LICENSE IN $filepath, to not introduce a new mechanism. Benefit is, that it is obvious what it is about while NOASSERTION is unclear.
There was a problem hiding this comment.
NONEgets filtered out by theDeclaredLicenseProcessor.
But isn't that exactly what we want for the "NPM does not mean https://unlicense.org/" case? Because that makes declaredLicensesProcessed empty, i.e. no declared license, which is exactly what "unlicensed" is supposed to mean.
While mapping
UNLICENSEDtoNONEmakes sense to me
Ok, seems we're on the same page here.
mapping to
NOASSERTIONcould be changed to keep the original string.
One problem we had with this is in past is that users then need to deal with each original string separately, instead of e.g. just disregarding everything that is "NOASSERTION" / not a concrete license.
Pull request was converted to draft
Related to #11459.