Why Apache 2.0 and MIT: our open source license strategy

At CodeCora, we build open source software. Every product we ship, from our semantic memory engine to our developer tools to our desktop applications, lives on GitHub under an open source license. No proprietary core, no "open core" pricing tiers, no feature gates. The same code our users run is the code we run.

We are bootstrapped. No VC funding, no investor pressure to lock things down. This gives us the freedom to let our software compete on quality rather than legal moats. When someone forks Uteke or Cora Code, we see that as validation.

But "open source" is not a single decision. The license you choose shapes who can use your software, how they can use it, and what happens when commercial interests collide with community interests. We put real thought into which license fits each product. The answer is different depending on what the product is and who it serves.

License per product type

We currently maintain four open source projects, all written in Rust:

• Uteke (Apache 2.0, 150 stars, 16 forks): an offline semantic memory engine.
• Cora Code (MIT, 14 stars, 4 forks): a lightweight AI coding agent.
• Covecto (MIT, 2 stars): a vector search library.
• DrawOver (AGPL + CLA, 1 star): a desktop overlay and annotation tool.

Three licenses across four products. That is intentional. The reasoning for each follows.

Apache 2.0 for infrastructure

Uteke is infrastructure. When you build infrastructure that developers embed, fork, or build businesses on, they need legal clarity. Specifically, they need a patent grant.

Apache 2.0 provides an explicit patent grant from contributors to users. If a contributor submits code that infringes on a patent they hold, they grant a license for that patent to all users. This matters for infrastructure because the blast radius of a patent dispute is larger. A memory engine might end up inside a search system, a database, a content pipeline. Companies that adopt it want to know they will not get sued.

Apache 2.0 also keeps the patent grant consistent through its contribution model. Anyone who contributes grants the same patent license to the project and its users. No individual contributor can create a gap in coverage.

We chose Apache 2.0 for Uteke because it is the most enterprise-friendly permissive license. Some companies have policies against MIT specifically because of the patent question. We want Uteke to be adoptable by those companies.

MIT for developer tools

Cora Code and Covecto are MIT licensed. These are developer tools and libraries. The goal here is simplicity and maximum permissiveness.

MIT is short. Anyone can read it in 30 seconds and understand exactly what they can and cannot do. For a developer tool, that immediacy matters. A developer who finds Cora Code and wants to try it should not need to consult a lawyer first. The MIT license says: use it, modify it, distribute it, just keep the copyright notice. Done.

Covecto is a vector search library. Libraries get embedded into larger projects. MIT is the most widely accepted license for this use case. No friction, no surprises. If someone wants to use Covecto in a proprietary product, they can. The barrier to adoption is zero.

We do not add a CLA to these projects. The contribution flow is simple: fork, commit, open a PR. For tools of this size, that is the right tradeoff.

AGPL for end-user apps

DrawOver is AGPL licensed, with a Contributor License Agreement. This is our most restrictive license, and it needs the most justification.

DrawOver is a desktop application. End users run it directly. For this category of software, the competitive dynamic is different. A company could take DrawOver, rebrand it, ship it as a paid product, and give nothing back. AGPL prevents that.

The AGPL requires anyone who distributes the software, or makes it available over a network, to also distribute their modified source code. If a company takes DrawOver, modifies it, and sells it as a service, they must publish their modifications. You can build on our work, but you share your changes.

We pair AGPL with a CLA. The CLA gives CodeCora the ability to relicense if needed. AGPL can block adoption by companies with strict license policies, so the CLA ensures we can change direction without tracking down every contributor.

Is AGPL the right choice for a 1-star project? We think so. The license should reflect the product's trajectory, not its current popularity. DrawOver competes in a space where commercial clones are common. Setting the license expectation early is easier than changing it later.

What this means for users

If you use Uteke, you get a patent grant and broad permission to build on it.

If you use Cora Code or Covecto, you get maximum freedom. Fork it, embed it, ship it.

If you use DrawOver, you get a free and open source app. If you modify it and distribute it, you share your changes. If you just use it, nothing changes for you.

All four products are free and self-hosted first. None of them phone home, require an account, or lock features behind a paywall.

Our philosophy

The license is a tool, not a statement of values. Our values are consistent: build useful software, share the source, let people run it themselves. The license is how we express that in legal terms that fit each product's context.

Infrastructure needs patent clarity. Developer tools need simplicity. End-user apps need reciprocity. One license cannot serve all three needs well. Choosing separately for each product is more work, but it produces a better outcome for users.

We will keep evaluating these choices as the projects grow. If a license stops fitting, we will change it.