Closed mikegerber closed 1 month ago
click: BSD License (BSD-3-Clause)
jinja2: BSD License (BSD-3-Clause)
lxml: BSD License (BSD)
uniseg: MIT License (MIT)
numpy: BSD License (BSD)
colorama: BSD License (BSD)
MarkupSafe: BSD License (BSD-3-Clause)
ocrd: Apache License 2.0
attrs: MIT License (MIT)
multimethod: Apache Software License
tqdm: MIT License, Mozilla Public License 2.0
pytest: MIT License (MIT)
pytest-flake8: BSD License (BSD License)
(We are also not linking to it.)
pytest-cov: BSD License (MIT)
(We are also not linking to it.)
pytest-mypy: MIT License (MIT)
(We are also not linking to it)
black: MIT License (MIT)
(We are also not linking to it)
All libraries used use - to the best of my knowledge - compatible licenses. 👍
@b2m expressed interest in creating a CI job to regularly check for licensing problems (#48), so I am reopening.
My notes:
pip-licenses --allow-only="MIT License;BSD License;Apache"
(addtion of Apache is untested) seems to be an interesting approach
(Keeping it short as I am on my free day actually 😜 )
(Keeping it short as I am on my free day actually 😜 )
Free day? Same as yesterday and the day before yesterday... 😉
I have three proposals, let me know which one(s) you'd like to try:
licensed
LicenseFinder
pip-licenses
My thoughts:
I have three proposals, let me know which one(s) you'd like to try:
While having support for JavaScript is certainly interesting, the tools seem to require Bower/Yarn/or npm(?) for that, and switching to that is maybe a bit overkill for the three JS dependencies :) (Might do it anyway because of #2 someday.)
pip-licenses seems to be a simple solution for Python dependencies, so maybe try that first :+1: If it can do the license checking offline from a previously set up venv, that would be the best case.
pip-licenses
- Supports only whitelisting
I thought --fail-on
supports blacklisting, but I'd prefer whitelisting anyway.
My thoughts:
- If it is ok to only check Python dependencies I would give pip-licenses a try as the setup is quite simple.
- If you want to check the licenses of other technologies as well (like the JavaScript dependencies in dinglehopper =) I would try licensed, as the integration in GitHub already is provided.
👍 Note that we're currently using CircleCI and while I'm not super passionate about it I am super passionate about not switiching CI systems every few months ;-)
pip-licenses seems to be a simple solution for Python dependencies, so maybe try that first +1 If it can do the license checking offline from a previously set up venv, that would be the best case.
It seems to work offline!
pip-licenses seems to be a simple solution for Python dependencies, so maybe try that first +1 If it can do the license checking offline from a previously set up venv, that would be the best case. It seems to work offline!
In other words: From my point of view, this makes it suitable for the normal test suite
While having support for JavaScript is certainly interesting, the tools seem to require Bower/Yarn/or npm(?) for that, and switching > to that is maybe a bit overkill for the three JS dependencies :) (Might do it anyway because of #2 someday.)
Yes (packacking tool), Yes (overkill) and Yes (switching someday) =)
I thought --fail-on supports blacklisting, but I'd prefer whitelisting anyway.
No idea why I had this in my notes... striked it out in my original comment.
👍 Note that we're currently using CircleCI and while I'm not super passionate about it I am super passionate about not switiching CI systems every few months ;-)
Why switching? Just use all in parallel 😆
Regarding the integration of pip-licenses:
requirements.txt
changes.I've added a pre-commit hook for this in 3233dbc.
dinglehopper is Apache-licensed. All libraries used as libraries need to have a compatible license, e.g. BSD, MIT, Apache or public domain. GPL-licensed programs used seem to be fine. See also #48 for a relevant discussion.
Checklist from
requirements*.txt
: