Re-Licensing Sentry

More than a decade ago, a small piece of code that would eventually be called Sentry was born. When I wrote this code, I didn't know much about open-source, so when it came down to licensing, I just grabbed the first reasonable suggestion thrown my way. That suggestion happened to be the BSD 3-Clause License.

Fast forward to today, and a lot has changed. Sentry is far more than that original 70-line snippet; it's a complex product made up of millions of lines of code that is used by tens of thousands of businesses around the world. It’s also no longer a personal project; it now employs nearly 100 individuals who depend on it for their livelihood.

Sentry – both the project and the company – is large enough now to question whether the licensing decision made 11 years ago was the right one.

Deciding to Re-license

For a few years now, we had been talking about re-licensing Sentry. Primarily, we wanted to standardize on an open-source license across all of our projects. These would replace our existing diverse use of Apache-2.0, MIT, and BSD 3-Clause across our hundreds of repositories, and ensure Sentry developers didn't need to make licensing decisions on future work.

Initially, our thinking was to standardize on Apache-2.0, which is a well-understood and widely adopted free, open-source license. But before rushing into another licensing decision, we stepped back and wrote down the few goals we had:

• Anyone should be able to run Sentry for themselves or their business

• No difference between our cloud service and our open-source product (no open-core model)

• Minimal limitations on usage of code; as free as possible

• Protection from other companies selling our work

This last bullet point – protection from other companies selling our work – was something we hadn’t given a lot of weight to before. But several well-timed events had occurred that caused us to re-evaluate how important this was to us.

Commercializing Open-Source

We pride ourselves on delivering a unified, free, open-source service, where our cloud offering (sentry.io) has the same functionality as our open-source offering. This stands in contrast to other open-source companies, who offer a reduced "open core" feature set that moves critical features into a paid, closed-source version of the software.

Sentry is often compared with companies that operate this way, but I will be the first to stand up at the front of the room to illustrate how these models are not equal. That said, as we’ve grown, we’ve felt the pain of a purely permissive license, and better understand why companies pursue the open core model or other alternative licensing arrangements.

For example, this past year, we’ve had to deal with funded businesses plagiarizing or copying our work to directly compete with Sentry. This has included taking marketing content from our website, plagiarizing our documentation and framing it as their own, or straight-up copy/pasting our product visuals. Their defense? “Well, it’s free open-source, and we can do that.” These businesses are not using Sentry to improve how they develop software; they’re lifting its code and assets to build their closed-source products to compete directly with us.

So far, this has been less serious than some of the concerns other open-source companies have. In the last few years, the big cloud providers have provided commercial hosted offerings of popular open-source projects. Offerings that compete with those companies' own hosted solutions. We've been fortunate in that the big cloud providers have not yet tried to monetize Sentry in this way, but this distinct possibility remains an existential threat to our business.

It’s important to remember that Sentry “the project” has been developed almost exclusively by employees of Sentry “the company”; millions of dollars have paid the salaries of engineers, designers, and product people to produce the software we know and love today. We face a catch-22 problem: if we continue to use a fully permissive license, we face real competitive elements that threaten the future of Sentry and our ability to continue funding its development. But if we move to an “open core” model that better protects our IP, users won’t be able to freely modify and deploy Sentry – all of it – as they can today.

In other words, we need a licensing arrangement that satisfies our need to protect our business while allowing us to develop and distribute our source code in as open a fashion as possible.

Enter The Business Source License (BSL)

In the past year, several companies have experimented with alternative licensing arrangements to protect against these concerns. In June, we saw our friends at Cockroach Labs (the creators of CockroachDB) moving to a new protections-focused license known as the “Business Source License” (or BSL). This license seemed like it would fit well with Sentry’s goals, so we started digging deeper.

The BSL is a standardized license with two distinct components: a license grant restriction and a conversion date whereby the license “converts” to a more permissive license (without a license grant restriction). In Sentry’s case, we’ve adapted these components to mean the following:

• You cannot offer a commercial version of Sentry’s service (the license grant restriction)

• After 36 months, the code becomes Apache-2.0 licensed (the conversion period)

Although we’ve come to refer to the BSL as eventually open-source since it converts to an OSI-approved license at the conversion date, due to the grant restriction, it is formally not an open-source license.

The BSL lets us hit our goals in a clean and low-impact way: it won’t change anyone's ability to run Sentry at their company, but it will ensure that we are protected from our work being used in an anti-competitive fashion. Most importantly, it guarantees that Sentry’s source will live on, and after three years, it can be used just as it is today, with attribution.

The Future of Open-Source

We’re literally entering a new decade, and like some of our contemporaries, we believe changes need to be made in the business of open-source software. Previous licensing models – the “open core” model, GPL, and permissive licenses like BSD and Apache-2.0 – are not sufficient for the way OSS is distributed and used today. We want to explore an alternative approach, one that allows for easy adoption and open distribution of our software, but defends against competitors repackaging our work in a way that threatens Sentry’s ongoing development.

It’s a brave new world, but we believe this licensing change will best ensure the future of Sentry and that protections-oriented source-available licenses like the BSL will become increasingly common as time goes on.

Questions – we have answers

If you’re interested in understanding more about how this licensing change affects Sentry, we have prepared an FAQ that goes into more detail. We’d also like to have an open dialogue with our users and customers – please consider commenting on our forums, where we’re happy to answer any additional questions or concerns.