Proposed terms — pending legal review

Sample licence application

These are drafts prepared for counsel. They are not in effect, and no licence has been granted.

This file illustrates, mechanically, how MPL-2.0 (the recommended default from the licensing options memo) would be applied to the open part of the blueHealthcare platform, with AGPL-3.0 noted as the alternative wherever the mechanics differ. Nothing here has been written into any actual file in the blueHealthcare repository or any other repository.

1. SPDX header per file

The SPDX License List is the standard machine-readable way to mark a file's licence without reproducing the full licence text in every file (SPDX, License List: https://spdx.org/licenses/). A file under the open licence would carry, as its first lines (adjusted per language's comment syntax):

# SPDX-License-Identifier: MPL-2.0
# SPDX-FileCopyrightText: (c) 2026 MOBLUEHQ, Inc.

If AGPL-3.0 were chosen instead, the only change is the identifier:

# SPDX-License-Identifier: AGPL-3.0-only
# SPDX-FileCopyrightText: (c) 2026 MOBLUEHQ, Inc.

(AGPL-3.0-only vs. AGPL-3.0-or-later is itself a decision for counsel.) A file that stays proprietary carries no SPDX open-source identifier at all; it would instead carry the company's own proprietary-notice header (a separate, short internal template, not drafted here since it is not open-source licensing).

2. LICENSE / NOTICE structure

If MPL-2.0 is adopted, the top of the open portion's tree (i.e., platform/core/, not the repository root, since the repository as a whole would remain mixed) would carry:

LICENSE — the full, unmodified MPL-2.0 text, linked from and matching Mozilla's canonical copy (https://www.mozilla.org/en-US/MPL/2.0/). This scaffold does not reproduce that text here per the "don't invent licence text" rule; counsel or the eventual maintainer would copy it verbatim from Mozilla's site.
A healthcare disclaimer addendum, modelled on OpenMRS's own approach of adding a Health-Related Additional Disclaimer of Warranty and Limitation of Liability on top of MPL-2.0 (OpenMRS wiki: link; OpenMRS's actual license file for the exact combined form: link). Counsel would draft blueHealthcare's own version of this addendum — it should not simply copy OpenMRS's wording, both because that wording is itself their copyrighted document and because blueHealthcare's specific harms profile (a receipts/verification spine, not a full EHR) differs from OpenMRS's.
NOTICE — required practice (and, for Apache-2.0, an explicit licence requirement) for attributions that must survive redistribution: the project's own copyright line, and the third-party licence inventory described below, or a pointer to it.

If AGPL-3.0 were chosen instead, the same LICENSE file would hold the AGPL-3.0 text (https://www.gnu.org/licenses/agpl-3.0.en.html), and the same healthcare-disclaimer addendum pattern would apply on top of it — Bahmni's current AGPL-3.0 licensing does not appear to carry an equivalent healthcare disclaimer as of this writing (unverified beyond the license pages cited in the licensing options memo; counsel should check Bahmni's actual repository headers directly if this matters).

3. Which directories fall under it, and which stay proprietary

Based on the international/handheld open-source addendum's own stated split and the actual repository layout observed at platform/core/ on 2026-09-10 (subdirectories: capture/, consent/, cutover/, events/, identity/, jurisdiction/ — with us/ and xx/ packs — receipts/, record/, terminology/, trust/), a sample split would be:

Path	Proposed licensing	Why
`platform/core/` (all subdirectories above)	Open (MPL-2.0 or AGPL-3.0 per counsel)	This is the receipt spine, verifier, record core, and jurisdiction interfaces the strategy document names as the open part
`platform/core/jurisdiction/us/` specifically	Open, but see note	Contains US-specific values; open licensing here is about the code, not a claim that its content (e.g. references to CPT, ICD-10-CM) is itself freely licensed — see the third-party licence inventory section below
`platform/app/`, `launcher/`, billing, tenancy, enterprise-export code	Proprietary, not publicly distributed	The addendum's own rule: enterprise features excluded "at build time, not by a runtime licence check"
The individual commercial products (blueChart, blueClaims, blueBench, blueDelta, blueRecall, blueNull, blueCatch, and the eSource module for clinical trials)	Proprietary code, not MPL/AGPL — superseded 2026-09-12: licensed under the blueOpenHealthcare Community Licence for eligible countries (see eligibility), a commercial licence elsewhere	Adam's 2026-09-12 decision brought these eight into the free edition for eligible countries; this row's earlier claim that "the strategy never proposes opening them" no longer holds. They still carry no SPDX open-source identifier — the Community Licence is source-available, not an OSI licence, so this page's MPL/AGPL scaffold applies only to the open spine above
`platform/core/jurisdiction/openmrs/` adapter slot	Open, once it exists	Named in the addendum as a planned interface stub; it does not exist yet (verified: no `openmrs`-path file found under `platform/core/` as of 2026-09-10)

Important caveat: core/ is documented as having a measured number of live dependencies on app/ — 28 of them in production code — measured 2026-09-12 by the repository's own core/app boundary test, counting imports outside test files dated 2026-09-10. Until that boundary is actually clean, "license core/ openly" is a target, not something that can be done today without either (a) also opening code that depends on app/ internals, or (b) shipping a core/ that does not build stand-alone. This is an engineering precondition to publishing anything under whatever licence is chosen, independent of which licence counsel picks.

4. Third-party licence inventory requirement

Any open release must ship a third-party licence inventory — a list of every dependency, its licence, and (for copyleft dependencies) whether its terms are compatible with the outbound licence. This is standard open-source hygiene, not something specific to healthcare. Two concrete facts from this codebase make it non-optional here:

The platform already vendors a large number of third-party Python and JavaScript packages with their own licences (spot-checked under platform/venv/ and launcher/web/node_modules/ — dozens of LICENSE files from packages like fastapi, sqlalchemy, pydantic, react, vite, etc., each under its own permissive licence, mostly MIT/BSD/Apache-2.0 by their filenames — not individually verified license-by-license here; a real inventory tool (e.g. pip-licenses, license-checker, or an SBOM generator) should be run before any release, not hand-compiled).
Coding-system content is a separate, sharper issue. Standard medical coding systems referenced by the US jurisdiction pack — CPT in particular — are themselves proprietary and licensed by their publishers (the American Medical Association, for CPT). The addendum's own design already anticipates this correctly: packs should carry identifiers/URIs pointing at coding systems, never the licensed code tables themselves ("packs carry URIs, not code tables"). The licence inventory must explicitly confirm no licensed vocabulary content (CPT, SNOMED CT, LOINC tables, etc.) is committed to the open repository, only references to where an implementer can obtain a licence for those vocabularies themselves.

Recommended inventory format: a single THIRD_PARTY_LICENSES.md (or SPDX-format SBOM) at the root of the open portion, generated by tooling on every release, not maintained by hand.

5. Healthcare-specific notices — separate documents, not licence terms

These are drafted as their own short notices, not folded into the licence, because they are product and clinical-safety statements, not grants of rights. A licence answers "what may you do with this code"; these answer "what does this software claim about itself." Suggested filenames, to sit alongside LICENSE and NOTICE:

NOTICE_NO_WARRANTY_CLINICAL_USE.md — states plainly that the software is provided with no warranty of fitness for clinical use, that it has not been validated for use in patient care in any jurisdiction, and that deploying it clinically is entirely the deploying institution's own responsibility and risk. This is in addition to, not instead of, the licence's own standard disclaimer of warranty (both MPL-2.0 and AGPL-3.0 already disclaim warranty generally; this notice makes the clinical-specific version explicit and prominent, matching OpenMRS's own pattern of adding a health-specific disclaimer on top of a standard OSS licence).
NOTICE_NO_AUTOMATED_DECISIONS.md — states that the software never approves, denies, recommends, or pays anything on its own; every consequential action is taken by a named human. This mirrors the two boundary sentences already used on the commercial site: "receipts prove process, not truth" and "a named human still decides."
NOTICE_NOT_A_MEDICAL_DEVICE.md — states that the software is not represented as, and has not been cleared or approved as, a medical device by the FDA, the EU (MDR/IVDR or AI Act "high-risk AI system" pathways), Australia's TGA, or any other regulator, and that no such claim should be inferred from its use of clinical terminology or FHIR profiles.
NOTICE_SYNTHETIC_DEMO_DATA.md — states that any demo, fixture, or example data shipped with the software is synthetically generated and does not represent any real patient, member, claimant, or clinician, matching the project's own is_synthetic fixture-provenance pattern and the fixtures-only lock it references.

Each of these should be one paragraph, plain language, and linked (not merged) from the main README of the open portion. Counsel should confirm whether any of them need to be more than a courtesy notice — e.g., whether a jurisdiction's law requires a specific medical-device disclaimer form to have legal effect.

Back to licensing