Fail your build automatically for legal reasons
Tags: python, devops, legal, license
Published: 2024-01-23 13:15:24

> Cover image by <a href="https://pixabay.com/users/myrfa-3126475/?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=1614223">Ag Ku</a> from <a href="https://pixabay.com//?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=1614223">Pixabay</a>

Nowadays almost every programming project uses dependencies, often open source. Each of these dependencies has its own license. If you launch your project you need to make sure all licenses are okay to use for you.

In this article, I will show you how to set up a fully automatic step in your build pipeline for Python projects.

In an earlier project of mine, I showed how 8000 Python packages do not have GNU GPL but do depend on a package using GNU GPL. This might* be fine for the package itself but if you use this package in enterprise software, you just created a product that uses GNU GPL.
**This is not tested in a court as far as I know, and every court of every country, state, county, federation, etc. could rule differently. Consult a lawyer if you need legal advice, not a random article on the internet.*

This continues on [**8000+ python packages might have to change to GNU Public License**](https://dev.to/wagenrace/8000-python-packages-might-have-to-change-to-gnu-general-public-license-1000)

To avoid this I will show 2 different ways of testing this; testing just your installed environment after building, and testing your full docker image before shipping. I will show it with GitHub actions and Jenkins.

## General setup

We are going to use the Python package [license-scanner](https://pypi.org/project/license-scanner/). This package will look at the `pyroject.toml` for whitelisted licenses and packages. It works by finding ALL packages installed in the Python environments and checking if the license or the package is whitelisted. If one or more packages do not pass this test an error will be raised.

Below is an example, it contains a common list of licenses that can be used in commercial software.
{% gist https://gist.github.com/wagenrace/200b36d100298cc477e80e19f793f505.js %}
To test this locally, navigate to the folder of `pyroject.toml` and run `license_scanner -m whitelist`.

## Github action: Check dependencies of my package

When you build a package you want to do this step automatically, but you also only want to test the dependency and not build or test tools. To avoid it, install the dependencies using pip install -r requirements.txt or via pip install .. Now run the license scanner and after that install other tools like pytest or build if needed.
{% gist https://gist.github.com/wagenrace/b5883a92fc9136a49f9f960ca9fefbd9.js %}
## Jenkins: check a full docker image

If you are deploying a docker image as a product, it is better to test the entire docker image. To avoid cluttering the docker with test code we create a test docker based on the production docker we want.

Create a file named Dockerfilelicensescan and populate it as below. Note how the image we build from is variable.
{% gist https://gist.github.com/wagenrace/9f574c864f9bbbd389931ef149f6ba5f.js %}
To your build pipeline (Jenkins in this example) we add the build step and a test step. In the test step, we build the docker test image based on the docker production image. After that, we just run the container. If an exception is raised the build pipeline will fail.
{% gist https://gist.github.com/wagenrace/4b7cee3068b1621b8a9fbed31ea043e8.js %}
## Conclusion

It is relatively simple to set up an automatic way to check your Python licenses. The hard part is to find out what licenses you can use within your project or to refactor your code if a dependency uses a license you want to avoid.