Unify api for license results: License, LicenseFileDetails, ImportedModuleData

[vlsi]

There are three classes meaning holding pretty much the same information. It would be nice if those could be unified somehow.

[guenhter]

@Sortable(includes = "name")
@Canonical
class License {
    String name
    String url
    String distribution
    String comments
}

@Sortable
@Canonical
class LicenseFileDetails {
    String file
    String license
    String licenseUrl
}

@Sortable
@Canonical
class ImportedModuleData {
    String name
    String version
    String projectUrl
    String license
    String licenseUrl
}

[guenhter]

Hm, you think it's worth to unify those classes?

[vlsi]

@guenhter , frankly speaking, I have no idea. I started using G-L-R for apache/jmeter, and my immediate thought was "those pom licenses, imported licenses, manifest licenses are overlapping".

However, it looks like implementing the API is challenging.

For instance: there's SPDX license database, so things like License.Apache_2_0 would be nice to have. Which means License should be interface or something behind those lines.

Then: even in case software declares "license is BSD-3-Clause", then the actual file will likely be different (year and copyright owner would be replaced with actual values), so it should be like "license flavour==BSD-3-Clause, actualFile=...". Note: single artifact might include multiple license/notice files (e.g. in case jar file bundles other jar files with their own licenses). It looks like LicenseFileDetails represents actual license file, however it is not clear where is the relation between LicenseFileDetails and License. It is not clear why LicenseFileDetails#license is of type String.

[jct-tympanon]

commenting on this old issue, but it's still relevant.

the main advantage to unifying the data model is so that filters and allow rules work the same for both imported modules (say from NPM) and gradle dependencies.

For example, right now there is no easy way to represent imported dual-licensed modules. if you use an "allowed licenses" list, gradle modules get a logical-OR behavior for checkLicense. but if your importer generates one instance of ImportedModuleData per license (like NpxLicenseCheckerImporter), then checkLicense acts like logical-AND. the difference in behavior between gradle and NPM modules is mysterious unless you read the code.

[vlsi]

For reference, I've ended up with https://github.com/vlsi/vlsi-release-plugins/tree/master/plugins/license-gather-plugin

For example, right now there is no easy way to represent imported dual-licensed modules

On top of that, Maven's pom.xml can have multiple entries for <license>, and it does not clarify if that means "one of the listed licenses" or "all the listed licenses". On top of that, there are cases when pom.xml and dependency artifacts miss or misstate the license.

In my plugin I play safe and I treat "multiple detected licenses" as "all them are required", see https://github.com/vlsi/vlsi-release-plugins/issues/50#issuecomment-1010731908 At the same time, there's a way to configure an override

---

Regarding the API, it looks like "the official API" should come from https://github.com/spdx/Spdx-Java-Library, however, the current state of "spdx-java-library" looks like too bloated to me, and it does not look like an attractive API to use :-/

[jct-tympanon]

thanks @vlsi i'll take a look. the main thing that brought me to GLR is the support for aggregation (via importers). I have a polyglot build system with significant components written in Typescript, Java, and Rust. being able to report and check compliance in one place is pretty nice.

and yeah license metadata has serious quality issues. different authorities report different licenses for the same package, and some package authors release their package under Apache while they have dependencies that are GPL.