Sample contributor terms

The outbound licence and the inbound contribution term are one bundled decision, because accepting code before both exist risks the company holding contributions it cannot redistribute under whatever licence it later picks. This file lays out both inbound options so counsel can pick alongside the outbound licence in the licensing options memo.

The Developer Certificate of Origin (DCO) 1.1 is a lightweight, industry-standard attestation, not a contract. A contributor certifies, per commit, that they wrote the contribution (or otherwise have the right to submit it) and agree it can be distributed under the project's licence. Canonical text: https://developercertificate.org/. Per that source, a contributor certifies one of: (a) the contribution is their own original work and they have the right to submit it under the project's licence; (b) it is based on prior work properly covered by a compatible licence, and they have the right to submit the modification; (c) it was provided to them by someone who certified (a) or (b) and they have not changed it; and (d) they understand the contribution and their sign-off are public and may be redistributed.

Mechanics: a contributor adds a Signed-off-by: trailer to each commit, generated automatically by git commit -s, e.g. Signed-off-by: Random J Developer <random@developer.example.org> (this convention and the -s flag are the standard git/DCO mechanism documented by DCO-checking tooling such as the Probot DCO GitHub App: https://github.com/probot/dco). Enforcement in CI is typically a GitHub Action or bot that fails a pull request missing a valid sign-off line.

Sample CONTRIBUTING section (DCO option):

## Sign off your work

Every commit must include a Developer Certificate of Origin (DCO) 1.1 sign-off. Read the
certification text at https://developercertificate.org/ before signing off — signing off means you
are certifying you wrote the change, or otherwise have the right to submit it under this project's
license.

Add the sign-off automatically:

    git commit -s -m "Describe your change"

This appends a line like:

    Signed-off-by: Your Name <you@example.com>

using the name and email from your git configuration. Pull requests with any unsigned commit will
not be merged. If you forgot to sign off, you can amend: git commit --amend -s (for the most
recent commit) or use an interactive rebase for older ones.

A Contributor License Agreement (CLA) is a separate, explicit agreement (beyond the outbound licence) in which a contributor grants the company additional rights — most importantly, the right to relicense the contribution later (e.g., to offer a commercial licence to paying customers under the "dual licence" option in the licensing options memo). The sample below is original text, structured to follow the same shape as the Apache Software Foundation's Individual Contributor License Agreement (ICLA) v2.2, whose section structure was verified directly from the canonical PDF (https://www.apache.org/licenses/icla.pdf): definitions; a copyright licence grant; a patent licence grant (with a defensive-termination clause if the contributor sues over patents); a representation that the contributor has the right to grant the licence (including an employer-rights carve-out); a representation that the contribution is original (with a separate path for third-party work); a statement that the contributor has no obligation to provide support; and an ongoing duty to notify the foundation/company if any representation becomes inaccurate. The Project Harmony contributor agreement templates were also reviewed as a second model — Harmony's own overview describes offering both copyright-licence and copyright-assignment forms, and "addressing the complexity of corporate contributions" (Harmony Agreements, Overview: https://www.harmonyagreements.org/overview.html) — but this sample follows the Apache structure specifically because it is a copyright-license form (not an assignment), which is the lighter-touch choice consistent with "counsel decides, but keep friction low."

Sample Individual CLA (original text, structure modeled on the Apache ICLA):

# blueOpenHealthcare Individual Contributor License Agreement (SAMPLE — DRAFT, NOT IN EFFECT)

Thank you for your interest in contributing to blueOpenHealthcare, a project of MOBLUEHQ, Inc.
("the Company"). To make clear the intellectual property licence granted with your contributions,
the Company asks each contributor to agree to the terms below before a contribution is merged.

1. Definitions. "You" means the individual or legal entity submitting a Contribution. "Contribution"
   means any original work of authorship, including modifications to existing work, that you
   intentionally submit to the Company for inclusion in blueOpenHealthcare.

2. Grant of Copyright License. You grant the Company, and recipients of software distributed by the
   Company, a perpetual, worldwide, non-exclusive, royalty-free, irrevocable license to reproduce,
   prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your
   Contributions and derivative works of them — including under a different license than the
   project's own open-source license, such as a commercial license offered to paying customers.

3. Grant of Patent License. You grant the Company, and recipients of software distributed by the
   Company, a perpetual, worldwide, non-exclusive, royalty-free, irrevocable (except as stated
   below) patent license to make, use, sell, offer to sell, import, and otherwise transfer Your
   Contribution, to the extent your patent claims are necessarily infringed by your Contribution
   alone or in combination with the project. If you (or your affiliate) sue anyone, including the
   Company, alleging that the project infringes a patent, the patent licenses granted to you under
   this agreement terminate as of the date you filed suit.

4. Representations. You represent that you are legally entitled to grant the license above. If your
   employer has rights to intellectual property you create, you represent that you have permission
   to contribute on the Company's behalf, or that your employer has waived such rights, or that your
   employer has signed a separate Corporate CLA with the Company (see below). You represent that each
   Contribution is your own original creation, except for any third-party material you have separately
   and conspicuously identified, with its license and source, at the time of submission.

5. No Obligation to Support. You are not required to provide support for your Contribution. Any
   support you choose to provide may be offered for free, for a fee, or not at all.

6. No Warranty. Unless required by law or agreed in writing, you provide your Contribution "AS IS,"
   without warranties of any kind.

7. Notification. You agree to tell the Company if you learn that anything in this agreement is no
   longer accurate.

Signature: _______________________  Date: _______________
Name: ____________________________  Email: ______________

Where a contribution is made in the course of someone's employment, an Entity/Corporate CLA — signed by an authorized representative of the employer, covering all of that employer's employees who contribute — is the standard companion document (this is exactly the split the Apache ICLA's own structure anticipates, and Harmony's templates offer the same individual/entity pairing). A Corporate CLA would additionally need: a list of, or a process for designating, which employees are authorized to contribute on the company's behalf; and a term addressing what happens to that authorization when an employee leaves. Drafting the Corporate CLA itself is left to counsel; it is a short document once the Individual CLA above is settled.

Framing for counsel: if the outbound licence ends up being plain MPL-2.0 or AGPL-3.0 with no commercial dual-licensing plan, DCO alone is simpler and matches how OpenMRS-adjacent, low-bandwidth contributor communities typically operate. If the dual-licence option is live, or the company wants the option to change the outbound licence later without re-clearing every contributor, a CLA is close to necessary.

No real patient data, ever. Rule, stated once, verbatim for every contribution surface: "No real patient, member, claimant or clinician data of any kind — identifiable, de-identified, 'anonymised', aggregated, or screenshot — may be posted, attached, or committed anywhere in this community. Synthetic, generated fixtures only." "De-identified" is banned too, on purpose: the company's own posture is that de-identification is itself a receipted, approved, in-institution act, and a community has no way to verify a contributor's claim that something was properly de-identified — so the only enforceable line is generated, never derived from real data by anyone, including the contributor.

Enforcement steps:

1. Issue and pull-request templates are text fields that refuse attachments, and the PR template requires ticking a box: "generated fixtures only; nothing derived from a real record."
2. Every fixture file must carry an is_synthetic: true marker and a generator field naming the tool and seed that produced it; CI rejects any fixture missing both (reusing the project's existing instrument-fixture pattern rather than inventing a second one).
3. A scanner runs in CI and pre-commit for identifier shapes — US SSN/NPI/MRN patterns, IBAN-shaped strings, phone-number patterns, a date-of-birth next to a name, realistic address lines, DICOM headers, and any non-text (binary/image/PDF) attachment — and hard-rejects a match. The scanner is published so contributors can run it locally before submitting. It is described honestly as a lie-detector for "this was pasted from a real record," not a guarantee of PHI-free content.
4. Fixtures must come from a generator (e.g., Synthea-shaped for US content; each jurisdiction pack contributes a generator configuration, never hand-authored data files). A pile of JSON with no named generator is rejected on shape alone.
5. A named moderator runs a takedown runbook on suspicion: remove the content, purge it from git history (e.g., git filter-repo), notify the contributor, and record that the event occurred (without repeating the data) in the project's public digest — time-boxed to 24 hours.

Security issues go through private disclosure, never public issues. Security vulnerabilities must be reported through a private channel (a SECURITY.md with a named contact and, once the project is on GitHub, GitHub's private security-advisory workflow), never as a public issue or discussion post. CONTRIBUTING should say this in its first section, and link to SECURITY.md and a .well-known/security.txt. A standard coordinated-disclosure window (commonly 90 days) should be stated once counsel/security leadership sets one; not fixed here.

No marketplace, dataset catalogue, buyer portal, or "sell data" surface. This is a hard prohibition, not a style preference. The company's own data-integration posture states "verified access, never data" as the operating principle, and explicitly forbids any surface that sells or catalogues data. CONTRIBUTING should state this as a project scope rule, not merely a code-review preference:

No contribution — code, documentation, issue, or design proposal — may add a marketplace, dataset catalogue, buyer portal, or any other surface whose function is to list, browse, request, or sell data or access-to-data as a transaction. This is a hard project-scope boundary, not a matter of maintainer taste, and pull requests that add such a surface will be closed regardless of code quality. If you believe a proposed feature does not cross this line, say so explicitly in the PR description and expect it to be checked carefully — "share solutions" must never become "share data."

Jurisdiction work arrives as packs, not forks. Consistent with the addendum's own architecture ("Jurisdiction is configuration — never a fork"), CONTRIBUTING should state:

Country- or region-specific work (coding systems, privacy regimes, FHIR profiles, currency, locale, payer vocabulary) is contributed as a new directory under core/jurisdiction/<code>/, implementing the existing CodingSystem, PrivacyRegime, and FhirProfile interfaces plus the JurisdictionPack fields — never as a fork of the project or a copy of core/ with local edits. A pack pull request must include a synthetic fixture and pass the interface conformance test. Do not hardcode any jurisdiction-specific constant (a coding system, a currency, a date format, a legal citation) anywhere outside your pack's own directory — the project runs an automated check for this against core/ and a PR that adds a new hardcoded constant there will fail it.