PM4Py: process mining in Python, and the AGPL line you have to notice
Official public repository for PM4Py (Process Mining for Python) — an open-source library for exploring, analyzing, and optimizing business processes with Python.
At a glance
- What is it?
- PM4Py is an AGPL-3.0 Python library for reading event logs, discovering process models and checking conformance. It is the right tool for research and open-source work, and a licensing decision first for anyone shipping closed-source software.
- Who is it for?
- Adopt PM4Py if your event logs are already in XES or convertible to it and your code can carry AGPL-3.0, which rules out most closed-source products without a commercial licence from Process Intelligence Solutions. Skip it if your data lives in a warehouse you cannot export from, or if you need a hosted analyst-facing tool rather than a library.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 15 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What PM4Py actually does with an event log
PM4Py turns recorded process events into formal models. The input is an event log, typically XES, where each case has a sequence of activities with timestamps. The README's first example shows the whole shape of the library in three lines: read_xes loads the log, discover_petri_net_inductive returns a Petri net plus an initial and a final marking, and view_petri_net renders it as SVG. That is process discovery: inferring a control-flow model from observed behaviour rather than asking someone to draw it. The same object model supports the other standard process mining tasks in the library, such as conformance checking of a log against a model and the analysis of object-centric event logs through the ocel extra. The audience is narrow but real. Researchers who need to reproduce published algorithms in Python, and engineers who have an event log sitting in a database and want a model of what the system actually does, as opposed to what the workflow diagram claims it does. The repository description names exploring, analyzing and optimizing business processes, and the library is maintained by PIS, a spin-off from Fraunhofer FIT where it started.
The Petri net is the pivot of the API
The design choice worth understanding is that discovery returns a Petri net, not a diagram. A Petri net is a tuple of places, transitions and arcs, and the API hands it back as three separate values: net, initial_marking, final_marking. Those three travel together into every downstream call, including the visualization step. That matters because the marking is what makes the model executable. A conformance check needs to know where a case starts and where it is allowed to end, and the marking supplies exactly that. It also means the output is inspectable and serializable rather than a picture you have to eyeball. Inductive discovery is the algorithm in the README example, and it is a reasonable default for logs with noise because it builds a process tree first and derives the net from it. If your log contains loops, the model will contain them too, which is the point: you are measuring the process, not the intention behind it.
Installing PM4Py and choosing extras
The base install is one command: pip install -U pm4py, on Python 3.9 through 3.14 according to the README. Everything beyond mainstream usage is grouped into extras in pyproject.toml, and you opt in by name. pip install -U "pm4py[polars,ml]" adds Polars dataframe support plus pyemd and scikit-learn. pip install -U "pm4py[all]" pulls every optional feature supported on the current platform, which is convenient on a laptop and a poor idea in a container you have to rebuild. The extras listed are calendars (workalendar), connectors (requests), llm (openai and requests), ml, ocel (jsonschema and pyarrow), polars, solvers (cvxopt), visualization (pyvis) and windows (pygetwindow, pynput, pywin32, Windows only). If you want the dependency versions the project itself validates in CI, install pm4py[stable] instead of pinning by hand. For a source checkout the README gives python -m pip install -e ., and build, CI and lint dependencies are standard dependency groups, for example python -m pip install --group lint. Python 3.8 is not in the main support list; the README points to third_party/old_python_deps/requirements_py38.txt for that environment, which tells you it is a legacy path rather than a supported one.
AGPL-3.0 is the first decision, not the last
The GitHub version is licensed under AGPL-3.0. That is the strongest of the common copyleft licences and it reaches network use, so a service built on PM4Py is not automatically outside its scope the way it would be with a permissive licence. The README is explicit that a separate version exists for commercial use in closed-source environments under a different licence, with details at processintelligence.solutions/pm4py#licensing. Read that page before you write code you intend to keep proprietary, and treat the licence as an architectural constraint rather than a formality. For academic work and for open-source projects the AGPL is usually unproblematic, and the README asks that scientific use cite the Software Impacts paper by Berti, van Zelst and Schuster (doi 10.1016/j.simpa.2023.100556). Dependencies are documented too: the third_party folder holds direct dependency licences and third_party/LICENSES_TRANSITIVE lists the transitive set, which is the file to open when your legal review asks what else is in the tree. None of this is legal advice; it is a pointer to where the answer lives.
Where PM4Py is the wrong tool
PM4Py is a library, and that is the limitation. There is no ingestion pipeline, no scheduler, no storage layer and no user interface beyond the rendering helpers such as view_petri_net. You supply the log and you own everything around it. If your events are spread across a warehouse and nobody has agreed on a case identifier, the library will not help you build that agreement; you will spend your time on extraction and case notion design before a single model appears. The extras hint at the edges of this. The connectors extra is requests, not a set of vendor adapters, and the llm extra is openai and requests, which suggests optional language-model features rather than a managed service. Visualization depends on pyvis and the windows extra depends on pywin32, so the interactive parts are the least portable pieces. There is also a data volume question the material does not answer: the README states no figures for log size, memory use or runtime, and I have not run it, so treat performance as something to measure on your own log rather than something to assume. Finally, if what you want is a tool an analyst opens on Monday morning, a library is the wrong shape of thing entirely.
The alternative: a hosted process mining platform
The obvious alternative is a commercial process mining platform, the kind sold as a product with connectors, a case model you configure in a UI, dashboards and a licence per user or per case volume. The difference is not which algorithms run; it is who owns the pipeline. A platform takes your ERP or ticketing data through its own connectors, keeps the event data in its own store, and gives analysts a model they can click through without writing Python. PM4Py gives you the algorithms and nothing else, which means you can embed discovery inside a batch job, version the analysis alongside the code, and reproduce a result from a commit. The trade is real in both directions: the platform removes the extraction work and adds a vendor, a data residency question and a renewal; PM4Py removes the vendor and adds the engineering. There is a middle path worth naming, since the same maintainers offer a commercially licensed PM4Py for closed-source settings. That is not a different library so much as a different licence on the same lineage, and it is the route to check if the AGPL is the only thing standing between you and adoption.
Release cadence and what upgrades cost
The recent releases are close together: 2.7.20, 2.7.21 and 2.7.22 all carry timestamps within minutes of each other on 2026-03-20, and the last push to the release branch is later, in September 2026. Three patch releases published in the same minute look like a batch publication rather than three independent bug fixes, so do not read the version numbers as a signal about how much changed. The README points to CHANGELOG.md for incremental updates, and that file is where an upgrade decision should start. On cost: the library is free to install, and the maintenance burden is the dependency surface. Extras pull in scikit-learn, pyarrow, jsonschema, cvxopt, pyvis, openai and others, each with its own release cycle, and the transitive licence list in third_party/LICENSES_TRANSITIVE will grow as those move. The stable extra exists precisely to avoid that drift, since it pins the versions the project validates in CI. If you are deploying PM4Py rather than experimenting with it, installing pm4py[stable] and reading CHANGELOG.md before each bump is cheaper than discovering a breaking change in production. Contributions go through the guidelines and a Contributor License Agreement linked from the README, which is worth knowing before you plan to send patches upstream.
Editorial conclusion
Adopt PM4Py if your event logs are already in XES or convertible to it and your code can carry AGPL-3.0, which rules out most closed-source products without a commercial licence from Process Intelligence Solutions. Skip it if your data lives in a warehouse you cannot export from, or if you need a hosted analyst-facing tool rather than a library. Verify two things before committing: whether your deployment triggers the AGPL network clause, and whether the extras you need (ocel, ml, polars, connectors) install cleanly on your Python version, since the README pins exact versions only through the stable extra.
Community notes