Re-licensing Sentry - FAQ & Discussion

On-Premise
1

Hello everyone!

I just wanted to announce that we are re-licensing Sentry to Business Source License 1.1 with a 36-month conversion time to Apache-2.0. You can find more details on our blog where @zeeg goes into more details. Below, you can find the FAQ we have prepared. Please do ask any questions that are not covered so we can answer them and update the FAQ.

Thank you!

FAQ for Re-licensing

Can I still use Sentry on-premise for my company or project?

As long as your company is not selling an Application Monitoring Service, you may use and modify Sentry without concern or limitations. How we define an Application Monitoring Service is in the license. It mostly comes down to “if you are not providing a competing service to Sentry.io while using Sentry the open-source project, you’re good.”

Is Sentry no longer open-source? / Is BSL a valid open-source license?

In strict terms, BSL (Business Source License) is not an open-source or an OSI-approved license. That said, it is no different from Apache-2.0 for all practical purposes except when your company is an “Application Monitoring Service” as defined in our license text. Each release and commit will automatically convert to Apache-2.0 after 36 months from their publishing date.

What is an Application Monitoring Service (APM)?

The definition of an Application Monitoring Service in our license is as follows:

An “Application Monitoring Service” is a commercial offering that allows third parties (other than your employees and contractors) to access the functionality of the Licensed Work so that such third parties directly benefit from the error-reporting or application monitoring features of the Licensed Work.

What happens to the older versions of Sentry code?

The new license will only apply to versions and code after November 1st, 2019. The older versions of the repository and any published versions (such as PyPI packages or Docker images) will stay on the old BSD 3-clause license.

Who else uses BSL?

BSL, pioneered by MariaDB, is also adopted by companies like CockroachDB and ZeroTier. It is also endorsed and improved by Bruce Perens, a prominent figure in open-source.

Does this cover all Sentry projects like the SDKs? Which repositories are affected?

The new license will only apply to the main Sentry product, its direct components, and its downstream products. The affected repositories are as follows:

Why is Sentry re-licensing?

Sentry is re-licensing, as the initial BSD 3-clause license does not provide adequate structure or the protections needed for a project as large as Sentry has become. The old license was picked speedily when Sentry was a tiny, 70-line project. Today, Sentry has grown to about a 100 person company, serving a much larger audience and with stronger support around its product. Some recent events have shown that there is potential to abuse our hard work through the very permissive BSD license. To ensure Sentry keeps growing, we have decided to switch to a license that is still very open, but with proper protections in place.

Have you considered other options/licenses/dual licensing?

Yes, we have. Dual licensing and the open core model were among the options we have investigated. Dual licensing was too broad and had the potential to reduce contributions and adoption. The open core model where the core is open-source but other components are closed-source, was also dismissed. We think the open core model disincentivizes open-sourcing more projects from the company and creates a gap between the paid version and the open version. Hence, after careful consideration, we settled on BSL.

Why Business Source License (BSL)?

We think BSL introduces minimum restrictions while converting into a fully open license in a reasonable timescale. Unlike the open core model, BSL does not provide incentives for creating more closed code while providing strong protections for our company to keep developing Sentry. Among some other licenses, we have also considered the Open-Source Eventually License, a license very similar to BSL. We landed on BSL as it is battle-tested by larger companies and has the backing of an open-source advocate, Bruce Perens.

Can I still fork Sentry?

Yes! As long as you don’t fall into the “Application Monitoring Service” definition, the license explicitly grants you “the right to copy, modify, create derivative works, redistribute, and make non-production use of the Licensed Work”. Just keep in mind that you have to carry the BSL license on until the change date stamped in the license that you are forking off of.

There is some code I want to get and reuse from Sentry codebase. Can I do this? What are my options?

If there’s some code you want to extract from Sentry to be used in another project you have 4 options:

  1. Find the same code before the commit SHA ca8674c533a0dffc48a177554479bb85fa05891b which is covered under the BSD-3 license and use that version.
  2. Carry Sentry’s BSL license over into your own project where you’ll be using the code.
  3. Wait until the code you want to reuse converts to the eventual Apache-2.0 license (typically 3-year lead time)
  4. Talk to us at oss@sentry.io as we definitely want to pull reusable components out of Sentry into open-source repositories. If that’s not possible we may still get you an explicit grant for that piece of code depending on the circumstances.
2 Likes
3

Hi Sentry team. Exciting news. I’m the Director of Product Management at GitLab and I cover our Ops section (Configure and Monitor stage). We are explicit about providing an APM solution (and we sell our Enterprise Editionshttps://about.gitlab.com/pricing/), but we also integrate (as a first class-citizen) with Sentry as part of that entire package. We love your product and would like to continue to integrate with it. Are we considered an APM provider for the purposes of your license change? Is our integration, including a future installation of Sentry as a GitLab managed app on user provided Kubernetes Clusters considered use?

1 Like
4

@kencjohnston Unfortunately that is the kind of thing we’re trying to prevent. If GitLab is bundling Sentry for its customers, who are we going to fund the development of Sentry? In that scenario you would need an additional grant on our public license. I’m not sure if we would or wouldn’t want to do that, but you can reach out to my-first-name at sentry.io if you want to have a conversation about it.

5

Great, thanks for the reply. Will do!

6

What sad news. I hate to see another company that used to be part of the open source community shuttering their source and going with a closed source model. Looks like I will have to start looking for an alternative solution. I hope you re-consider and re-open your source!

1 Like
7

@ensignavenger the code is and will stay open and will become “completely open” in 3 years time.

8

@kencjohnston, your definition off “open” code seems to be different from the Open Source Definition. I appreciate that it will eventually be open source, but I can’t wait 3 years for critical security fixes.

9

@ensignavenger - Was this meant to be directed at me?

10

Hi, I understand the need for BSL. What happens if you use sentry as part of a package?

E.g you do SAAS apps that bundle Sentry for application error monitoring?

11

I’m assuming you’re referring to bundling the SDKs, and those will maintain being fully OSS. This change only affects components related to our server.

So assuming we’re on the same page here with what you are bundling, you should be unaffected. :slight_smile:

1 Like
12

I don’t see a Contributor License Agreement on these repositories. How can you legally relicense the software, without agreement of all contributors also agreeing to relicense, seeing as that you don’t have a full copyright ownership, and don’t have an implicit or explicit copyright grant from contributors?

13

@ryan-lane - we are not relicensing retroactively. The license only applies to new code from now on.

14

Does that include any change to existing code? Changes are based on the old code, so you’d be using a new license on code derived from old code. That seems iffy at best, and is absolutely wrong from a moral perspective.

15

I am sorry, meant to be directed at @BYK! Keep up the great work at GitLab :slight_smile:

16

@ensignavenger
Unless you are trying to compete with Sentry hosted version using their own source code, I don’t see how this affect you.
Why are you so bitter?
Do you prefer seeing AWS stealing sentry source-code and claiming it’s their new technology and competing against Sentry which will eventually make them go out of business?
Companies are exploiting open-source to make money and you ok with that?

3 Likes
17

The old license was BSD, which gives them (or anyone else) the right to use it in non-open source code. Nothing illegal about it, as the license explicitly allows it.

18

True, since they’re not retroactively relicensing, it’s legal, but it’s still relatively immoral.

19

Ya’ll are free to use the previously licensed code if you need “samples of work” (though it likely makes little to no sense since its tightly coupled to Sentry). All of our SDKs will stay openly licensed, and many of our major pieces of tech will as well.

This really only affects you today if you’re running Sentry yourself, and even then shouldn’t affect you.

We’ll keep looking for ways to clarify and evolve how the open source side of things work, but we won’t stop ensuring Sentry’s accessible to all developers.

It is important to note, that while we absolutely appreciate contributions, it’s not very easy or common for them to exist on our server. Nearly all development happens in house (though ^5 to anyone who submits a PR to fix our typos), so this is really about allowing us to protect that investment and ensure we can keep building Sentry for the next decade and beyond.

it’s also important to note that we can and will choose to pull things out of our server/BSL licensed code and move them into open licenses as needed. If there’s components that people feel are actually valuable to the community, we’d love to have those discussions. We’d just rather not build someone else’s competing business for them.

9 Likes
20

I don’t know why you think I am bitter. I see value in open source software, including all of the rights given in the Opens Source Definition. I prefer open source, and require it for many uses. I promote the use of open source, and I have promoted the use of sentry in the past- based in part on the fact that it was open source- and I find it sad that I can no longer recommend it on that basis.

You asked how it impacts me- it impacts me by making it impossible to fork the project if Sentry decides to take it in a direction or fails to support it in an appropriate manner in the future. The BSL only allows a 3 year old version of the software to be forked. This places the community at a disadvantage, and sets sentry as a project dictator that does not have to be benevolent or risk a fork.

Whereas in an open source project, if the maintainers stop being benevolent, the community can fork it- this has happened with several projects in the past- in some cases the split became permanent, resulting in both communities being healthy, in other cases one community ends up thriving, and in other cases, the two sides reconcile their differences. S

With the BSL, the new community would always be at a disadvantage, as no one in the new community could use the product to operate a managed solution.

You mentioned AWS stealing from sentry- I was unaware they had ever doen any such thing- that would obviously be illegal- and should be prosecuted if they attempted to do such a thing!

Yes, I encourage companies to exploit open source, I am perfectly okay with it. I highly encourage the use of open source to make money!

Edit: Just wanted to clarify again, I am not bitter or angry about this- Sentry (appear to be trying to be) honest and is within their rights. I am just saddened by this development, and I wish they could have found an alternative that would protect the open source status of their code.