MNE-Python: A Unified Analysis Stack for MEG, EEG, sEEG and ECoG
MNE: Magnetoencephalography (MEG) and Electroencephalography (EEG) in Python
At a glance
- What is it?
- MNE-Python is a BSD-3-Clause Python package that covers I/O, preprocessing, source estimation, time-frequency analysis, connectivity, machine learning and statistics for human neurophysiological recordings. Its breadth is the draw and also the reason to check dependency and maintenance expectations before adopting it.
- Who is it for?
- Adopt MNE-Python if your data is MEG, EEG, sEEG or ECoG and you want one library spanning raw I/O through source estimation, connectivity and statistics, with the API reference and tutorials at mne.tools as your entry point.
- Can I use it commercially?
- Yes. BSD-3-Clause is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- 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
The Problem MNE-Python Solves for Neurophysiology Teams
Neurophysiology data arrives in a long tail of vendor formats, sampling rates and channel naming conventions. A lab recording MEG, EEG, sEEG or ECoG typically ends up writing its own readers, its own event parsing, and its own montage handling before any analysis starts. MNE-Python exists to absorb that layer. The README describes it as an open-source Python package for exploring, visualizing, and analyzing human neurophysiological data, with modules for data input/output, preprocessing, visualization, source estimation, time-frequency analysis, connectivity analysis, machine learning and statistics. The target user is a researcher or research engineer who already works in Python and wants the format handling and the analysis primitives to come from the same library, so that a Raw object read from disk can be filtered, epoched and passed into a statistical test without a conversion step in between. It is not aimed at real-time streaming or at clinical diagnostic pipelines; nothing in the supplied material suggests either use case is supported.
Data Flow Through the Library: Raw, Epochs and Evoked
The architecture visible in the README is a pipeline of in-memory data containers. The I/O module reads a recording into a raw continuous representation; preprocessing operates on that; segmentation produces an epoched representation; averaging produces an evoked representation; and the downstream modules (time-frequency, connectivity, source estimation, machine learning, statistics) consume whichever of those containers fits the analysis. Visualization is a peer module rather than a separate application, which matters because it means plots are produced from the same objects the analysis uses, not from an exported intermediate file. The dependency list reinforces how the layering works. NumPy and SciPy supply the array and signal primitives, Matplotlib supplies rendering, Jinja2 handles report templating, Pooch handles dataset fetching, and lazy-loader defers imports so that importing mne does not pull in every optional backend at once. That last dependency is a deliberate design choice with a visible cost: it keeps import time down but means a missing optional package surfaces at call time rather than at import time.
Installing MNE-Python and the Minimum You Actually Need
The README gives a single command for the minimal install: pip install --upgrade mne. That pulls in only the core dependencies, which the README lists as Python 3.11 or newer, decorator 5.1 or newer, Jinja2 3.1 or newer, lazy-loader 0.3 or newer, Matplotlib 3.9 or newer, NumPy 2.1 or newer, packaging, Pooch 1.5 or newer, SciPy 1.14 or newer, and tqdm 4.66 or newer. Note the floor on Python and NumPy: 3.11 and 2.1 respectively. If your environment is pinned to an older NumPy for another dependency, you will have a conflict before you write a line of analysis code. For the development version, the README offers two routes. The first is a pip install from the main branch archive: pip install --upgrade https://github.com/mne-tools/mne-python/archive/refs/heads/main.zip. The second is a plain git clone of https://github.com/mne-tools/mne-python.git. The README also points to a separate installation guide for standalone installers and more advanced methods, and to a user forum at mne.discourse.group for usage questions. Bugs and feature requests go through the GitHub issue tracker, not the forum.
Where MNE-Python Is the Wrong Tool
The dependency floor is the first hard constraint. Python 3.11 or newer and NumPy 2.1 or newer rule out environments that are frozen for reproducibility against older scientific stacks, and the pip install command above will not negotiate around that. The second constraint is scope. If your signal is not human neurophysiological data, the modality-aware containers and the format readers are overhead rather than help. A team processing accelerometer traces or audio waveforms gets more from scipy.signal and numpy directly, with fewer abstractions between the array and the analysis. The third constraint is harder to see from the README: because optional functionality is loaded lazily, a pipeline that works in one environment can fail in another at the point where an optional backend is first touched, and the failure appears mid-analysis rather than at startup. The README does not enumerate which features require which optional packages, so that mapping has to come from the documentation site. Finally, nothing in the supplied material describes real-time or streaming acquisition support, so a lab that needs closed-loop stimulus delivery should not assume this library covers that path.
How MNE-Python Differs from a General Signal Processing Stack
The obvious alternative for a Python user is to assemble the analysis from scipy.signal, numpy and matplotlib, the same libraries MNE-Python itself depends on. The difference is in what each layer knows about. A scipy.signal pipeline operates on arrays and knows nothing about channels, montages, sampling rates as metadata, or event structures. MNE-Python operates on objects that carry that context, which is why source estimation and connectivity analysis can be offered as first-class modules rather than as recipes you write yourself. The trade is control for convention. With raw scipy you decide exactly how filtering is applied and you can see every step; with MNE-Python you accept the library's conventions for referencing, montage handling and epoching in exchange for not rebuilding them. A second alternative worth naming is to stay inside a vendor's own analysis environment. That keeps format handling trivial but ties the analysis code to one manufacturer, which is the problem MNE-Python was written to remove. The choice between these comes down to whether your bottleneck is format diversity or step-level control.
Maintenance, Releases and the BSD-3-Clause Licence
The release cadence visible in the material is roughly two feature releases a year with patch releases in between: v1.12.0 in April 2026, v1.12.1 later that same month, and v1.13.0 in September 2026. The repository is not archived and the last push recorded is 2026-09-10, one day after the v1.13.0 tag. For a team pinning a version, that cadence means an upgrade decision roughly every six months, plus patch releases you should track for fixes. The README also documents a development install path from the main branch, which is useful for testing an unreleased fix but puts you on code that has not been tagged. The licence is BSD-3-Clause, a permissive licence that generally allows use, modification and redistribution provided the copyright notice and disclaimer are retained. This is a description of the licence identifier, not legal advice; if you are redistributing MNE-Python inside a commercial product, have your own counsel read the terms. One practical note on packaging: the README's About table references both PyPI and conda-forge, so teams standardised on conda have a channel to install from, but the README does not state whether the two channels always carry the same version at the same time. Verify that before you make conda-forge your only source.
Editorial conclusion
Adopt MNE-Python if your data is MEG, EEG, sEEG or ECoG and you want one library spanning raw I/O through source estimation, connectivity and statistics, with the API reference and tutorials at mne.tools as your entry point. Do not adopt it if you only need generic filtering or spectral estimation on non-neurophysiological signals: the modality-aware objects and file-format readers add surface area you will not use, and scipy.signal plus numpy will cover that ground with far less to learn. Before committing, verify three things against your own environment: that your Python is 3.11 or newer, that your recording format has a reader in the I/O module, and that the version you pin is one you can also get from conda-forge if your team installs that way. The BSD-3-Clause licence is permissive, but it is your responsibility to confirm it fits your distribution model.
Community notes