GPL for Python Packaging ⚖

Understanding GPL for Python Packaging #

Over the last 10 years–since I started working on and with open source projects–the GPL topic has frequently come up with friends and colleagues. I simply write this post as a reminder to myself and to have something concise and clear to link to later. Also, IANAL, so if you are relying on this post, please do your own research, I have included all the links I used to make this post.

The GNU General Public License (GPL) is widely used in the open-source world, but its implications can be unclear, especially regarding Python packaging. If you develop or distribute Python software, understanding GPL variants is crucial.

What is GPL? #

GPL is a strong copyleft license—meaning software using GPL-licensed code must also be released under the GPL. There are several key variants relevant to Python:

• GPLv2 & GPLv3: These licenses require that software using GPL code (directly or indirectly) also be open-sourced under GPL upon distribution.(¹,²) If your Python application imports or depends on a GPL package, your code must adopt GPL licensing.

• LGPL (Lesser GPL): LGPL is more permissive and is usually applied to libraries. It allows proprietary software to link or import the library without forcing the proprietary software itself to adopt LGPL.(³,⁴) You just need to ensure users can replace or modify the LGPL component.

• AGPL (Affero GPL): AGPL is similar to GPLv3 but includes a critical extra clause: it applies even when users access the software remotely over a network (such as web services or APIs). If you use an AGPL-licensed Python library, your entire application must be open-sourced under AGPL, even if you’re only hosting it online.(⁵,⁶)

What Does “Linking” Mean in Python? #

GPL licenses often refer to “linking,” traditionally associated with compiled languages (e.g., C, C++). Python doesn’t link code in the traditional sense. However, it is generally agreed upon that importing a Python module counts as linking for licensing purposes.(¹,⁷) Therefore, directly importing a GPL-licensed Python package typically triggers the GPL’s copyleft requirements.

Why Does This Matter for Python Packaging? #

Python makes it easy to incorporate third-party libraries. But unintentionally using GPL-licensed libraries (especially GPL or AGPL) legally obligates you to open-source your proprietary code.

• Direct Dependencies: If you directly import a GPL-licensed Python library, your software must be GPL-licensed upon distribution.(¹,²)

• Indirect (Transitive) Dependencies: If any dependency in your Python project indirectly relies on GPL-licensed code, your entire software must also adopt GPL licensing upon distribution. Even a hidden, indirect GPL dependency triggers the GPL requirements.(⁸,⁹,¹⁰)

Recommendations #

• Check Licenses Carefully: Always verify the licenses of both your direct and indirect dependencies to prevent unintended GPL licensing obligations.(¹¹,⁷)

• Use Permissive or LGPL Licenses: When planning to keep your own software proprietary, prioritize libraries with permissive licenses (e.g., MIT, Apache, BSD) or LGPL-licensed libraries, as they allow for proprietary use without triggering GPL requirements.(³,⁴)

• Separate GPL Code: If you must utilize GPL code, explicitly separate it from proprietary code. Using subprocess calls or isolated microservices is often recommended since it counts as “mere aggregation,” not linking, thus avoiding GPL obligations.(¹²,⁷)

By clearly understanding GPL licensing implications, you can confidently manage your Python project’s dependencies and safely distribute your software.