reactive-firewall
commented
2 weeks ago 🙊 I like the idea too, but what happens regarding incompatibilities logic? Is there a known solution? EDIT: Possibly: https://github.com/pilosus/pip-license-checker
- does an apache 2.0 licensed dependency in a GPLv3 project pass as both are OSI-approved? or fail because the licences are actually incomparable as apache states? I can see a case for both.
- Do un-attributed CC 4 by attribution count as a fail or pass? The license is quite permissive, but requires some attribution. How would one test this?
- How would users input the compatibility options?
I don't think these are un-answerable questions, but I do acknowledge the significant challenges involved.
I suggest an intermediate feature to align with the idea here:
It would be an improvement to have some common built in whitelist values, for example instead of needing to input '--allow-only=' followed by the whole OSI-approved licenses it would be wonderful to just use a new option like '--match-only-from=OSI' and --match-only-from=GPL. This should be aligned with the current available options and simply enhances usage, and readability.
other considerations:
- toml based configurations to write the whole allow-only list in a config or similar
- lists that combine fail-on with allow-on logic based on the target of the list (complex)
- would need a new input for target in logic (for the compatibility target)
- would need to handle unknown cases somehow (pick one can't have both)
- defining a "compatibility" scope as input (even if just arbitrary scope or no compatibility scope option would help)
🙈 Hopefully this helps.
Feature proposal
Check OSS license compatibility, optional fail-on for incompatible licenses OSI-approved licenses would be sufficient, or at least the most popular list: https://opensource.org/licenses
Reference: https://dwheeler.com/essays/floss-license-slide.html https://www.whitesourcesoftware.com/resources/blog/license-compatibility/ https://www.gnu.org/licenses/license-list.html