Display package license on version info api endpoint

[leoafarias]

Problem

Pub currently accepts non-oss licensed packages. It's important to have an easy way to check a package license through the API.

Suggestion

The package license is currently displayed on the package page. That info could also be exposed on the return for https://pub.dev/api/packages/<package>/versions/<version>

[jonasfj]

Once license detection has been improved, it's been proposed for GSoC so hopefully that happens, I think we can expose the information.

[jonasfj]

There is a plan to build something this summer I imagine...

If you just want the license text, that's easy to extract from tar balls... But license detection is a bit more work, especially ensuring quality of the detected results.

[maks]

It seems the license text already appears to be available via https://pub.dev/packages/<packagename>/license but the detection of the type of the license, eg. MIT, BSD-3-Clause etc that we see on the package page on pub is the thing I would fine useful, even if its only for the say top 10 most common OSS licenses.

[sschuberth]

but the detection of the type of the license, eg. MIT, BSD-3-Clause etc that we see on the package page on pub is the thing I would fine useful

Agreed, that would help to improve Pub support in the OSS Review Toolkit. Any update on extending the API in that regard?

[leoafarias]

@sschuberth dont think they have implemented this

[jonasfj]

I can be deduced from https://pub.dev/api/packages/retry/versions/3.1.0/score

The tags field contains license: tags.

But this is only present for versions we've analyzed, so not all versions. This API is not stable.

There is also: https://pub.dev/api/packages/retry/metrics

This API will probably change in the not so distant future. But it actually has "licenses".

Beware our license detection is not perfect!

---

I think the best logic is to:

• Download the package tarball
• Extract the LICENSE file
• Run license detection on that.

This way, you control how you're detecting it.

[jonasfj]

I don't think we oppose making a stable API for this.

@isoos maybe once, we've cleaned up the pana output a bit, and we've migrated to new workers, then we can reasonably serve the output from pana as JSON. Thoughts?

[isoos]

@isoos maybe once, we've cleaned up the pana output a bit, and we've migrated to new workers, then we can reasonably serve the output from pana as JSON. Thoughts?

Yes, we need to migrate all of pana output to the result/report pair, and then we can expose it through API. I don't see any blocker on this, just a few high-priority task that we need to do before getting started on it..

[vhaidamaka]

Do we have some updates for this feature?

[leoafarias]

This is already avaiable under the /metrics endpoint. .scorecard.panaReport.licenses[0].spdxIdentifier

You can probably also parse the .score.tags

You can see something like this

tags: [
  sdk:dart,
  sdk:flutter,
  platform:windows,
  runtime:native-aot,
  runtime:native-jit,
  is:null-safe,
  is:dart3-compatible,
  license:mit,
  license:fsf-libre,
  license:osi-approved
],

[isoos]

Note: the /metrics endpoint is an internal API and is subject to change (both in content and structure). The /score endpoint is more likely to remain the same structure, but it is not a public API either. However, if anything, the /score endpoint may become a public API if there is enough interest in it.

[leoafarias]

@isoos Maybe this is an off topic, but how can people show their interest in a particular end point? Would that be an issue and up votes?