RFC: a sustainable future for Go Micro as an embeddable runtime

Go Micro has created real value over a long period: it has helped people build systems, generated consulting and contract work, attracted investment, and built a community. What it has not yet produced is a repeatable business model that can fund the framework itself over the long term.

This issue is to discuss that openly with the community. No licensing decision has been made.

The direction

The opportunity for Go Micro is bigger than being another microservices toolkit.

The emerging direction is an embeddable Go runtime where services, agents, and workflows can use the same building blocks: transport, discovery, messaging, storage, configuration, orchestration, and runtime lifecycle.

In short:

Build agents that operate real services.

Go Micro should remain useful as a Go library inside someone else's product, a statically linked binary, a self-hosted system, or the foundation of a larger platform. Embeddability is not a side use case; it is central to the value of the project.

The goal

We need a model that does three things at once:

1. Keeps Go Micro easy to inspect, adopt, run locally, self-host, and embed.
2. Gives the community confidence that the project will remain available and useful.
3. Creates a durable economic reason to maintain the core, documentation, integrations, releases, and ecosystem.

A model that prevents normal embedding would undermine the product. A model with no commercial boundary at all leaves maintenance dependent on intermittent contracts, funding, or unpaid work. The useful answer is somewhere between those outcomes.

Principles

Any proposal should start from these constraints:

• Existing Apache 2.0 releases remain Apache 2.0. Nothing would be changed retroactively.
• The process should be public, with time for users and contributors to respond.
• Source access and self-hosting should remain first-class.
• Terms must be understandable without every adopter needing a lawyer.
• Individual developers, learning, experimentation, and genuine open-source use should have a clear path.
• Commercial value should be attached to something scarce and useful—not artificial inconvenience.
• Before changing the licence for future work, we would need proper legal advice and a careful review of copyright, contributor history, and future contribution governance.

Models worth learning from

These are precedents to study, not a shortlist that has already been selected.

SQLite: open core, paid certainty and embedded capabilities

SQLite keeps its core in the public domain while selling warranty-of-title licensing, support, and proprietary extensions. It demonstrates that an embeddable component can remain extremely accessible while commercial users pay for legal certainty, specialist capabilities, or a closer supplier relationship.

A Go Micro version of this model might keep the framework under Apache 2.0 while offering separately licensed embedded modules, certified/provenance-backed distributions, warranties, long-term maintenance, or other capabilities that companies genuinely value.

The attraction is minimal disruption to adoption. The question is whether Go Micro has enough defensible, paid value outside the core to sustain development.

wolfSSL: open-source or commercial embedding

wolfSSL uses dual licensing: GPLv3 for open-source use and a commercial licence for businesses embedding it in proprietary products.

This creates a direct answer to “who pays?”: organisations that want to redistribute the framework inside closed commercial products without taking on the open-source licence obligations.

This is one of the clearest models for an embeddable software component, but applying it to Go Micro would require decisions about future code, contributor rights, compatibility, and the effect on the existing community.

Qt: community and commercial licences

Qt also combines open-source and commercial licensing. Commercial customers pay where proprietary product requirements do not fit the open-source terms.

It is a useful precedent, but not necessarily a licence to copy. Go commonly produces statically linked binaries, and even Qt notes that static linking can make LGPL compliance more demanding. Any Go Micro model must fit how Go software is actually built and distributed.

Business Source License: source available, then open later

The Business Source License permits source visibility and specified uses, with code converting to an open-source licence after a defined period. Commercial use outside an “Additional Use Grant” requires another licence.

This can fund infrastructure products, but it may be a poor fit for a framework whose value depends on broad production embedding. A narrowly drafted restriction could deter exactly the users we want. If considered at all, the permitted-use boundary would need to be unusually clear and generous.

Possible shapes for Go Micro

The discussion does not need to choose only among existing templates. Plausible directions include:

• Apache core plus commercial embedded components: keep the framework permissive; sell proprietary modules, verified distributions, warranty/provenance, or other embedded capabilities.
• Dual licensing for future versions or specific modules: an open-source licence for compatible projects and a commercial licence for proprietary redistribution or embedding.
• Source-available future components: use a BSL-style licence for particular commercial components, with broad permitted use and eventual conversion to open source.
• A hybrid: preserve a clearly defined open framework while placing new, high-value runtime components behind a commercial or dual licence.
• Sell Go Micro: transfer ownership and stewardship to an organisation with the resources and strategic reason to invest in it.

A sale should be considered on the same terms as any licensing change: whether it gives Go Micro a credible long-term home, preserves value for existing users, funds continued development, and keeps the framework aligned with its embeddable direction. It would not simply be a financial exit; the identity, licence commitments, roadmap, governance, and treatment of the community would all matter.

Support and sponsorship can complement any of these, but they should not be mistaken for the whole business model. The core question is whether Go Micro itself creates something organisations will reliably pay to use, embed, redistribute, or acquire.

Questions for the community

If you use, have used, contribute to, or evaluated Go Micro, concrete answers would be especially helpful:

1. How are you using it: application dependency, internal platform, commercial product, on-device software, hosted service, or something else?
2. Is Go Micro embedded in software you distribute to customers?
3. Which parts of the framework create the most value for you today?
4. What licensing change would cause you to remain on the last Apache release or fork the project?
5. Would your organisation consider paying for any of the following?
   • commercial redistribution or proprietary embedding rights
   • warranty of title and verified source provenance
   • maintained or certified releases
   • proprietary embedded modules or integrations
   • long-term support for a release line
6. Which ecosystem model earns the most trust: SQLite, wolfSSL, Qt, BSL, or another example?
7. If future relicensing required a contributor agreement or different governance, what would make that acceptable or unacceptable?
8. What should always remain freely available in the core?
9. Would a transfer to a committed long-term owner be preferable to changing the project's licensing model? What commitments would that owner need to make?

Please share real constraints where possible—company policy, procurement requirements, static-linking concerns, device distribution, fork risk, or budget ownership. That evidence is more useful than a simple vote.

Proposed next step

Use this issue to collect examples and objections, then publish a concrete proposal covering:

• the exact boundary between open and commercial code;
• the licence text and permitted uses;
• treatment of existing releases;
• contributor and copyright governance;
• migration and compatibility;
• how revenue would fund ongoing Go Micro development;
• and whether independent ownership or a transfer of stewardship offers the stronger future.

The objective is not to extract rent from the existing community. It is to make sure Go Micro can keep delivering value—and keep being maintained—over the next decade.

Start with the RFC's principles, licensing precedents, and community questions; no source files or tests are named. Gather concrete evidence about usage, embedding, licensing, governance, and funding, then define done as a public proposal covering the open/commercial boundary, licence terms, existing releases, contributor governance, migration, and stewardship.