The Case for Source-Available Licensing in Developer Tools

Colony’s source code is on GitHub. You can read it, audit it, fork it, modify it. But it’s not “open source” in the OSI-approved sense.

We use the Functional Source License (FSL-1.1). One restriction: you can’t offer Colony as a hosted service to compete with us.

This decision sparks questions. Why not MIT or Apache 2.0? Isn’t this just open source theater?

Let’s talk about the tradeoffs, why this model makes sense for developer tools, and what it means for you.

The Open Source Spectrum

Open source isn’t binary. It’s a spectrum:

Pure open source (MIT, Apache 2.0): Anyone can do anything, including selling hosted versions that compete with you.

Copyleft (GPL, AGPL): You can use and modify, but if you distribute it (or with AGPL, offer it as a service), you must open source your modifications.

Source-available (FSL, BUSL, SSPL): Source is visible and modifiable, but certain commercial uses are restricted (usually hosting as a service).

Proprietary: Source is closed, no modifications allowed.

Colony sits in source-available. FSL-1.1 allows:

Using Colony for your own development
Reading the source to understand how it works
Auditing for security
Forking and modifying for internal use
Contributing back (MIT-licensed contributions)

What FSL-1.1 doesn’t allow:

Offering Colony as a hosted service to third parties

That’s it. One restriction. And after two years, the license converts to Apache 2.0. Every release becomes fully open source within two years.

Why Not Apache 2.0 From Day One?

We need a sustainable business model. If we released Colony under Apache 2.0 today, here’s what would happen:

Scenario 1: The AWS Problem

A cloud provider sees Colony gaining traction. They:

Fork the Apache 2.0 code
Offer “Managed Colony” as a cloud service
Leverage their existing customer base and infrastructure
Undercut our pricing

We lose the ability to monetize hosted Colony. Our only revenue is enterprise support, which doesn’t fund R&D at the pace needed to compete.

Scenario 2: The Fragmentation Problem

Multiple companies fork Colony and create incompatible versions:

“Colony Enterprise” with proprietary extensions
“Colony Cloud” with a different API
“Colony Lite” with features removed

The ecosystem fragments. Users don’t know which version to use. We lose the ability to steer the project’s direction.

These aren’t hypothetical. They’re what happened to Redis, Elasticsearch, and MongoDB — all of which started as open source and later switched to source-available after being exploited by cloud providers.

The HashiCorp and Elastic Precedent

We’re not alone in this decision.

HashiCorp (Terraform, Vault, Consul): Switched from MPL to BSL in 2023. The reason? AWS and other cloud providers were offering hosted versions without contributing back.

Elastic (Elasticsearch, Kibana): Switched from Apache 2.0 to SSPL in 2021. AWS had launched “Amazon Elasticsearch Service” and was making more money from Elasticsearch than Elastic itself.

Sentry (error monitoring): Uses FSL-1.1 — the same license as Colony. They’ve been transparent about why: it protects them from cloud providers offering “Sentry-as-a-Service” while still allowing self-hosting.

The common thread: hosted services are the primary threat, not internal corporate use. Companies don’t mind if you run their software on your own infrastructure. They mind if you resell it as a competing product.

What About Trust?

The biggest criticism of source-available licensing is that it erodes trust. Users worry:

“What if you change the license retroactively?”

Licenses are tied to specific releases. If you download Colony v1.0 under FSL-1.1, that version is FSL-1.1 forever. We can’t change it. And after two years, v1.0 automatically becomes Apache 2.0.

“What if you go out of business?”

If Colony shuts down, the code remains available under FSL-1.1. And because FSL has a time-based conversion clause, all releases eventually become Apache 2.0 anyway.

“What if I want to fork it for internal use?”

You can. FSL-1.1 explicitly allows forking and modification for internal use. You just can’t offer it as a hosted service to third parties.

“What if you become hostile to the community?”

This is the real risk with any company-controlled project. But FSL-1.1 includes a governance escape hatch: if we stop maintaining Colony or become unresponsive, the community can fork under FSL (for internal use) or wait for the two-year conversion to Apache 2.0.

Why Source-Available Builds Trust

Ironically, source-available licensing increases trust for developer tools:

Auditable code. You can read every line of Colony’s source. No hidden telemetry, no backdoors, no proprietary black boxes. If we claim agents are isolated in network namespaces, you can verify it.

No vendor lock-in. Because the source is available, you can fork it if you need to. You’re not dependent on our APIs or proprietary formats. Colony uses standard formats (Protobuf, TOML configs, Jujutsu repos).

Sustainable development. By restricting hosted services, FSL-1.1 ensures we can monetize Colony without resorting to crippled “community editions” or feature paywalls. All features are in the source code, not locked behind enterprise licenses.

Alignment with users. We make money when you succeed with Colony. If you’re using Colony internally, we’re not competing with you — we’re enabling you. The license restriction only affects direct competitors.

Compare this to traditional proprietary dev tools (JetBrains IDEs, GitHub Copilot, many CI/CD platforms). They’re closed source, you can’t audit them, and you’re entirely dependent on the vendor’s roadmap. FSL-1.1 gives you more control, not less.

The Two-Year Conversion: Proof of Intent

FSL-1.1’s defining feature is the automatic conversion to Apache 2.0 after two years. This is a binding commitment written into the license.

Why this matters:

For users: You know any version of Colony will become fully open source within two years. Concerned about long-term lock-in? Wait two years and you have a fully open-source version.

For the project: It prevents us from accumulating a massive code base under a restrictive license. Every two years, a new wave of code enters the open source commons. This keeps us honest.

For the ecosystem: Even if Colony dies, the technology doesn’t. Two years after our last release, the entire code base becomes Apache 2.0 and can be forked freely.

Think of it as delayed open source release. We get a two-year head start to build a business, and then the code belongs to everyone.

When Full Open Source IS the Right Choice

FSL isn’t right for every project. Pure open source (MIT, Apache 2.0) makes sense when:

You’re building a standard or protocol. If the goal is ecosystem adoption, openness accelerates that.

You’re not the product. If your business model is services/consulting around the tool, you want maximum adoption even if competitors use your code.

You have multiple revenue streams. If hosted services aren’t your primary business, the risk is lower.

You don’t plan to offer hosted services. If you’re building a side project or community-driven tool, FSL’s restrictions might alienate contributors without providing business benefits.

Colony doesn’t fit these categories. We’re building a product that’s valuable specifically as a hosted service. FSL-1.1 is the right license for this stage.

The Future: Apache 2.0 Releases

Starting two years after Colony’s first release (targeted for late 2026), we’ll begin publishing Apache 2.0 versions. Fully open source, no restrictions.

By 2028, assuming we’re still actively developing Colony, we’ll have:

Current releases: FSL-1.1 (latest features, two-year countdown to Apache 2.0)
2-year-old releases: Apache 2.0 (fully open source)
4-year-old releases: Apache 2.0 (historical versions)

This creates a dual-licensed ecosystem: users who want the latest features use FSL-1.1 (with the hosted service restriction), and users who want full open source wait two years or use older versions.

We’re betting most users will prefer the latest features and won’t mind FSL’s restriction (since they’re not building competing hosted services). But if we’re wrong, the Apache 2.0 releases are there as a fallback.

Source-Available Is the New Normal

The developer tools landscape is shifting. Pure open source worked when cloud providers weren’t aggressively repackaging OSS projects as managed services. That world is gone.

Source-available licenses like FSL, BUSL, and SSPL are the industry’s response. They preserve the benefits of visible, auditable code while protecting companies from predatory competition.

For users, this is better than the alternative: more dev tools going fully proprietary because open source is unsustainable. FSL-1.1 lets us build a business and share the source code.

Want to see what source-available licensing looks like in practice? Join the waitlist for Colony, and check out our source code on GitHub.