Skip to content
← LICENSING
Proposed terms — pending legal review

Sample trademark policy

These are drafts prepared for counsel. They are not in effect, and no licence has been granted.
Why an open-core project needs this document separately from the licence

An open-source licence and a trademark policy do two different jobs, and open-core projects consistently need both: the licence gives away the code; the trademark policy protects the name. A permissive or weak-copyleft licence (see the licensing options memo) lets anyone copy, modify, and redistribute the code — including under a new name, which is exactly what open-source licensing is supposed to permit. What it does not automatically permit is calling that fork "blueHealthcare" or "blueOpenHealthcare," using the company's logo, or implying the company's endorsement. Trademark law, not the software licence, is what prevents a fork from wearing the original project's name and confusing health systems, patients, or regulators about who stands behind it. OpenMRS runs exactly this kind of policy (their wiki page on it is cited throughout this document); it is the direct model for the structure below.

This sample covers the family of marks used across the healthcare line — blueHealthcare, blueOpenHealthcare, blueChart, and the other "blue…" product names — as a single policy, since they share both a naming convention and a likely enforcement approach.

Registration status is unknown. This scaffold does not know, and did not attempt to verify, whether any of "blueHealthcare," "blueOpenHealthcare," "blueChart," or the other marks are federally registered, state-registered, or unregistered common-law marks in any jurisdiction. Counsel must check the actual registration status (and file for registration where warranted) before any enforcement position is taken. Where this document says "the mark," it means "whatever legal protection the name and logo in fact have," not an assertion that registration exists.

1. What a fork may and may not call itself

May:

  • Fork the open-licensed code (per whatever outbound licence counsel selects) and give the fork an entirely new, non-confusing name and its own logo.
  • Say, accurately, that the fork is "based on," "derived from," or "forked from" blueOpenHealthcare, as a factual statement of provenance.
  • Use the phrase "Powered by blueOpenHealthcare" or "Built on blueOpenHealthcare" (or an accurate local-language equivalent) alongside the fork's own name and logo, provided the fork's own name and logo are the dominant identifier — this pattern is modeled directly on OpenMRS's own guidance: "If you are building a derivative work from/using OpenMRS, you may use the phrase 'Powered by OpenMRS' or 'Built on OpenMRS' ... in conjunction with your product's own name or logo" (OpenMRS Logo Policy: link).

May not:

  • Name itself "blueHealthcare," "blueOpenHealthcare," "blue[Anything]," or any name confusingly similar to those marks (including transliterations, or a name that differs only by adding a generic word like "Pro," "Community," or "International").
  • Use the company's logo, wordmark, or the specific "blue" + capitalized-descriptor naming pattern (Brand Law v4 rule 3, as referenced internally) as the fork's own primary identity.
  • State or imply that the fork is officially supported, endorsed, certified, or maintained by MOBLUEHQ, Inc., or that its output (a receipt, a verification result) carries the same trust guarantees as the company's own builds, unless that is actually true and disclosed accurately.
  • Use "blueOpenHealthcare" (or any "blue…" mark) as part of the fork's own package name, domain name, or app-store listing name in a way likely to cause a health system, patient, or regulator to believe they are getting the original project.
2. "Compatible with" / "built on" wording

Accurate, narrowly factual compatibility claims are permitted and encouraged — they are useful to implementers and are exactly the kind of claim OpenMRS's own policy contemplates. Acceptable patterns:

  • "[Fork name] implements the blueOpenHealthcare jurisdiction pack interface."
  • "[Fork name] is compatible with blueOpenHealthcare v[X]."
  • "[Fork name], built on blueOpenHealthcare." (fork name dominant, per §1 above)

Not acceptable:

  • Any claim of compatibility that has not actually been tested against the stated interface or fixture set (e.g., claiming FHIR-profile or jurisdiction-pack conformance without passing the project's own conformance tests).
  • Using "compatible with" as a stepping-stone to implying endorsement — e.g., "the blueOpenHealthcare edition for Country X," which reads as an official product line rather than a third-party compatible fork.
3. Logo use

Any use of the company's actual logo (as opposed to a fork's own logo) must follow the official logo package, plus Brand Law v4 and its addendum for color and lockup rules — this policy does not restate those visual rules, it defers to them. As a starting structural model (again following OpenMRS's published guidance, cited above):

  • The official logo, if displayed near a third party's own product logo, should appear no larger than a modest fraction of that product's own primary logo (OpenMRS's stated ratio is 25%; counsel and brand should decide blueHealthcare's own number rather than copy OpenMRS's exactly).
  • The logo's proportions and color values (official palette, print vs. electronic color spaces) may not be altered, stretched, recolored, or reconstructed from a low-resolution source.
  • The cross/glyph-plus-wordmark composition (if the eventual blueOpenHealthcare mark follows the same construction as the other product marks) should not be separated into its component parts for independent use.
  • No logo exists yet specifically for "blueOpenHealthcare" as of this writing (the name itself may not survive Brand Law v4's one-descriptor rule, and no logo asset exists for it). Until a mark is commissioned or the name is finalized, this policy should be read as covering the existing blueHealthcare wordmark used with an "Open" section label, not a mark that does not yet exist.
4. Enforcement posture (a starting point, not a rule)

Consistent with the low-friction, low-legal-overhead posture the rest of this scaffold uses: a first violation should typically be handled as a polite, direct request to rename or relabel, not a cease-and-desist, unless the violation involves actual patient-safety risk (e.g., a fork claiming FDA clearance or medical-device certification it does not have) or clear bad faith (e.g., cybersquatting a domain to sell it back). Escalation to formal enforcement is a decision for counsel and Adam together, not something this policy pre-authorizes.

5. What counsel should check before adopting anything above
  1. Whether "blueHealthcare," "blueOpenHealthcare," "blueChart," and the other product names are registered anywhere, and if not, whether to file.
  2. Whether "blueOpenHealthcare" survives as a usable mark at all, given an internal brand-naming rule conflict already flagged separately — this is a naming decision for Adam, not a legal one, but counsel should confirm no third party already holds a confusingly similar mark in the health-IT space before it is finalized either way.
  3. Whether a formal trademark policy needs to be a condition of the CLA/DCO (see the sample contributor terms) or can stand alone as this file does.
Back to licensing