Software Engineering , , , , ,

Open Source Licences for Startups: MIT, Apache, AGPL, BSL

Shelves of legal reference books in a law library

Licence choice is a commercial decision that founders keep delegating to whoever opens the repository. The last eight years have supplied a long list of companies that learned this the expensive way: MongoDB, Elastic, HashiCorp and Redis all relicensed core products, and three of the four triggered a fork that now competes with them.

What follows is what each family actually obliges you to do, what AGPL section 13 really triggers, and why the contributor agreement you set up on day one determines whether any of these moves is available to you later.

Three families, not two

Licence Family OSI-approved Express patent grant Obligation you inherit
MIT Permissive Yes No Keep the copyright and licence notice
Apache 2.0 Permissive Yes Yes (section 3) Notice file, mark changed files, patent peace
AGPLv3 Copyleft (network) Yes Yes (section 11) Offer source to remote users of your modified version
BSL 1.1 Source-available No No No production use beyond the Additional Use Grant, until the Change Date
SSPL Source-available No Yes (GPLv3-derived text) Publish the whole service source if you offer the software as a service

MIT versus Apache 2.0

The interesting difference is not length. The MIT licence, in the text published by the Open Source Initiative, grants permission “to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies,” and says nothing whatsoever about patents. Whether an implied patent licence arises is a question for a court in your jurisdiction, which is exactly the kind of question a corporate acquirer’s counsel does not enjoy.

Apache 2.0 removes the ambiguity in section 3, which grants “a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work.” The exception is the patent-peace clause:

“If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.” — Apache License 2.0, section 3

Apache 2.0 also adds real obligations in section 4: reproduce attribution notices from any NOTICE file in derivative works, and give prominent notice of which files you modified. For a startup releasing a library it wants enterprises to adopt without a legal review, Apache 2.0 is the sensible default. For a fifty-line utility, MIT is fine.

What AGPL actually triggers

AGPLv3 is widely described as banning SaaS use of the code. That is not what it says. Section 13 of the GNU Affero General Public License version 3, published on 19 November 2007, provides that “if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network… an opportunity to receive the Corresponding Source of your version.”

Three consequences follow. Running an unmodified AGPL program as a network service does not oblige you to publish anything of your own. Modifying it and exposing the modified version over a network does, and the offer must be prominent to the users interacting with it, not buried in a compliance page. And the scope is the Corresponding Source of the modified program, not your entire product, though where the boundary sits between “your application” and “a modified version of the Program” is precisely the grey area that makes counsel at large enterprises ban AGPL dependencies outright rather than litigate the question.

That blanket-ban behaviour is the practical reason AGPL is a commercial tool. It does not stop a competitor from reselling your software. It makes doing so unattractive, while keeping the licence OSI-approved.

Source-available licences and why they exist

The Business Source License, written by MariaDB’s David Axmark and Michael Widenius, has three moving parts. Production use is prohibited by default, except as permitted by an Additional Use Grant the vendor writes itself. A Change Date converts the code to a Change License, which must be GPL version 2.0 or later. And the Change Date can be no later than the fourth anniversary of first public distribution of that code. BSL 1.1 is the current version, reviewed by OSI co-founder Bruce Perens, and MariaDB is explicit that BSL is not itself an open source licence. Sentry’s Functional Source License tightens the same idea: two years, converting to Apache 2.0 or MIT, with less room for vendor-specific variation.

The Server Side Public License is a different instrument. MongoDB adopted it on 16 October 2018, covering releases from that date; earlier versions remain under AGPLv3. Its section 13 requires anyone offering the software as a publicly available service to release the complete Service Source Code under the SSPL, including management software, user interfaces, APIs, automation, monitoring, backup, storage and hosting software, such that “a user could run an instance of the service using the Service Source Code you make available.” Building an application that merely uses MongoDB as a database does not trigger it. Offering MongoDB-as-a-service does. The Open Source Initiative rejected the label on 19 January 2021, writing that what a company “may not do is claim or imply that software under a license that has not been approved by the Open Source Initiative… is open source software.” MongoDB’s own FAQ now states the same.

The relicensing record

  1. 16 October 2018. MongoDB moves MongoDB Community Server from AGPLv3 to the SSPL.
  2. 2021. Elastic moves Elasticsearch and Kibana off Apache 2.0 to SSPL and the Elastic License, citing market confusion created by a competing AWS offering.
  3. 19 January 2021. The OSI publishes its formal position that the SSPL is not an open source licence.
  4. 10 August 2023. HashiCorp adopts BSL 1.1 for future releases of Terraform, Vault, Consul, Nomad, Packer, Waypoint and Boundary, keeping APIs and SDKs under MPL 2.0. The announcement is direct about the target: “Vendors who provide competitive services built on our community products will no longer be able to incorporate future releases, bug fixes, or security patches.”
  5. 10 January 2024. OpenTofu 1.6, the Terraform fork, reaches general availability as a Linux Foundation project roughly four months after the fork began, with backing that the foundation’s announcement said included Cloudflare, Buildkite, GitLab and Oracle.
  6. March 2024. Redis relicenses to RSALv2 and SSPLv1.
  7. 28 March 2024. The Linux Foundation launches Valkey under BSD 3-clause, backed by AWS, Google Cloud, Oracle, Ericsson and Snap. The foundation’s Chris Aniszczyk framed the point: “having this project in the hands of a foundation, rather than a single company, means Valkey will be community-driven without surprise license changes that break trust.”
  8. 29 August 2024. Elastic founder Shay Banon announces on the company blog that Elasticsearch adds AGPL as a licensing option alongside ELv2 and SSPL.
  9. 1 May 2025. Redis 8 ships with AGPLv3 added, and Redis states on its blog that the SSPL is not truly open source because the OSI had clarified that it lacks the requisites for OSI approval.

The pattern is worth naming. Source-available licences reliably achieve their stated goal of blocking hyperscaler resale, and reliably produce a foundation-governed fork with the resale-capable clouds as its sponsors. Two of the four companies above have since re-added an OSI-approved copyleft licence, which suggests AGPL was the option that would have done the job in the first place.

CLA or DCO, and why it decides everything else

Every relicensing event listed above required one thing: the company held sufficient rights in all the code. That is what a Contributor Licence Agreement buys. A CLA has contributors grant the project owner broad rights, often including the right to relicense, which is what makes both future licence changes and commercial dual licensing possible.

The Developer Certificate of Origin, version 1.1, published by the Linux Foundation, does something narrower. A contributor adding a Signed-off-by line certifies only that they wrote the contribution or have the right to submit it under the project’s existing licence, that the submission record will be public, and that it may be redistributed under the project’s terms. No rights are assigned to anyone. A DCO project therefore cannot be unilaterally relicensed once outside contributions land, which is a feature if you are an adopter and an obstacle if you are the vendor.

Dual licensing runs on the same rights. Offering the same code under AGPLv3 and under a paid commercial licence that waives the copyleft obligation only works if you can license the whole codebase both ways. Adopt a DCO, take significant external contributions, and that business model closes behind you.

A defensible default for a new company

Release libraries, SDKs and client code under Apache 2.0, because you want maximum adoption and the express patent grant removes a procurement objection. Release the server or engine, the thing a competitor could resell, under AGPLv3, and require a CLA so a commercial licence and any future change remain yours to make. Reach for BSL or FSL only if you have a specific competitor and can write an Additional Use Grant that leaves ordinary users unaffected, and expect a fork if your project is infrastructure that clouds already resell. Whichever you pick, write the choice and its reasoning into a one-page document your first ten engineers can read, because the licence you can defend in year five is the one you understood in year one. None of the above is legal advice; a lawyer who has read your actual dependency tree is worth the hour.

Sources

Tag

Related Posts

Post Comment

You May Have Missed