Consider relicensing to a permissive license (MIT/Apache-2.0) for enterprise adoption

[dinesh-bay]

pytest-rerunfailures is licensed under MPL-2.0 (Mozilla Public License 2.0). While MPL-2.0 is an OSI-approved open source license, its copyleft provisions create adoption barriers in enterprise environments.

From pyproject.toml:
license.text = "MPL-2.0"

Why This Matters

Enterprise organizations running security/license scanners (Snyk, Black Duck, FOSSA, WhiteSource) commonly have policies that flag or block MPL-2.0 dependencies because:

1. File-level copyleft: Any modifications to MPL-2.0 licensed files must be released under the same license
2. Distribution triggers: Distributing the software (e.g., in Docker images, CI pipelines, packaged test frameworks) can trigger compliance obligations
3. Legal review overhead: Each MPL-2.0 dependency typically requires legal review and an exception approval process

In practice, this means teams that want to use pytest-rerunfailures in enterprise CI/CD pipelines either:

• Go through a lengthy legal exception process
• Build custom retry plugins from scratch to avoid the dependency

We chose the latter — building a ~190-line custom retry plugin that reimplements the core functionality (--reruns, --reruns-delay, per-test @pytest.mark.flaky) using pytest_runtest_protocol and
runtestprotocol. It works, but it's duplicated effort that wouldn't be necessary under a permissive license.

Context: The pytest Ecosystem is Permissive

Most of the pytest plugin ecosystem uses permissive licenses:

  ┌──────────────────────┬──────────────────────┐
  │       Package        │       License        │
  ├──────────────────────┼──────────────────────┤
  │ pytest               │ MIT                  │
  ├──────────────────────┼──────────────────────┤
  │ pytest-xdist         │ MIT                  │
  ├──────────────────────┼──────────────────────┤
  │ pytest-html          │ MPL-2.0 (same issue) │
  ├──────────────────────┼──────────────────────┤
  │ pytest-playwright    │ Apache-2.0           │
  ├──────────────────────┼──────────────────────┤
  │ pytest-asyncio       │ Apache-2.0           │
  ├──────────────────────┼──────────────────────┤
  │ pytest-cov           │ MIT                  │
  ├──────────────────────┼──────────────────────┤
  │ pytest-mock          │ MIT                  │
  ├──────────────────────┼──────────────────────┤
  │ pytest-timeout       │ MIT                  │
  ├──────────────────────┼──────────────────────┤
  │ pytest-rerunfailures │ MPL-2.0              │
  └──────────────────────┴──────────────────────┘

pytest-rerunfailures is one of the few popular pytest plugins that uses a copyleft license. This creates friction for teams that can freely use the rest of the ecosystem.

Suggestion

Consider relicensing to MIT or Apache-2.0 to align with the broader pytest ecosystem and remove enterprise adoption barriers.

This package has no transitive dependencies beyond packaging and pytest itself (both permissive). A license change would have no upstream implications.

I understand relicensing requires consent from all contributors, and this may not be a simple change. But given the package's role as essential testing infrastructure, a permissive license would
significantly broaden adoption in enterprise environments where license compliance is non-negotiable.

Our Workaround

For reference, we built a custom replacement (~190 lines) that provides:

• --retries N CLI flag (equivalent to --reruns)
• --retry-delay CLI flag (equivalent to --reruns-delay)
• @pytest.mark.retry(count=N) marker (equivalent to @pytest.mark.flaky)
• Full protocol re-run (setup + call + teardown) so Playwright fixtures get fresh browser contexts

This works but represents duplicated community effort.

Environment

• pytest-rerunfailures 16.1
• Python 3.13
• Snyk enterprise license policy (blocks MPL-2.0)

[icemac]

I understand relicensing requires consent from all contributors, and this may not be a simple change.

This repository has a history going back until 2012. During this time it had 58 contributors (including 1 bot) (source). I have very little hope that all of them will agree to a license change. But you can try to get their consent. I think it is enough to prepare a sentence that each contributor has to paste here as issue comment to give their consent to the license change. When all consents are gathered I'd be happy to change the license.
Keep in mind: I am just the maintainer who has taken over this project from @klrmn years ago and changing the license is something I can do. But I neither have the time nor energy to bring this process forward.

[klrmn]

i have no objections...didn't know much about licensing when i did it, and still don't. i'm pleased it's still being used.

[dinesh-bay]

Thanks, @klrmn. I absolutely love it and with Playwright _ rerunfailure - both are top notch.

@icemac I believe getting consent from all 58 contributors'(not sure whether they got this message) is a time talking and low confidence one. Do we have any other option as Leah also agreed. Can you update the license. From my perspective, I don't think it's gonna negatively affect any rather positive.

[webknjaz]

AFAIK, all the contributors of substantial patches are copyright holders. They contributed things under a certain license and a maintainer cannot arbitrarily say that they actually allow use under incompatible licenses without asking them. This is why big tech companies demand signing CLA before accepting contributions so that they can get away with this without asking the contributors and do whatever they please.

---

On a related note, there's the recent drama with chardet that claimed that original copyright doesn't apply to LLM-generated reimplementation and changed it despite the original author objecting (and a bunch of other concerns being raised).

[dinesh-bay]

Thanks, @webknjaz for helping me to understand how this works. I'm new to this and I knew now about all of this.

Sure, we will wait for all contributors to respond.

[webknjaz]

More ctx: https://opensource.guide/legal/#what-if-i-want-to-change-the-license-of-my-project / https://choosealicense.com/appendix/ / https://choosealicense.com

[icemac]

@dinesh-bay Do not expect that all needed contributors will see this ticket. Getting a consent form all of them will be a bit more footwork like directly contacting them or mentioning them, maybe in an ticket with shorter text, so it is actually read. But I think you'll find out what to do here.