Parse license from the pom.xml if not contained in the manifest

[coheigea]

Right now, the license is only found for a Maven artifact if it's an OSGi Bundle with "Bundle-License" declared in the manifest. This PR adds functionality to also check for the license information in the pom.xml.

Running syft before on https://repo1.maven.org/maven2/eu/neilalexander/jnacl/1.0.0/ does not output any license information, with this PR for cyclonedx-json it outputs correctly:

"licenses": [
        {
          "license": {
            "name": "The BSD 2-Clause License"
          }
        }
      ],

[kzantow]

Thanks for the contribution @coheigea -- NOTE: this modifies the Syft JSON, so you'd need to update the JSON schema. Basically: bump the patch version (since this is just addition) in https://github.com/anchore/syft/blob/main/internal/constants.go#L6, run make generate-json-schema, and commit the changes.

[coheigea]

Thanks for the contribution @coheigea -- NOTE: this modifies the Syft JSON, so you'd need to update the JSON schema. Basically: bump the patch version (since this is just addition) in https://github.com/anchore/syft/blob/main/internal/constants.go#L6, run make generate-json-schema, and commit the changes.

Done thanks, I rebased the PR. Please re-run the workflows so that I can check if all the tests are fixed.

[spiffcs]

@coheigea thanks for the PR here! I really appreciate you doing the schema bump - would you mind if I added a commit that possibly makes it so we don't have to change the schema here? We might not have to add licenses to the metadata for this to work =)

We can remove the commit if we don't like it, but I think it might be advantageous to not have duplicate values across Metadata and Package.

I think we can take your code and curry the licenses up to where package creation happens and have them all accounted for on the pkg.Licenses field without having to stop off in the Metadata here.

WDYT?

[coheigea]

@spiffcs Sure, whatever works really! Let me know when the PR is updated and I'll review and test it again.

The only thing to add is that I'm working on a few follow-ups, where if the license is not defined in the pom.xml, but in a parent pom, then it will go to maven central and extract the license from the parent. So for this I would need access to the pomPropertiesObject found in guessMainPackageNameAndVersionFromPomInfo.

[coheigea]

@spiffcs Any update on getting this merged?

[coheigea]

Maybe we could just merge this and look at refactoring later? It's blocking a number of contributions I want to make to Syft to improve license detection for Maven projects.

[spiffcs]

@coheigea you're right - and huge apologies for dragging my feet on this - let me try and get these conflicts resolved and try to get this merged in for our next release

[spiffcs]

cc @wagoodman for review so we can get this into tomorrow's planned release

[coheigea]

Thanks a lot @spiffcs ! I just have a query about this line, in my PR the pomLicenses were only added if we didn't already get licenses from the Bundle-License. I'm going to contribute PRs after this is merged to reach out to Maven Central to retrieve the license if not contained in the pom, which we probably want to avoid if we already have a license from the Manifest.

[spiffcs]

Oh interesting! cc @wagoodman for the morning - we discussed this yesterday. I thought that it might be best to surface all licenses found regardless of source to provide the most information to the user (manifest or pom). @coheigea's comment makes sense though with respect to the other PRs coming. Leaving this open for @wagoodman comments

[wagoodman]

is there a reason to make this mutually exclusive? Typically we raise up as much information as is useful, and I feel that license info should be fairly unbiased. That is, if there are two licenses then knowing that they agree or disagree is useful.

[coheigea]

It's not a big deal for now, we can revisit it later if it's an issue.

[wagoodman]

Actually, I take back my comment -- today we can't distinguish paths within the jar. We have a future enhancement to the be able to capture paths within archives, but without that enhancement the licenses captured appear to be from the same location (the top-level jar path) and not a manifest vs the pom.xml. I think the results would initially be confusing without this information.

I'll restore the behavior you originally put in @coheigea such that the pom licenses are only added if the license within the manifest cannot be found. When the Location objects get this additional pathing information we could enhance this to show both licenses.

[wagoodman]

We've been talking about the Location enhancement for a while but I couldn't find an issue for it -- created #2211 to track (and linking with this comment 😄 )

[wagoodman]

I adjusted the parsing logic to preserve what the specific license data we are cataloging (name vs URL) since the pkg.License object keeps track of both separately. I also added a parser-level test to ensure this was working as expected.