Is Mirth Connect Still Open Source in 2026? — Status, License, Path

Mirth Connect is licensed under the Mozilla Public License, version 1.1. The license terms haven't changed since the original Mirth Corporation release in 2006, and they survived all subsequent ownership transitions: Mirth Corporation → Quality Systems Inc. → NextGen Healthcare → the current state.

MPL 1.1 is a weak copyleft license. In practical terms:

• You can use, modify, and redistribute the source code.
• Modifications to Mirth Connect's files must be released under MPL.
• You can combine Mirth Connect with proprietary code (the file-level boundary matters, not the application-level boundary). Channels, transformers, and custom Java extensions you write don't become MPL by virtue of running inside Mirth.
• No copyleft on derivative works at the application level — your healthcare app built on top of Mirth stays your IP.

For US healthcare buyers, the practical takeaway is: deploying open-source Mirth Connect does not create license obligations on your downstream applications or channels. You own the work you build on top.

NextGen Healthcare maintains a commercial distribution called NextGen Connect. The two are not separate products in the engineering sense — they share a codebase. The differences are commercial, not technical:

• NextGen Connectis the commercially packaged version. Includes vendor support, installer with commercial-grade signing, access to NextGen's customer portal, and a per-server license fee. Customers buying NextGen Connect get an SLA, a vendor relationship, and a stable upgrade cadence.
• Mirth Connect is the open-source distribution. Source-available on public git mirrors, downloadable as built artifacts via various third-party mirrors (NextGen has periodically restricted direct downloads of binaries from mirthcorp.com/mirthconnect.com domains, but the source code itself remains MPL and publicly available). No vendor support; you either self-support, hire a consultancy, or buy a NextGen Connect contract.

Functionally, a channel built on Mirth Connect runs identically on NextGen Connect. Migration between the two is trivial — typically just a re-installer and license activation. We support clients on both distributions.

Short answer: not publicly, and not in a way that changes the legal status of code already released under MPL.

The MPL license is irrevocable for already-released code. Even if NextGen stopped contributing to the open-source distribution tomorrow, every version up to that point stays freely usable, modifiable, and redistributable. A fork by the community would be legally straightforward.

What NextGen could do (and has periodically done in smaller ways):

• Restrict direct binary downloads from official domains, pushing buyers toward the commercial NextGen Connect distribution. This has been observed at various points but doesn't affect the MPL status of the source.
• Slow the pace of open-source releases relative to NextGen Connect releases. This is the more practical concern — see the feature-velocity section below.
• Stop accepting community pull requests. This would fork the project de facto, but wouldn't affect existing deployments.

Under any of these scenarios, the existing open-source codebase remains usable for existing deployments. The license cannot retroactively close. This is one of the structural advantages of MPL over more restrictive licensing arrangements.

The headline risk for open-source Mirth Connect isn't license status — it's feature velocity. NextGen prioritizes work that benefits NextGen Connect customers (who pay license fees); pure open-source contributions sit further down the list.

What this looks like in practice for 2026:

• FHIR R4 implementation: usable but trailing the most aggressive FHIR-native engines on some specific profiles. US Core profiles are covered. SMART Backend Auth integration is reliable. Bulk Data ($export) is supported through custom channel patterns rather than first-class support — we publish a FHIR Bulk Data implementation guide that walks through the production pattern.
• Cloud-native deployment:Docker support is mature. Kubernetes patterns work but require some integration glue. Helm charts exist in the community but aren't official.
• Modern transformer language support: JavaScript (Rhino) and Groovy still core. No first-class TypeScript, but the Rhino engine handles modern JavaScript features adequately for most channel logic.
• UI / Admin Console:Java Swing-based desktop admin tool, dated but functional. Web-based admin features exist but aren't at parity with the desktop tool.

None of these are blockers for production healthcare integration work. They are the reasons a small percentage of greenfield deployments consider commercial alternatives (Iguana, Rhapsody, InterSystems IRIS) — though for established deployments, migrating off Mirth typically costs more than tolerating the feature gaps and using standard workarounds.

Mirth Connect is not governed by a foundation. There is no Apache-style PMC, no Linux Foundation membership, no formal community governance structure. The codebase is controlled by NextGen Healthcare as the corporate steward.

Practical consequences:

• Pull requests get reviewed when NextGen has bandwidth. Community-contributed patches are merged but the cadence varies.
• The roadmap is set by NextGen Healthcare based on what NextGen Connect customers need. Open-source community priorities can diverge.
• Forks exist but none have achieved meaningful adoption. The codebase is large and specialized; community capacity to maintain a competing fork is limited.

For procurement teams evaluating Mirth as a long-term bet: this is the most honest risk. The license protects already-released code, but the corporate steward decides where the codebase goes next. The mitigation is the same mitigation that applies to most healthcare open-source software — pick the engine that fits your needs today, use it under MPL, hire independent specialists for support, and accept that the next 5 years of feature evolution are not under your control.

Source code is available via NextGen Healthcare's public repositories and third-party mirrors. Built artifacts (the installer and JARs you actually run in production) have been distributed via various channels over time. Current options include:

• NextGen Connect installer (commercial distribution) via NextGen Healthcare's customer portal — requires a license.
• Mirth Connect community builds via third-party mirrors. We maintain links to verified mirrors and SHA checksums in our installation guide.
• Build from source — straightforward for teams comfortable with Java build tooling. Source repository accessible publicly.

For production deployments, we strongly recommend either: (1) a commercially-supported NextGen Connect license, or (2) a productized managed-support engagement on the open-source distribution. Self-supporting open-source Mirth in production without either is feasible but assumes you have in-house Java + healthcare-integration expertise to handle CVE remediation, version upgrades, and incident response.

Full installation walkthrough including verification: Mirth Connect installation guide.

For most US healthcare integration workloads: yes. The license is irrevocable, the codebase is production-grade, the talent pool is the deepest in the commercial integration-engine market, and the productized managed-support market around it is mature enough to provide a clear operational path.

The cases where we'd recommend commercial alternatives:

• Greenfield deployment with FHIR-native requirements and budget for commercial licensing.If you're starting fresh and FHIR R4 maturity is the #1 requirement, evaluate Iguana and Rhapsody alongside Mirth.
• Enterprise customers requiring vendor accountability on every channel. NextGen Connect commercial support provides a vendor SLA backed by NextGen's corporate balance sheet. For some regulatory or contractual situations, that matters.
• Teams without integration-engineering capacity and unwilling to engage a consultancy. Self-support on any open-source engine is risky in healthcare. Either pay a vendor or pay a consultancy — picking the open-source engine without either is a bad spot.

For everyone else — the large majority of US health systems, HealthTech startups, and mid-market deployments — Mirth Connect on MPL 1.1 is the right call for 2026 and beyond. We support hundreds of those deployments at mirth.support; the operational model is well-trodden.