Prompted by Emlyn's review comment on #404 flagging that DINOv2's pretrained weights were originally released under a non-commercial license (CC BY-NC 4.0) before later moving to Apache 2.0. Pinning the DINOv2 weights version (tracked separately, in review discussion on #404) addresses that specific case, but there's currently no automated check that a declared PyPI dependency doesn't carry a license that's incompatible with the intention of PyOPIA's own permissive BSD3 license.
Proposal: add pip-licenses as a dev dependency, plus a CI step that fails the build if any dependency's license matches GPL/AGPL/LGPL/Commons Clause/Non-Commercial/SSPL/Business Source License (using --partial-match, since these tools match license strings exactly by default, not as substrings).
Findings from testing this locally:
docutils needs an explicit --ignore-packages exception - its PyPI metadata reports a compound license string that includes GPL, from a couple of bundled non-code files, even though the actual code is BSD.cmocean and namex (both real PyOPIA dependencies) don't declare any machine-readable license on PyPI at all. Manually confirmed MIT and Apache 2.0 respectively, directly from their source repos - this check can't verify that automatically since neither package declares it themselves.- PyOPIA itself didn't declare its own license in packaging metadata either - fixing that (
license = "BSD-3-Clause" in pyproject.toml) is included as part of this issue.
Note: this check only covers declared PyPI dependencies (pyproject.toml/uv.lock). It doesn't cover runtime-downloaded artifacts like the DINOv2 weights, which aren't a Python package at all - that risk needs a different mitigation (version pinning), discussed separately on #404.
Prompted by Emlyn's review comment on #404 flagging that DINOv2's pretrained weights were originally released under a non-commercial license (CC BY-NC 4.0) before later moving to Apache 2.0. Pinning the DINOv2 weights version (tracked separately, in review discussion on #404) addresses that specific case, but there's currently no automated check that a declared PyPI dependency doesn't carry a license that's incompatible with the intention of PyOPIA's own permissive BSD3 license.
Proposal: add
pip-licensesas a dev dependency, plus a CI step that fails the build if any dependency's license matches GPL/AGPL/LGPL/Commons Clause/Non-Commercial/SSPL/Business Source License (using--partial-match, since these tools match license strings exactly by default, not as substrings).Findings from testing this locally:
docutilsneeds an explicit--ignore-packagesexception - its PyPI metadata reports a compound license string that includes GPL, from a couple of bundled non-code files, even though the actual code is BSD.cmoceanandnamex(both real PyOPIA dependencies) don't declare any machine-readable license on PyPI at all. Manually confirmed MIT and Apache 2.0 respectively, directly from their source repos - this check can't verify that automatically since neither package declares it themselves.license = "BSD-3-Clause"inpyproject.toml) is included as part of this issue.Note: this check only covers declared PyPI dependencies (
pyproject.toml/uv.lock). It doesn't cover runtime-downloaded artifacts like the DINOv2 weights, which aren't a Python package at all - that risk needs a different mitigation (version pinning), discussed separately on #404.