Licensing options memo
Adam's goal, as recorded in the company's internal blueHealthcare strategy document: give the open part of the blueHealthcare clinical platform to health systems worldwide that cannot pay, while the company sells the commercial blueHealthcare product line (US first, then Germany, Australia, Saudi Arabia, UK) — commitment #4 and the strategic-paths table, path 4.
The mechanism that document already names is open-core: the receipt spine and verifier are open, and the healthcare applications ship a community edition under a public-sector / low-income-country licence — the open-core, DHIS2/OpenMRS model (commitment 4).
This memo's first job is to correct a framing problem in that sentence before comparing options, because it shapes every option below.
The Open Source Definition (OSD), maintained by the Open Source Initiative, is the standard the industry and OpenMRS/DHIS2 use to decide what counts as "open source." Two of its ten criteria are directly relevant here:
- "No Discrimination Against Persons or Groups" — "The license must not discriminate against any person or group of persons."
- "No Discrimination Against Fields of Endeavor" — "The license must not restrict anyone from making use of the program in a specific field of endeavor," including business use. (Open Source Initiative, The Open Source Definition: https://opensource.org/osd, verified live.)
Put plainly: an OSI-approved open-source licence cannot be scoped to "low-income countries" or "health systems that can't pay." It cannot charge based on ability to pay, cannot exclude a specific class of user (including a large, well-funded hospital chain or a commercial vendor), and cannot be field-of-use-restricted to the public sector. A licence that tried to do any of those things would not be an open-source licence by the OSD's own test, and could not credibly borrow the "open source" label that makes the OpenMRS/DHIS2 comparison valuable in the first place.
How "free for those who can't pay" is actually achieved, then, is not a clause in the outbound licence — it is the combination of (a) a genuinely open licence on the spine, which is free for everyone including a well-resourced buyer, plus (b) a separate commercial offering (support, hosting, the proprietary application layer, integrations, SLAs) that the company sells to those who can pay. That is exactly what "open core" means in practice, and it is what OpenMRS and DHIS2 do: their core software is unconditionally open to everyone, and revenue comes from implementation partners, hosting, and paid modules/services layered on top — not from a licence clause that reads income.
A "source-available" licence publishes the source but limits who may run it in production, or requires a fee once usage crosses some line — that is precisely a field-of-use or identity restriction, which is what the OSD forbids. Concretely:
- Business Source License (BSL/BUSL): source is published, but a licensee is barred from certain production uses (defined per release) until a stated "Change Date," after which it automatically converts to a real open-source licence (commonly Apache-2.0 or GPL). It is not OSI-approved and does not meet the OSD. (Wikipedia, "Business Source License": https://en.wikipedia.org/wiki/Business_Source_License; MariaDB's own BSL FAQ describes the same mechanic: https://mariadb.com/bsl-faq-adopting/.)
- Elastic License: source-available, free to use, but with use restrictions (notably barring competing "as a service" offerings); after a period it can convert to Apache-2.0. Elastic's own blog describes the change from Apache-2.0 to this model and back again over time. (Elastic, "License Change Clarification": https://www.elastic.co/blog/license-change-clarification.)
- PolyForm licences: a family of template source-available licences (noncommercial, small-business, internal-use, shield, etc.), each with an explicit field-of-use or competitor restriction by design. (Overview via FOSSA's guide: https://fossa.com/blog/comprehensive-guide-source-available-software-licenses/.)
OSI describes this category of licence as failing the Open Source Definition and has publicly used the term "fauxpen" for source-available licences marketed as if they were open source (summarized in the FOSSA guide above; the exact OSI usage of "fauxpen" and its original source were not independently fetched and should be treated as unverified — confirm before quoting it to counsel).
Why this matters for blueOpenHealthcare specifically: a source-available licence would look, on its face, like it satisfies "give it to those who can't pay, keep it from those who can" — but it does that by exactly the mechanism the OSD forbids, so the project could not call the result "open source," could not credibly claim the OpenMRS/DHIS2 comparison, and — separately — a "cannot compete with us" clause is the one thing large vendors have the least trouble ignoring in low-oversight jurisdictions, because it is a contract term to be litigated, not a permission that was never granted. It buys reputational cost, not real protection, and it costs the open-source narrative that is the whole point of the international-access strategy. It is included in the comparison table below for completeness, and is not recommended.
| Criterion | Apache-2.0 | MPL-2.0 | AGPL-3.0 | Dual licence (AGPL + commercial) | Open core (proprietary app/, open core/) |
|---|---|---|---|---|---|
| Goal holds (free for those who can't pay; commercial survives) | Yes, but only via a separate commercial layer/service — the licence itself cannot discriminate | Same as Apache-2.0 | Yes, and the copyleft gives a second lever: a SaaS competitor must publish their modifications, which reduces their incentive to fork-and-compete | Yes — AGPL default + a paid non-AGPL licence for anyone who wants proprietary terms | Yes — this is the mechanism the strategy document already names, and does not depend on a licence clause at all |
| Protects against a large vendor taking the code into a closed SaaS | Weak. Apache-2.0 permits closed derivative works and closed-source SaaS with no reciprocal obligation | Weak-to-moderate. File-level copyleft: modified MPL files must stay MPL and be shared, but the vendor can wrap them in a proprietary "Larger Work" and never publish that wrapper (Mozilla, MPL-2.0 "Distribution of Source Form," "Distribution of a Larger Work": https://www.mozilla.org/en-US/MPL/2.0/) | Strongest of the five for the SaaS case. AGPL's Section 13 extends copyleft to network use: a party that runs a modified version as a network service must offer users the corresponding source (GNU, AGPL-3.0 full text: https://www.gnu.org/licenses/agpl-3.0.en.html) | Same protection as AGPL for anyone using the free licence; a vendor who wants to avoid disclosure must buy the commercial licence, which is the point | Strongest in practice, because the parts a SaaS competitor would want most (billing, tenancy, enterprise export, UI) are never released at all — the licence question only applies to the spine |
| Explicit patent grant | Yes — Apache-2.0, broad, terminates on patent litigation against the licensor (Apache Software Foundation, LICENSE-2.0: https://www.apache.org/licenses/LICENSE-2.0) | Yes — MPL-2.0, similarly scoped to each contributor's own contribution, with a defensive termination clause (https://www.mozilla.org/en-US/MPL/2.0/) | Yes — AGPL-3.0 incorporates GPLv3's explicit patent grant unchanged (https://www.gnu.org/licenses/agpl-3.0.en.html) | Yes, inherited from AGPL for the free tier; the commercial licence's patent terms are whatever the company negotiates | Whatever the chosen licence for core/ provides; app/ carries no open patent grant because it is not distributed under an open licence |
Fits core/app split and make community | Fits cleanly — permissive licence on core/, proprietary app/; no interaction risk | Fits cleanly for the same reason, with the added benefit that MPL's file-level scope maps naturally onto "these specific files are the spine" | Fits, but needs care: if any AGPL-licensed core/ code is statically linked into or otherwise combined with proprietary app/ code in a way that makes them one "work" under AGPL, that could pull app/ under AGPL too. This is a real legal question, not a policy one — see the open questions below. A clean process-boundary or service-boundary between core/ and app/ (which the addendum's "zero dependencies on app/" rule already pushes toward) reduces this risk considerably | Same combination risk as plain AGPL for the free tier, resolved for paying customers by the commercial licence, which can explicitly permit combination with proprietary code | This is the core/app split; the licence question is then "what open licence goes on core/," i.e., the first four columns, applied only to core/ |
| Fits OpenMRS/Bahmni's own licensing | Compatible; Apache-2.0 and MPL-2.0 are both listed by Mozilla as mutually and GPL-compatible in relevant ways | Exact match with OpenMRS. OpenMRS is licensed under MPL-2.0 with a healthcare-specific disclaimer (openmrs-core LICENSE: https://github.com/openmrs/openmrs-core/blob/master/LICENSE; background at the OpenMRS wiki, "Proposed Adoption of MPL 2.0 with Disclaimer": https://openmrs.atlassian.net/wiki/spaces/RES/pages/26312431/Proposed+Adoption+of+MPL+2.0+with+Disclaimer) | Exact match with Bahmni's current licence. Bahmni's GitHub repositories are licensed AGPL-3.0 today (Bahmni, "License": https://www.bahmni.org/license; also https://www.bahmni.org/license-faq). However, as of a November 2025 community thread, the Bahmni Coalition has an active proposal to move away from AGPL-3.0 toward MPL-2.0 (with a healthcare disclaimer, following OpenMRS) or MIT for some repositories (OpenMRS Talk, "Proposal for License change for Bahmni": https://talk.openmrs.org/t/proposal-for-license-change-for-bahmni-requesting-community-inputs-by-nov-15-2025/47267). Treat Bahmni's AGPL status as current-but-possibly-transitional; counsel should re-check before this memo is acted on. | The free tier can be made to match either OpenMRS (MPL) or Bahmni's current AGPL | The open core/ can be licensed to match either community; the proprietary app/ has no OpenMRS/Bahmni analogue because neither of those projects has a comparable held-back proprietary layer at the core level |
| Government procurement acceptability in low-income health systems | Very high — permissive licences are the least friction for any government legal/procurement review; no reciprocal disclosure obligation to worry about | High — same as Apache in most procurement reviews; the file-level copyleft is rarely a procurement blocker because it only affects code the government would be redistributing, not running | Moderate. Some government and enterprise procurement teams flag AGPL specifically because the network-copyleft clause is unusual and legal teams unfamiliar with it sometimes over-read its reach; OpenMRS's own history is informative here — it deliberately moved away from a from-scratch licence toward a standard OSI one specifically to reduce this kind of friction (OpenMRS wiki, cited above) | Moderate for the free tier (same AGPL friction), resolved for institutions that need cleaner terms by offering the commercial licence | High for procurement of the open core/ (whatever permissive/weak-copyleft licence is chosen); the proprietary app/ goes through ordinary commercial procurement like any vendor product |
| Export control / sanctions considerations for a global release | Flagged, not resolved, for all five options — see §3 below | ||||
The company's strategy document explicitly names "the DHIS2/OpenMRS model" as the target (commitment 4), and the strategy row for the community edition names an OpenMRS/Bahmni module as the first integration target. Verified current facts:
- OpenMRS: MPL-2.0 with an added Health-Related Additional Disclaimer of Warranty and Limitation of Liability. History: OpenMRS Public License 1.0 (from-scratch) → a modified MPL 1.1 → MPL 2.0, the last move made specifically with the OSI's help to land on a real, OSI-approved licence rather than a bespoke one (OpenMRS wiki, "Proposed Adoption of MPL 2.0 with Disclaimer": link; license file: link). OpenMRS does not require the same licence for community-contributed modules (OpenMRS wiki, "Licensing of OpenMRS Modules FAQ": link).
- Bahmni: AGPL-3.0 today (https://www.bahmni.org/license, https://www.bahmni.org/license-faq), with an active 2025 community proposal to move to MPL-2.0 (matching OpenMRS) or MIT for some repositories (link).
- DHIS2 (mentioned in the strategy document as a second reference open-core project): the
dhis2-corerepository'sLICENSEfile is BSD-3-Clause, not AGPL (verified by fetchinghttps://raw.githubusercontent.com/dhis2/dhis2-core/master/LICENSEdirectly). This is worth flagging to counsel because the phrase "DHIS2/OpenMRS model" implies a shared approach, but the two projects use materially different licences (BSD-3-Clause, a permissive licence with no copyleft, versus OpenMRS's file-level-copyleft MPL-2.0). DHIS2's own web terms (https://dhis2.org/terms-privacy/) were checked and cover only the dhis2.org website, not the software licence — the BSD-3-Clause finding above is the software licence. DHIS2 also runs a separate, more actively governed brand-control document for its name and marks; a specific DHIS2 trademark-policy URL was searched for and not found in a form that could be verified — mark DHIS2's trademark practice as unverified (see the sample trademark policy).
Implication for counsel: "the DHIS2/OpenMRS model" is really two different licensing choices (BSD-3-Clause vs. MPL-2.0) united only by the open-core business model (open engine, revenue from services/paid layers on top). Picking a single outbound licence to "match" both is not possible; counsel should decide whether OpenMRS's MPL-2.0 (closer fit: healthcare-specific disclaimer precedent, and the module most likely to be extended — Bahmni — may itself be moving to MPL-2.0) or a permissive licence (closer fit to DHIS2's actual choice) better serves the stated goal.
This program is a global release, and the strategy explicitly includes low-income and Gulf-region markets. Two distinct questions exist and neither is resolved here:
- Is the software itself subject to U.S. export control (EAR) at all, and does an open-source release change that? Publicly available, freely downloadable open-source encryption source code is generally excluded from EAR licensing requirements once a required notification is filed, under License Exception TSU (15 C.F.R. § 740.13(e)); the Linux Foundation has published general guidance on how U.S. export control interacts with open-source projects (link; BIS's own encryption-controls page: link). blueHealthcare's receipt/verifier spine signs records with public-key cryptography (Ed25519), which is exactly the kind of thing this exception was written for — but whether the specific notification has been filed, and whether any non-encryption part of the platform is separately controlled, is a question only counsel (with export-control expertise) can answer. Not resolved here.
- Sanctions / restricted-party screening for who may download or contribute. An OSI licence cannot restrict who uses the software — but U.S. sanctions law is a separate, mandatory overlay that applies regardless of licence choice: the company likely cannot knowingly make the software available to, or accept contributions that route through, sanctioned countries, entities, or listed individuals, irrespective of what the licence says. GitHub itself, as a US company, already restricts access from certain sanctioned jurisdictions at the platform level, which may do some of this work by default — but that is a fact about GitHub's own policy, not a substitute for the company's own OFAC/BIS compliance analysis. Not resolved here.
Recommendation (not a decision): license core/ (the receipt spine, verifier, record core, and jurisdiction interfaces) under MPL-2.0, following OpenMRS's own precedent of adding a healthcare-specific warranty/liability disclaimer on top, and keep app/ (billing, tenancy, enterprise exports, and the commercial healthcare applications) proprietary and unlicensed for public distribution — i.e., go with the open-core column of the table above, using MPL-2.0 as the specific licence for the open half. MPL-2.0's file-level copyleft gives real protection against a vendor quietly forking the spine into a closed SaaS without giving anything back, it explicitly permits combination with proprietary code in a "Larger Work" so app/ is never at legal risk of being pulled under the open licence, it carries an explicit patent grant, and it is the licence the project's own most likely integration partner (OpenMRS) already uses — which lowers friction if a module is ever contributed back and forth between the two projects. AGPL-3.0 is the strongest alternative to test if counsel weighs SaaS-forking risk more heavily than combination flexibility; it is also Bahmni's current (though possibly transitional) licence, which matters if Bahmni integration specifically is the priority over OpenMRS integration.
Superseded by the country eligibility proposal: this recommendation assumed a licence open to everyone in every country. Adam's 2026-09-11 direction limits the community edition by country instead — see the country eligibility and share-back terms. The licence-comparison analysis above is unaffected; only the "open to everyone, no country limit" framing is superseded.
- Which of the five options above should govern
core/? (This memo's tested recommendation is MPL-2.0 within an open-core structure, subject to the eligibility-terms caveat above.) - If AGPL-3.0 (plain or dual) is chosen: given the actual, current code dependencies between
core/andapp/, does AGPL's network-copyleft reach far enough to pull any part of the proprietaryapp/layer into disclosure obligations once they are combined at runtime? Answerable only after reviewing the actual combination mechanism (in-process import vs. separate service/process boundary). AGPL-3.0-onlyorAGPL-3.0-or-later(if AGPL is chosen) — which SPDX variant should the project standardize on?- Should the healthcare disclaimer follow OpenMRS's wording closely, or be drafted fresh for blueHealthcare's specific risk profile (a receipts/verification spine, not a full EHR)?
- Does the company want the option to offer a paid, non-open commercial licence to specific customers later (the "dual licence" path)? This determines whether an Individual/Corporate CLA is close to required, or whether a DCO alone suffices — see the sample contributor terms.
- Has anyone confirmed whether the receipt/verifier spine's use of public-key signing (Ed25519) qualifies for the EAR's publicly-available-encryption-source-code exception, and if so, has the required notification been filed?
- Independent of what the open-source licence permits, does the company need its own process for sanctions/restricted-party screening, and does hosting on GitHub satisfy that on its own?