The Fallout of Open Source Licensing Changes: How New Rules Are Affecting Python Projects

Open source licensing is the bedrock of Python’s ecosystem. Projects like Django, Flask, pandas, and NumPy all rely on permissive or copyleft licenses to share code freely while protecting contributors. But in recent years, the landscape has shifted. Companies behind once-open tools are rewriting the rules, and Python projects—big and small—are feeling the shockwaves.

Think about it: you build a Python app, pull in a library that says “MIT” or “Apache 2.0,” and assume you’re safe. Then, overnight, a new version appears with a license that demands payment or restricts use in production. It’s not just theoretical. Events like the Elasticsearch–AWS battle, HashiCorp’s switch to the Business Source License, and Redis changing its licensing model have sent ripples through the Python community.

Why Licensing Changes Matter for Python Developers

Python’s strength is its vast library ecosystem. A single package can bring in dozens of dependencies. When one of those dependencies changes its license, you suddenly face legal and financial risks you didn’t sign up for. This isn’t a niche problem. At PyCon 2025, one talk highlighted how a popular Python ORM was almost abandoned because its core contributor had to spend months auditing license compliance.

Here’s the real-world impact: you might be building a Python microservice for a small business, relying on a library that was GPL-licensed but later switched to a non-commercial variant. If you’re deploying to a cloud provider, you could be breaching the license without knowing. That’s a lawsuit waiting to happen.

Recent High-Profile Cases

Let’s look at concrete examples. HashiCorp, which maintains tools like Terraform and Vault, switched from MPL 2.0 to the Business Source License in 2023. Terraform is written in Go, but Python projects that use Terraform providers or automate infrastructure face license incompatibility. A PythonSkillset reader reported their CI/CD pipeline broke because a custom provider had to be rewritten to avoid BSL restrictions.

Then there’s MongoDB. It moved from AGPL to the Server Side Public License (SSPL) in 2018. Python web frameworks that depend on MongoDB drivers had to add license checks. Some projects forked the old driver to stay compliant. Package maintainers now ask: “When will this dependency change its license next?”

What You Should Check in Your Python Projects

Don’t just assume licenses are static. Here’s a practical checklist for PythonSkillset readers:

• Audit your requirements.txt or Pipfile for every direct and transitive dependency. Tools like pip-licenses or license-checker can print out licenses for all installed packages.
• Watch for “new BSD” forks—when a project switches to a restrictive license, a community fork often appears under the original permissive license. Example: the terraform-provider-aws fork from HashiCorp’s changes.
• License compatibility matters—If you use a GPLv3 library in a commercial product, you must open source your own code. Mixing GPL with MIT isn’t straightforward.
• Look at GitHub commit history for license changes. A sudden license file update in a minor version bump might be a red flag.

How PyPI and Package Maintainers Are Adapting

The Python Package Index (PyPI) hasn’t mandated license fields, but many maintainers now add License :: OSI Approved :: MIT in their trove classifiers. The Python Software Foundation (PSF) recommends using SPDX identifiers in setup.cfg. But enforcement is weak. You can upload a package claiming MIT and later change the license file.

That’s why the community is pushing for automated license scanning. New tools like pip-audit check for known vulnerabilities but not license changes. Initiatives like “Licensed” by GitHub help, but they only check what you explicitly list.

The Rise of Ethical Licensing

Some Python projects are trying a different approach: open source but with ethical clauses. For example, the “Hippocratic License” restricts use from companies that violate human rights or practice “surveillance capitalism.” While not legally tested, it shows that developers want control beyond simple permissive/copyleft divides. But for a Python developer, this creates confusion—can you use a library in your e-commerce site if your hosting provider is Amazon?

What This Means for Your Python Career

If you’re a Python developer, licensing knowledge is now a job skill. More job postings on PythonSkillset mention “open source compliance” as a requirement. In interviews, you might be asked to evaluate license compatibility in a package manager scenario. Larger companies have dedicated legal teams, but startups and freelancers often don’t.

Start learning: read the OSI’s license list, understand the difference between permissive (MIT, Apache 2.0) and copyleft (GPL, AGPL), and test your projects with pip license tools. If you maintain a Python package, choose a license early and stick to it. Changing it later erodes trust.

The Bottom Line

Open source licensing changes are not going away. They’re a natural outcome of companies trying to monetize their software while keeping a “community” label. For Python projects, this means vigilance. Don’t rely on the license you saw a year ago. Audit your dependencies, understand the implications, and be ready to fork if needed.

The PythonSkillset community thrives on open code. But open code without clear, stable rules is a ticking time bomb. Stay informed, stay compliant, and keep building.