slog historical license information is incorrect

[johnbatty]

Describe the bug
In the crate versions view, each version is displayed with the license of that version.
When looking at the slog crate where I know the licensing changed, the displayed licenses do not match the older crate license declarations.

To Reproduce
Steps to reproduce the behavior:

1. Observe that the initial release of slog (0.6.0) was released under the MPL-2.0 license:
   • https://github.com/slog-rs/slog/blob/v0.6.0/Cargo.toml#L7
2. Observe that from slog version 2.0.5 the license declaration changed to MPL-2.0/MPL/Apache-2.0:
   • https://github.com/slog-rs/slog/blob/v2.5.0/CHANGELOG.md#205---2017-05-15
   • https://github.com/slog-rs/slog/blob/v2.0.5/Cargo.toml#L8
3. View the slog version list at crates.io, and observe that the versions prior to 2.0.5 are incorrectly shown with a license of MPL-2.0 OR MIT/Apache-2.0, rather than the expected MPL-2.0.

Expected behavior
slog versions prior to 2.0.5 should be shown with a license of just MPL-2.0

Desktop (please complete the following information):

• OS: Windows 10 Enterprise
• Browser: Microsoft Edge
• Version: 91.0.864.48

[Turbo87]

thanks for reporting this @johnbatty. I can reproduce it, but it looks like it is a bug in the backend. I've just used https://crates.io/crates/cargo-download to cargo download slog==2.0.2 > slog-2.0.2.gz and I can confirm that the Cargo.toml in that tarball reads license = "MPL-2.0". https://crates.io/api/v1/crates/slog/2.0.2 however shows "license": "MPL-2.0/MIT/Apache-2.0", so something must have gone wrong 🤔

I'll put it on the agenda for the team meeting tomorrow.

[carols10cents]

Licenses used to be stored on a per-crate basis, then later we changed them to be stored per-version. If this crate's license change happened before we stored per-version licenses, it will be incorrect: we did not go through all old crate versions and untar each .crate file looking for mismatched versions.

[Turbo87]

interesting, that certainly explains it. I'll keep it on the agenda for tomorrow to discuss whether such a retroactive fix might be useful.

[johnbatty]

@carols10cents Thanks for the explanation - makes sense. This is not a big issue for me - I just noticed it was wrong and wanted to flag the fact in case there was a more serious bug in crates.io.

I'd guess there aren't many crates that changed their licensing pre-2017, and probably even fewer people who look up old license versions via crates.io!

[Turbo87]

It looks like #787 is the PR that introduced this, so all the versions that were created before this PR was merged are potentially affected. Since the PR is from 2017 I guess that means it's not actually all that many versions and it might be possible to fix it 🤔

[Turbo87]

I ran some analysis on the database dump and the tarballs and we have 6481 affected versions: https://gist.github.com/Turbo87/3a6d47a761a9c3ff2541987c0f624f3b

[Turbo87]

Summary from the team meeting today:

• We need to investigate how to temporarily disable the updated_at update triggers
• Afterwards we can run the SQL script on the production database through the Heroku CLI

[Turbo87]

the SQL script ran to completion and the issue should now be fixed. https://crates.io/crates/slog/versions shows only MPL-2.0 now for sub-2.0.5 releases :)

[johnbatty]

@Turbo87 Great work! Thanks very much for making this fix happen!