Description
A recent scan of an FFmpeg project returned a composite license expression that included AND proprietary-license
in the various licenses, and that was totally incorrect, as there was no object in the codebase under any proprietary license. The culprits are two rules that are simply getting clues from configuration file documentation, and I think that these rules should simply be deleted.
-
proprietary-license_489.RULE
-
proprietary-license_490.RULE
{ "score": 100.0, "matcher": "2-aho", "end_line": 4182, "rule_url": "https://github.com/nexB/scancode-toolkit/tree/develop/src/licensedcode/data/rules/proprietary-license_489.RULE", "start_line": 4182, "matched_text": " license=\"nonfree and unredistributable\"", "match_coverage": 100.0, "matched_length": 4, "rule_relevance": 100, "rule_identifier": "proprietary-license_489.RULE", "license_expression": "proprietary-license" }, { "score": 100.0, "matcher": "2-aho", "end_line": 101, "rule_url": "https://github.com/nexB/scancode-toolkit/tree/develop/src/licensedcode/data/rules/proprietary-license_490.RULE", "start_line": 101, "matched_text": " --enable-nonfree allow use of nonfree code, the resulting libs", "match_coverage": 100.0, "matched_length": 2, "rule_relevance": 100, "rule_identifier": "proprietary-license_490.RULE", "license_expression": "proprietary-license" }
The rules are simply finding the configure instructions that the FFmpeg authors provide to anyone that wants to build FFmpeg to include proprietary code (which results in a non-redistributable build, since that is not compatible with GPL, but that's another story). But SCTK is interpreting these rules to mean that there is some software object in the codebase under a "generic" proprietary-license, when there is actually no such object in the codebase.