We have the following goals regarding our products and services:
- Anyone should be able to run Sentry for themselves or their business
- There should be no differences between our cloud service and our open-source product (no open-core model)
- There should be minimal limitations on usage of code; should be as free as possible
- There should be protections from other companies selling our work without giving back
This last bullet point — protection from other companies selling our work — may sound controversial but we found it to be necessary to ensure Sentry as a company can survive and keep working on Sentry the product.
All these lead us to use a somewhat extraordinary license, the Business Source License, which we best describe as eventually open source. Although this license is not among the OSI-approved licenses and does not fit the strict OSI definition of open source, it gives you all the freedom provided that you are not offering a commercial version of Sentry. Even more, it removes this one limitation after a 36-month grace period, turning into a bare Apache-2.0 license eventually. You can read more about our license and the whys behind it on our blog.
Since we strive to keep everything as open and free as possible, we are only using the more restrictive BSL-1.1 license on the Sentry backend code. Here are the 3 licenses we use:
All components powering the main Sentry backend use BSL-1.1 license which limits their usage in a commercial Sentry-like offering. If you need to use some of this code without the BSL license or want to commercialize Sentry, reach out to us at email@example.com. Here are all the projects covered under our BSL-1.1 license:
- All Docker images produced by the repositories above
Sentry’s default license of choice is the permissive but protective Apache-2.0 license. This license is OSI-approved, widely adopted, and still has some safe-guards like attribution requirement or patents protection. Any new projects are licensed under Apache-2.0 unless there’s a concern around GPL-2.0 compatibility for adoption.
We use the MIT license as a fallback for the Apache-2.0 license where we need to reach to a wider audience, due to the GPL-2.0 incompatibility. This is the license we use for all our SDKs.