Remove unreachable duplicate LGPL key in rubygems licenses mapping

[aishwary-dongre]

Fixes #5314

Brief description

LICENSES_MAPPING in src/packagedcode/rubygems.py declared 'LGPL' twice on consecutive lines:

'LGPL': 'lgpl',
'LGPL': 'lgpl-2.0-plus',

A dict literal keeps only the last value for a repeated key, so 'LGPL': 'lgpl' was dead at import time and a bare LGPL gem declaration already resolved to lgpl-2.0-plus.

Why the unreachable line is the one removed

The issue notes that which of the two applies is currently decided by line order rather than intent, so I looked for evidence of which is correct rather than picking one:

• lgpl is not a ScanCode license key. There is no lgpl.LICENSE under src/licensedcode/data/licenses/ or src/licensedcode/data/inactive/. Checking every target in this mapping against the license data, 'LGPL': 'lgpl' is the only entry of the 32 that does not resolve to a real key.
• The mapping never uses bare family keys. 'GPL': 'gpl-2.0', 'BSD': 'bsd-new' and 'Apache': 'apache-2.0' all map bare family names to a concrete license. (gpl is likewise not a key.)
• Both lines arrived together. git log -L 676,681:src/packagedcode/rubygems.py shows both were added in b2a5a5a ("Recognize .gem archives as packages", 2019), which reads as an accidental duplicate rather than a deliberate override.

So removing 'LGPL': 'lgpl' deletes a line that could never have worked, and license detection behaviour is unchanged.

Whether a bare LGPL declaration should imply lgpl-2.0-plus at all is a separate question about license semantics, and I have deliberately left it out of scope. Happy to open a follow-up issue if you think the unversioned case warrants a different target.

Test

Added TestRubygemsLicensesMapping in tests/packagedcode/test_rubygems.py. The duplicate-key check has to parse the module source with ast, because a duplicated key is silently collapsed and cannot be observed on the loaded dict. I confirmed it fails before the fix (duplicated keys still present: ['LGPL']) and passes after.

On local test runs

I could not run the suite locally. requirements.txt pins extractcode-7z==16.5.210531, but only 16.5.210525 is on PyPI, so ./configure --dev fails to resolve:

ERROR: Could not find a version that satisfies the requirement extractcode-7z==16.5.210531
       (from versions: 16.5.210525)

That looks like a pre-existing packaging problem independent of this change; let me know if it is already tracked or if you would like a separate issue. I verified the new tests' assertions standalone against the module source instead, so I am relying on CI for the real run. Please do flag anything that comes back red.

I also left the existing ruff and isort findings in these two files alone, to keep a one-line fix from turning into unrelated import churn. No CHANGELOG.rst entry since there is no user-visible change, but glad to add one if you prefer.

AI generation disclosure

I used an AI assistant while investigating this. The duplicate-key detection, the license-key cross-check, and the git log -L archaeology were done with its help, and it drafted the test and this description. I have reviewed and verified every claim above against the repository myself and can explain and defend the change. Flagging it since ScanCode has no stated policy either way and I would rather be upfront.

Tasks

• Reviewed contribution guidelines
• PR is descriptively titled 📑 and links the original issue above 🔗
• Tests pass -- see the section above; blocked locally by the extractcode-7z pin, relying on CI
• Commits are in uniquely-named feature branch and has no merge conflicts 📁
• Signed off (DCO)
• Updated documentation pages (not applicable)
• Updated CHANGELOG.rst (not applicable, no user-visible change)