ADR-003: MPL-2.0 License

Status

Accepted — March 2025

Context

Healthcare integration is a space dominated by proprietary, expensive software:

• Mirth Connect (now NextGen Connect) — was open source under MPL, then moved critical features behind a proprietary license. The open source community lost trust.
• Rhapsody (Rhapsody Health) — fully proprietary, enterprise-only pricing, no source code access.
• Intely — SaaS-only, no self-hosting option, no source code.
• InterSystems HealthShare — proprietary, tightly coupled to the Caché/IRIS database.

These products charge tens to hundreds of thousands of dollars per year. Healthcare organizations — especially smaller hospitals, clinics, and public health agencies — are locked into vendors with no ability to inspect, modify, or self-host the software that handles their most sensitive data.

Note

Open source is not just a business model choice in healthcare — it is a trust and compliance requirement. Organizations handling Protected Health Information (PHI) need the ability to audit the code that processes, transforms, and routes patient data. Proprietary black boxes create compliance risk.

We needed a license that satisfies four requirements:

1. Keeps the core open source — the engine, CLI, and standard connectors must always be source-available and modifiable.
2. Allows commercial use — companies must be able to use intu in production without legal ambiguity.
3. Allows proprietary extensions — vendors and healthcare organizations must be able to build proprietary connectors, dashboards, and SaaS products on top of intu without being forced to open-source their own code.
4. Requires modifications to the core to be shared back — if someone improves intu’s engine, those improvements must benefit the community.

Decision

We chose the Mozilla Public License 2.0 (MPL-2.0).

MPL-2.0 is a file-level copyleft license. This means:

• Modifications to intu’s source files must be distributed under MPL-2.0. If you change a file in intu’s codebase, that changed file must remain open source.
• New files (proprietary connectors, custom dashboards, SaaS wrappers) can use any license, including proprietary. MPL-2.0 does not “infect” adjacent code the way GPL does.
• Commercial use is explicitly permitted. Companies can use, distribute, and sell products that include intu.
• Patent grants are included. Contributors grant a patent license for their contributions, protecting users from patent claims.
• Compatible with secondary licenses including GPL v2+, LGPL, and AGPL, allowing intu’s code to be incorporated into projects with those licenses if needed.

What this means in practice

Scenario	License requirement
Use intu as-is in production	No obligation beyond including the license
Modify intu’s source files	Modified files must be shared under MPL-2.0
Build a proprietary connector	Your connector code can be any license
Build a SaaS product on top of intu	Your SaaS code can be proprietary
Fork intu and redistribute	Modified MPL files must remain MPL-2.0

Consequences

Positive

• Balances openness and commerce — MPL-2.0 sits in the sweet spot between permissive (MIT/Apache) and strong copyleft (GPL/AGPL). The core stays open; the ecosystem can be commercial.
• Enterprise-friendly — MPL-2.0 is approved by the Open Source Initiative (OSI) and the Free Software Foundation (FSF). Enterprise legal teams understand it. Mozilla Firefox, LibreOffice, and Syncthing all use MPL-2.0 — it has a strong track record.
• Prevents hostile forks — a competitor cannot take intu’s code, make improvements, and release a proprietary version without sharing the improvements to the MPL-licensed files. This protects the community’s investment.
• Encourages contribution — because modifications must be shared back, organizations are incentivized to contribute upstream rather than maintaining private forks that diverge over time.
• Proprietary extensions welcome — healthcare organizations and vendors can build proprietary connectors (e.g., for niche EHR systems), commercial dashboards, managed hosting services, or enterprise features without license conflicts.
• Trust in healthcare — open source builds trust with compliance teams, security auditors, and CTOs who need to verify that PHI is handled correctly.

Negative

• Less permissive than MIT — some developers and companies prefer the simplicity of MIT, which imposes no copyleft obligations at all. MPL-2.0’s file-level copyleft may deter contributors who want maximum freedom.
• File-level copyleft confusion — the boundary between “modifying an existing file” and “creating a new file” can be unclear in edge cases. Contributors unfamiliar with MPL-2.0 may need guidance on what triggers the copyleft obligation.
• Not as protective as GPL — a company could build a large proprietary product around intu, contributing nothing back, as long as they don’t modify intu’s own files. Strong copyleft advocates may see this as insufficient.

Caution

If you modify any of intu’s source files, those modifications must be made available under MPL-2.0. This applies even if the modified file is distributed as part of a larger proprietary product. When in doubt, consult the full MPL-2.0 text.

Why Not Other Licenses

MIT / Apache 2.0

Too permissive for our goals. A competitor could fork intu, improve the engine, and release a proprietary product without contributing anything back. This is exactly what happened in the Mirth Connect ecosystem — proprietary forks fragmented the community. Apache 2.0 adds patent protection but still allows proprietary forks without sharing modifications.

GPL v3

Project-level (strong) copyleft. Any project that links to or includes GPL code must itself be GPL-licensed. This deters enterprise adoption — companies building proprietary healthcare products cannot use GPL-licensed components without open-sourcing their entire product. Many enterprise legal teams have blanket policies against GPL dependencies.

AGPL v3

Adds network-use copyleft to GPL — if you run AGPL software on a server, you must provide source code to anyone who interacts with it over a network. This is extremely aggressive for integration middleware that, by definition, runs as a network service. Cloud providers and healthcare SaaS companies actively avoid AGPL-licensed software.

BSL (Business Source License) / SSPL (Server Side Public License)

Neither BSL nor SSPL is approved by the OSI. They are “source available” but not “open source” by the accepted definition. Enterprise compliance teams may reject them on principle. SSPL in particular was created by MongoDB to prevent cloud providers from offering it as a service — a legitimate concern, but the license is too restrictive and untested in court for us to adopt.

Tip

MPL-2.0 is sometimes called the “Goldilocks license” — not too permissive, not too restrictive. For infrastructure software that needs both community trust and commercial viability, it hits the right balance.