Node on FHIR v3 - Apache 2.0 or MPL 2.0?

[awatson1978]

Dear Meteor Community,
Over the course of the years, many of you have followed my work as I created the Clinical Meteor release track, and published the Meteor on FHIR app skeleton, followed by the Node on FHIR app skeleton.

This work has been adopted by many startups, in over 100 prototypes and pilots to date, eventually even being used by Centers for Medicare and Medicaid (CMS) on numerous R&D efforts.

Well… with Meteor v3, I’m excited to announce that we’re preparing a Node on FHIR v3 release, which involved a complete rewrite of the codebase. It’s the cleanest and best working code ever, and I personally have great hopes for it. As we finalize the publication process, we’re looking at what license it gets released under.

In the past, when I was the main (only) developer on the project, Meteor on FHIR and Node on FHIR were released with a dual-license strategy. The core frameworks were released under GNU Affero v3.0, a strong copyleft license; with the intent that adopters would put their proprietary code into Atmosphere packages in the /packages directory. That was to protect me from people who would abuse and take advantage of my altruism, and try to use my own code to compete against me, when I was trying to make a living as a software engineer. While also allowing the community to contribute and improve to the core app structure, for things like HIPAA compliance, FHIR compliance, etc. It was basically a WordPress model. The core app is copyleft, and adoptees can custom brand it in a settings file and add proprietary content and business logic as a custom module.

Times change, the software engineering market is getting gutted by LLMs and copilots, and I’m doing more architecture and product management work nowadays. So, I’m not as sensitive to the issue of competition nowadays, and the MITRE/CMS team has made a request to relicense it under Apache 2.0.

Considering that I started from GNU Affero, a request to move to Apache 2.0 has ruffled my feathers a little bit; and my natural inclination was to split the difference and settle on Mozilla Public License (MPL). A soft copyleft, instead of a strong copyleft.

I think we can land at MPL as a compromise agreement; but before finalizing things; I thought I’d bring it to the Meteor community, and let the community weigh in.

Convince me one way or another?

• Apache 2.0
• Mozilla Public License 2.0
• GNU Affero

@wreiske @alanning @chafey @alimgafar @storyteller

[wreiske]

Awesome news about Node on FHIR v3!

AGPL was the right move back when you needed to protect your work more directly. Apache 2.0 would certainly open things up for bigger adoption, especially with CMS and MITRE involved now, but I see why you’re hesitating.

Personally, MPL 2.0 sounds like a nice compromise: keeps the open spirit alive without giving away all the guardrails. I think that strikes the right balance between openness and practicality, especially given the community around this project.

Anyway, just my two cents. Excited to check out the v3 release!

Cheers,
Will

[awatson1978]

Hmmm…
Claude seems to think we should go with the Apache 2.0 license.

This is a nuanced licensing decision that touches on business strategy, community dynamics, and your personal values. Let me walk through the key considerations:

The Case for Apache 2.0: Your situation has fundamentally changed. You’re now doing architecture/product work rather than competing as a hands-on developer, CMS/MITRE adoption could drive massive legitimate adoption (healthcare moves slowly but at scale), and Apache 2.0 removes friction for enterprise adoption - especially in healthcare where legal departments are notoriously risk-averse.

The “Firefox of EHRs” vision actually aligns well with Apache 2.0. Firefox succeeded not because of its license but because Mozilla maintained architectural leadership and community stewardship. Your value isn’t just in the code anymore - it’s in your domain expertise, relationships with CMS/MITRE, and understanding of healthcare workflows.

The Case for MPL 2.0: MPL is indeed a reasonable middle ground. It ensures improvements to your core files come back to the community while allowing proprietary extensions. This preserves the WordPress-like model you originally envisioned and provides some protection against wholesale appropriation.

The Deeper Question: Will people use your work to compete against you? Almost certainly. But that’s happening anyway - with AGPL, competitors either ignore the license or work around it. The real question is whether broader adoption creates more opportunities than it eliminates.

My Take: Given your evolution toward architecture/product roles and CMS backing, I’d lean toward Apache 2.0. Your competitive moat isn’t the code anymore - it’s your reputation, relationships, and deep healthcare domain knowledge. The goodwill from CMS/MITRE and broader adoption could open more doors than protecting the code closes.

The thousands of hours aren’t “given away” - they’re invested in establishing your position as the go-to expert in this space.

[alimgafar]

Since you’ve brought your LLM to the table, I’ll bring mine (Actually, I don’t really care which LLM is used. I used Gemini just to see what it would share.)

It’s been a while since I’ve done any licensing work. So many different models have evolved over the last decade that have different strategic value, I’ve left it to experts. I think about the problem now based on what is the desired outcome, what licensing models appear to fit it, what are some known tradeoffs, and what regrets I might have later with the decision. Where the model has been tested in the field and in courts, hearing from users and a review with a good IP attorney can be very helpful at arriving at an informed decision.

I dropped in your post into Gemini and added the following to it to help guide the response:

What do I get from the MPL that is more aligned with protecting my interests in the project that I would not get the Apache 2.0 license? While I am not as sensitive to competition today, is it possible that the move to Apache 2.0 may lead to "seller's remorse" later on due to unintended outcomes? What, if any, may those be?

TLDR - it suggests the MPL (I think walking through its reasoning is worthwhile.) BTW, I would not take this as solid legal strategy reasoning, but would use it to frame a discussion with someone who is a true expert, if clear confirmation matters. Here’s the full response:

The shift in licensing for your Node on FHIR project, particularly from GNU Affero v3.0 (AGPL) to Apache 2.0, with MPL as a consideration, involves significant implications. Let’s break down what MPL offers over Apache 2.0 and potential “seller’s remorse” scenarios.

What do you get from MPL that is more aligned with protecting your interests than Apache 2.0?

The core difference between MPL and Apache 2.0 lies in their copyleft nature:

• Mozilla Public License (MPL) - “File-level copyleft”:

  • Modified Source Code Must Be Shared (but only the modified files): This is the key. If someone modifies your original MPL-licensed files, they must make those modifications publicly available under the MPL. This means improvements, bug fixes, or new features directly within your core codebase (e.g., your Node on FHIR v3 rewrite) would need to be contributed back to the community if distributed.
  • No Requirement to Share Dependant/Linking Code: Unlike the AGPL, the MPL does not require an entire application or system that uses your MPL-licensed code to be open source. Proprietary code can link to and use your MPL-licensed libraries without needing to be released under the MPL.
  • Benefits for You:
    • Community Contributions to Your Core: This is perhaps the biggest win for you. If a company takes your Node on FHIR v3, makes a critical bug fix, or adds a generally useful feature directly to your files, they are compelled to share that back. This could lead to a stronger, more robust core project over time, driven by external development.
    • Prevents “Fork and Keep Secret”: It discourages others from taking your codebase, making internal improvements, and never sharing them back. They can still build proprietary products on top, but the core improvements are shared.
    • Balances Openness with Business Flexibility: It’s more permissive than AGPL, allowing commercial use and proprietary additions, but still maintains a level of reciprocity for improvements to the core.

• Apache License 2.0 - Permissive License:

  • Highly Permissive: Apache 2.0 is one of the most permissive open-source licenses. It allows users to freely use, modify, and distribute the software for any purpose, including commercial purposes, without any obligation to share their modifications or the source code of derivative works.
  • No Copyleft: There is no requirement to share modifications, even if they are made to the original Apache-licensed files.
  • Benefits for Adopters (but not necessarily for your project’s core evolution): Apache 2.0 is very popular with businesses because it imposes minimal restrictions, making it easy to integrate into proprietary products without any open-source obligations for their own code.

Is it possible that the move to Apache 2.0 may lead to “seller’s remorse” later on due to unintended outcomes? What, if any, may those be?

Yes, absolutely. While your current focus has shifted, the long-term implications of Apache 2.0 could lead to “seller’s remorse.” Here are potential unintended outcomes:

1. Loss of Core Project Momentum/Innovation:

   • “Tragedy of the Commons” for Your Core: If adopters fix bugs or add common features to your core Node on FHIR v3 codebase, they are under no obligation to share those improvements back. This means your project might not benefit from external development, and common problems might be solved repeatedly in private silos.
   • Stagnation of Public Repository: Your public repository might become less vibrant, as significant improvements and active development could be happening behind closed doors within various companies. You’d lose out on community-driven evolution of the core framework.

2. Increased Maintenance Burden on You/Core Team:

   • If others aren’t contributing back improvements, you or your new core team might bear the full burden of identifying and implementing common bug fixes and new features. You’d have to reinvent the wheel, rather than benefiting from distributed development.

3. Competition from “Your Own Code”:

   • While you’re less sensitive to direct competition now, imagine a scenario where a large company takes your Apache 2.0 licensed Node on FHIR v3, builds a highly customized and proprietary version with significant improvements, and then offers a competing service or product that is superior due to their internal advancements on your original code. You would have no claim to those improvements.
   • This is particularly relevant if, down the line, you or your current team ever wanted to offer commercial support, premium features, or consulting services based on Node on FHIR. Competitors could be leveraging your foundational work without any reciprocity.

4. Reduced Influence and Control:

   • With Apache 2.0, you effectively relinquish much of your control over the future direction and evolution of the core project in the hands of others. While this might be fine for a permissive license, it means you’d have less leverage to guide the project’s development based on community contributions.

5. Difficulty in Changing Licenses Later:

   • Once you release under Apache 2.0, it’s extremely difficult, if not impossible, to unilaterally relicense to a more restrictive license (like MPL or AGPL) in the future for existing distributed versions. Users who received it under Apache 2.0 retain those rights. While you could release future versions under a different license, it creates fragmentation and potential adoption issues.

Conclusion:

Given your history and the desire for reciprocity in your past licensing, MPL seems like a more balanced compromise than Apache 2.0.

• MPL allows commercial adoption and proprietary additions (addressing the MITRE/CMS request for flexibility).
• MPL also ensures that improvements made to your core codebase are shared back, fostering a stronger community and potentially reducing your long-term maintenance burden.

The “seller’s remorse” with Apache 2.0 stems from the potential for your carefully crafted, rewritten codebase to be significantly improved upon by others without any obligation for those improvements to benefit the broader community or your core project, potentially leading to a fragmented ecosystem and missed opportunities for collaborative development.

Ultimately, the decision depends on your long-term vision for Node on FHIR v3. If you want a vibrant, actively improving open-source core that benefits from external contributions, MPL is a strong contender. If your primary goal is maximum adoption at all costs, even if it means minimal contributions back to the core, then Apache 2.0 fits the bill.
This is a thoughtful and relevant discussion, especially given the evolving landscape of open-source and the impact of LLMs. Let’s break down the differences between MPL 2.0 and Apache 2.0, and explore the potential for “seller’s remorse.”

MPL 2.0 vs. Apache 2.0: What You Get from MPL 2.0

The core difference lies in their “copyleft” nature:

• Mozilla Public License 2.0 (MPL 2.0): Soft Copyleft (File-Level)

  • What you get: MPL 2.0 is often described as a “weak” or “file-level” copyleft license. This means that if someone modifies or extends your original MPL-licensed code files, those modifications must also be released under MPL 2.0. However, if they integrate your MPL-licensed code into a larger work, other files in that larger work that do not directly modify your original MPL-licensed files can be under a different license, including proprietary ones.
  • Protection for your interests:
    • Ensures contributions back to your core: This is the primary benefit for you. If a company uses your Node on FHIR v3 and makes improvements or bug fixes to the core files you released, they are obligated to share those improvements back under the MPL 2.0. This directly fosters community contribution and prevents proprietary forks of your core work.
    • Allows combination with proprietary code: This is its flexibility. Companies can build proprietary applications on top of your MPL-licensed core, adding their own business logic and sensitive modules under their preferred proprietary licenses. This is a good balance for adoption, as it doesn’t force their entire application to be open source, which is often a significant barrier for commercial entities.
    • Patent Protection: MPL 2.0 includes explicit patent grants and defensive termination clauses similar to Apache 2.0, offering some protection against patent lawsuits related to your code.

• Apache License 2.0: Permissive (No Copyleft)

  • What you don’t get (that MPL 2.0 provides): Apache 2.0 is a permissive license. It allows anyone to use, modify, and distribute your code for any purpose, including commercially, without requiring them to release their modifications back to the public. They only need to include the original license and copyright notices.
  • No guaranteed contributions to your core: If a company takes your Node on FHIR v3, improves it, and integrates it into their product, they are under no obligation to share those improvements with you or the community. They can essentially “fork” your project and keep their enhanced version proprietary.

Potential for “Seller’s Remorse” with Apache 2.0

Yes, the move to Apache 2.0 could lead to “seller’s remorse” later on, even if your current priorities have shifted. Here’s why and what those unintended outcomes might be:

1. Loss of Community Contributions to the Core:

   • The biggest risk: This is the most direct consequence. If your motivation for open source is to foster a community that contributes to and improves the core project, Apache 2.0 significantly reduces that incentive. Companies that make valuable improvements might keep them internal for competitive advantage, rather than contributing them back.
   • Impact on your project’s vitality: Over time, your public codebase might stagnate compared to the proprietary forks that are being actively developed and improved behind closed doors. This could diminish the perceived value and relevance of your public release.

2. Dilution of Your Influence and Control (over the “product”):

   • Loss of leverage for collaboration: With AGPL, and even MPL, you had a certain leverage: if others wanted to use your code and benefit from its open-source nature, they had to play by certain rules (contribute back, etc.). With Apache, that leverage is gone. You might find yourself in a position where others are profiting significantly from your work, but you have no mechanism to encourage their collaboration or benefit from their advancements in a structured way.
   • Competitors emerging from your own code: While you’re less sensitive to direct competition as a software engineer, think about it from a “product” or “ecosystem” perspective. If a company takes Node on FHIR v3 under Apache 2.0, heavily modifies it, and then offers it as a competing product or service, you have no recourse to benefit from their improvements or even to see what they’ve done. This could still feel like “seller’s remorse” if their version outcompetes yours in the market.

3. Reduced Incentive for Others to Engage with Your Public Project:

   • If companies can simply take and modify your code without giving back, what’s their incentive to participate in your public forums, report bugs, or even engage in discussions that might benefit your core development? They might just “take” the code and run with it.

4. No Mechanism for Funding Future Core Development (through license strategy):

   • Your previous dual-license strategy with AGPL was a way to potentially monetize your expertise or the proprietary extensions. While your current focus is different, an Apache 2.0 license closes off any future possibility of leveraging the license itself for direct revenue generation (e.g., through proprietary add-ons or support that rely on a strong copyleft core).

Why MPL 2.0 is a Good Compromise in Your Situation

Given your journey and current considerations, MPL 2.0 appears to be an excellent middle ground:

• Balances openness and protection: It is sufficiently open to encourage widespread adoption, especially by commercial entities, because it allows them to keep their own added-value proprietary.
• Encourages reciprocity where it matters: It ensures that any improvements made to your core Node on FHIR v3 codebase (the files you released under MPL 2.0) are contributed back, fostering a healthier, collectively improved core.
• Mitigates “seller’s remorse”: By ensuring modifications to your core come back, you retain a level of influence over the evolution of the foundational code and benefit from the community’s efforts, even if you’re not the primary developer anymore.
• CMS/MITRE compatibility: MPL 2.0 is generally well-regarded and understood in enterprise and government contexts, and its compatibility with other licenses (including GPL and Apache in many cases) makes it a pragmatic choice.

Recommendation

While the request from MITRE/CMS for Apache 2.0 is a strong pull due to potential adoption, your intuition to go with MPL 2.0 is well-founded. It truly splits the difference between your historical strong copyleft and a fully permissive license, offering a solid balance that protects your interests in the long run without significantly hindering adoption.

Clearly communicating the rationale for MPL 2.0 to the MITRE/CMS team, highlighting its benefits for community contributions to the core, while still allowing for proprietary extensions, could be a key to getting their buy-in. It demonstrates your commitment to open collaboration while retaining a mechanism for the continuous improvement and vitality of the foundational project you’ve poured so much into.

[alimgafar]

You’ll decide what you think is best. I worked with the premise that whatever license model, I think whomever benefits, given the amount of work you put into the software, it should be clear to all that your contribution is there, and what it is. To me, acknowledgement of others’ work matters when one benefits from contributed materials. OSS contributors should at least get that much.

[alimgafar]

Curious to know if Mitre’s preference for Apache 2.0 is because they believe any modifications they make confer upon them some competitive advantage that they would be unwilling to share.

[awatson1978]

Thanks for chiming in! Interesting to see that Gemini is in favor of MPL. We’ve talked about presenting this at Meteor Impact conference; and there’s an aspect where I want to ask not just what is best for me, but what would the Meteor community be most comfortable with. Assuming this is an app skeleton, an ideal outcome would be to register the repository so people can:

meteor create --node-on-fhir myapp

Just like they can do with --react flag, to get the react skeleton.

I wonder if @gabsferreira, @nachocodoner, or anyone else on the Meteor Team have opinions?

[awatson1978]

It’s not exactly competitive advantage. MITRE is a federally funded R&D laboratory, and they are legally not allowed to compete with industry. So productizing and going to market isn’t in their DNA in the same way as most organizations. So, when doing open-source, they often have a ‘dump some prototype software in the open, and let others run with it’ mentality. But Node on FHIR was originally envisioned as a WordPress model, where organizations are sharing the effort to get some difficult compliance work done… HIPAA, FHIR, TEFCA, FDA, etc. It takes a long time to get software past compliance review; and forking and rebranding it could cause confusion in ways that could bite people in the ***. So, this app skeleton is a different thing.

[alimgafar]

BTW, I crafted a system prompt to have the LLM act as a legal strategist with blah, blah, blah. ← used in both LLMs.

Here’s what I got back from ChatGPT when I posted the same context I used in Gemini:

Thank you, Alim. This is exactly the kind of thoughtful, strategic licensing discussion that matters—not just for legal protection but for steering the culture and sustainability of a project.

You’re right to be cautious here. The decision to move from AGPL to Apache 2.0, or to compromise with MPL 2.0, is not a trivial one. Each comes with a very different set of assumptions about control, community expectations, commercialization, and long-term leverage. Let’s walk through your key questions and concerns.

---

TL;DR Summary

• MPL 2.0 gives you a middle ground: you keep a measure of control over core code (via file-level copyleft) while allowing proprietary extensions and broad community use.

• Apache 2.0 is highly permissive, with no copyleft, strong patent protections, and encourages wide adoption—but at the expense of any obligation for giving back.

• Moving from AGPL to Apache 2.0 may feel like a loss of control, and could absolutely lead to “seller’s remorse” if:

  • A commercial actor forks your code, builds a closed solution, and never credits or contributes back.
  • You later want to commercialize but have no licensing leverage.
  • The community stagnates because there’s no reason for them to share improvements.

---

1. Tradeoff Comparison: AGPL vs. MPL vs. Apache 2.0

License	Type	Copyleft Scope	Commercial Use	Contribution Back	Patent Protection	Community Culture
AGPLv3	Strong copyleft	Network use + full codebase	Allowed, must open derivative works	Required	Yes	Community-first, anti-competitive
MPL 2.0	File-level copyleft	Only modified files	Allowed, can mix with proprietary	Required for modified MPL files only	Yes	Cooperative middle ground
Apache 2.0	Permissive	None	Fully allowed, including closed forks	Not required	Yes + explicit grant	Enterprise-friendly, commercial-first

---

Why MPL 2.0 Might Be a Smart Compromise

The Mozilla Public License (MPL) allows you to:

1. Permit commercial use and proprietary modules, like WordPress plugins or Meteor packages.
2. Ensure changes to your core codebase (individual files) are shared back if distributed.
3. Avoid the “viral” nature of AGPL, which can discourage adoption.
4. Maintain moderate leverage over those who want to fork and evolve the base software.
5. Remain OSI-approved and open source, unlike BSL or SSPL.

This aligns well with:

• Encouraging adoption (especially among federal entities like CMS)
• Preserving the ethical commons of the core app
• Reducing your long-term maintenance burden by requiring core-level contributors to publish their changes

What MPL Doesn’t Give You

• It doesn’t enforce the “network use” clause like AGPL.
• It won’t prevent closed forks of your app if the fork only uses your core files unmodified.
• It allows for some extract-and-fork behavior if users refactor your code cleverly.

---

What Apache 2.0 Changes (and Risks)

Moving to Apache 2.0 could be beneficial if your only goal is maximum adoption. But it comes at these risks:

1. You Lose All Copyleft Leverage

• Companies can fork your code, remove your name, and commercialize it without attribution or contribution.
• Your years of labor can become someone else’s product without recourse.
• You can’t require upstreaming of changes—core improvements may disappear into closed forks.

2. You May Regret It When Monetization Is Back on the Table

If you ever return to a commercial model, you’ll lack:

• Exclusive licensing rights (you’ve already given those rights to the world)
• Control over derivative works
• Any leverage over your own work’s ecosystem

3. The Community May Fragment

Apache 2.0 encourages parallel ecosystems rather than a unified community contributing back. Examples:

• MongoDB: moved away from AGPL due to AWS commercializing without giving back
• Redis: dual-licensed Redis modules when facing exploitation
• Elastic: famously abandoned Apache 2.0 for SSPL after AWS monetization

---

Strategic Guidance Based on Your Position

You’re no longer just a developer. You’re the architect and steward of a widely used health IT project. Your goals are now:

• Stewardship over a meaningful commons
• Ongoing reputation and influence in the space
• Flexible options for potential future funding, reuse, or commercial packaging

Given that:

MPL 2.0 is a well-aligned choice if:

• You want to protect core code without enforcing copyleft over user-created modules
• You’re open to adoption but still care about stewardship
• You’re concerned about long-term community cohesion

Apache 2.0 is risky unless:

• You’re completely sure that wide adoption is more important than control
• You’re willing to lose influence over where your work goes
• You have zero intent to ever return to commercializing the project

---

Final Thoughts and Additional Options

You might also consider:

License	Description
Dual licensing (MPL + Commercial)	MPL for open source users, commercial license for enterprises who want full proprietary rights
Business Source License (BSL)	Delayed open-source release (e.g. 3 years), proprietary in interim. Used by MariaDB, Sentry.
Contributor License Agreement (CLA)	Keep license permissive (e.g. Apache 2.0), but require contributors to sign over some rights to a foundation or yourself
Foundation Model	Create a community-led governance model (similar to OpenJS Foundation) to manage licensing decisions collaboratively

---

Would you like me to help draft a comparative memo or a communication brief for stakeholders like MITRE/CMS explaining the benefits of MPL over Apache?

Also happy to walk through what a dual-license or CLA setup might look like if you want a path to keep both community and commercial flexibility open.

Again MPL. Very similar reasoning. It’s not the LLM. It’s the frame.

[alimgafar]

Domain-specific app skeletons I think would be a big plus for MeteorJS.

[awatson1978]

I think an alternative question for the MeteorJS community would be:

What licensing and project governance structure would be needed for this to get adopted as an app skeleton in the official tooling?

[alimgafar]

I believe most official MeteorJS code is MIT licensed. The distinction is that it is a very permissive model (like Apache 2.0), but without the explicit patent grant found in the Apache model.

Honestly, I would be surprised if using an MPL license on the skeleton were a sticking point. It doesn’t stop distribution or modification and it doesn’t restrict any of the MeteorJS code.

Not sure what governance issues you are considering. In terms of contributing and maintaining the skeleton code itself?

@fredmaiaarantes thoughts?