Overview

Delivers ANE-2297

When we show license results from an archive that we find using a first-party license-scan or a vendored dependency, we do not show the archive filename in the license path. This can make it hard for the user to figure out where the license is actually coming from.

For example, if I have an archive in vendored/files/random-name.zip that unzips to a directory called tools, the path that we show to the user will look like vendored/files/tools/LICENSE.txt.

It would be better if the path was vendored/files/random-name.zip/tools/LICENSE.txt, which lets the user know exactly where that license was found.

This PR fixes that for first-party license scans and CLILicenseScan style vendored dependencies. It does not fix it for ArchiveUpload style vendored dependencies.

Unfixed:

Fixed:

Acceptance criteria

• We include the archive file in the path to a license found in an archive when scanning a vendored dependency or doing first-party license scans

Testing plan

Here is an example project to test with:

licenses-in-zip.zip

It includes two vendored dependencies. One that is just a directory containing an MIT license. The output from this should be unchanged. The other is a zip file that contains a BSD-3 license.

├── fossa-deps.yml
└── vendored
    ├── directory
    │   └── tools
    │       └── mit.LICENSE
    └── file
        └── random-name.zip

vendored-dependencies:
  - name: from-directory
    version: 1.0.0-unfixed
    path: vendored/directory
  - name: from-file
    path: vendored/file
    version: 1.0.0-unfixed

Scan it with the current production release of fossa. You'll see that the path to the BSD-3 license looks like the "unfixed" screenshot above.

Then scan with this branch. The path to the BSD-3 license should now look like the "fixed" screenshot above.

You can also see the difference using fossa license-scan fossa-deps. Look for the path to the BSD-3 license. For fossa, it will be "vendored/file/tools/bsd-new.LICENSE". For fossa-dev it will be "vendored/file/random-name.zip/tools/bsd-new.LICENSE".

Now repeat that with a first-party license scan.

mv fossa-deps.yml fossa-deps.yml.bak
fossa-dev analyze --experimental-force-first-party-scans --revision fixed-first-party-scans

You should once again see that the path to the BSD-3 license looks like the "fixed" screenshot above.

Risks

I did not fix this for ArchiveUploads, but I think that's okay. It will give us another reason to move customers to ArchiveUploads.

This will change the output we provide, which may surprise users. I think it's what we should have done in the first place, though, so I think the change is worth it.

Metrics

References

ANE-2297

Checklist

• I added tests for this PR's change (or explained in the PR description why tests don't make sense).
• If this PR introduced a user-visible change, I added documentation into docs/.
• If this PR added docs, I added links as appropriate to the user manual's ToC in docs/README.ms and gave consideration to how discoverable or not my documentation is.
• If this change is externally visible, I updated Changelog.md. If this PR did not mark a release, I added my changes into an ## Unreleased section at the top.
• If I made changes to .fossa.yml or fossa-deps.{json.yml}, I updated docs/references/files/*.schema.json AND I have updated example files used by fossa init command. You may also need to update these if you have added/removed new dependency type (e.g. pip) or analysis target type (e.g. poetry).
• If I made changes to a subcommand's options, I updated docs/references/subcommands/<subcommand>.md.