Checksum-based review

[Ben Asher]

It would be cool if instead of pinning reviews to a version, we could instead pin to a license checksum. This way, you can freely update the version without touching reviewed libraries, as long as the cached license text hasn't changed.

[Ben Asher]

Looks like this already kind of works via the review_changed_license flag. In that case, do I really need to use versions in my "reviewed" config?

[Jon Ruskin]

What you're describing would be interesting, but would likely require a new licensed CLI command to change the configuration file on disk to avoid users needing to be aware of checksum calculations. In order to keep the tool simple this isn't something that's been considered in the past in general purpose usage. It wouldn't be the worst thing in the world, but without clear value I'm not sure it's worth bringing that additional complexity

In that case, do I really need to use versions in my "reviewed" config?

Which language or package manager are you using? Specifying versions in the "reviewed" config is generally only required for enumerating dependencies from sources that allow for multiple versions of the same dependency to be used. Currently only the pnpm source requires reviewed and ignored config entries to include version information, but this could also apply to npm and other sources.

Even when version information is required for a specific source, you can still set @* to match all versions of a dependency.

[Ben Asher]

I'm using the yarn source. I think the answer is I can safely do <package>@* for all of my reviewed packages, since if the license changes when upgrading (even with multiple versions in play), the review_changed_license will be set, right?

[Jon Ruskin]

Yep, if the license changes when upgrading then the review_changed_license flag should be set. If that doesn't happen as expected let me know, that sounds like it would be a bug or other unexpected behavior that should be fixed 🙏 .

Are you getting any errors when you leave out the @*? You shouldn't have to specify a version for yarn dependencies in the configuration file, so if you do that would also be a bug that should be fixed.

[Ben Asher]

Nope confirmed removing @* works! Just an oversight on my end.

For checksum-based review, one way to do it might be to have a global configuration that enables this "checksum mode", and then for all dependencies + matching reviewed/ignored dependencies, the cache will store the license based on its checksum rather than per dependency version. The checksum can live in the cache, where users can largely ignore it.

[Jon Ruskin]

@benasher44 I'm still not entirely sure how this improves general usage of licensed, and I'm hesitant to make any changes to the tool without clear value.

I have a few concerns around checksums that I'd be curious to get your thoughts on. This is mostly from the user experience perspective, I don't have too many concerns about what an implementation would look like.

1. if the checksum is used as the 'version' of a dependency, we lose version information which can be important from a reporting perspective if there are any requirements that all versions of a dependency are reported
2. if the checksum is not used as the 'version' of a dependency, there is increased complexity in the configuration and runtime in order to enable checksums logic
3. checksums are nice when there is only one checksum to manage. It's potentially worse from a usage perspective to have users input <dependency>@<checksum> compared to <dependency>@<version range>. Checksums are non-human-meaningful strings to humans because there are no clear semantics behind the checksum and no way to predict how they will change.
   • The alternative to having users manually update their configuration lists with checksum values is to introduce a new CLI option like licensed review <dependency>. We might still need to uniquely identify one of multiple versions of a dependency in use to mark as reviewed, in which case we're either using the dependency version or the dependency checksum. This doesn't feel too different (at least to me 😂, maybe different for you!) to manually update the configuration file in a similar way, and might still require humans to interact with checksums.

Also, Licensed already does an ok job of not pestering users about version updates if the license contents don't change. Just because I don't see the value yet though doesn't mean it's not there, so I'm curious if you have further thoughts 🙏

[Ben Asher]

No I think you're right. I think right now if you just don't add version requirements in you reviewed list, you basically get what I'm looking for (only pestered if license changes). Will close for now and reopen if I have a better case after using this some more. Thanks for your time!