You made a point that I agree with within the first paragraphs. Thank you for being more clear and I agree with you that now we lose this ability. Sucks.
I don’t understand this part though… If you are encouraging companies to exploit open-source and you are ok with that, how is it illegal for AWS to “steal” an open-source project and claim as theirs, which they can legally do with an Open Source license?
What other solutions are there? I understand Sentry trying to protect themselves – they are pouring money and time into building this amazing cool open-source project and trying to protect their business model by not allowing another company to compete using their code. It’s immoral but happened in the past.
Is this license prohibiting the fork or just the sale of a competing product using a fork of their source code?
Aside, we’re super interested in hearing constructive opinions on how we can clarify things and be good citizens.
We’re already working on fixing some of our marketing material, and we’re talking about building an “Open Source at Sentry” mini-site to help explain what you can and can’t do with our code, where licenses apply, and generally help folks who might be outside of the black/white of the license definitions (e.g. “Can I bill someone who is asking me to help run their Sentry instance?”).
On that note, I find your negative language on “open core” a bit confusing. Aren’t you effectively doing open core in reverse? Sentry now has a restrictively licensed core, with an open source outer shell.
In any case, Sentry’s criticism of open core seems misplaced. Open core licensing of the Sentry main product could just as well mean that only the most business-critical parts of the code would be BSL-licensee, while the rest would remain open source. In other words: an open core approach could result in a more open Sentry. I agree there’s an insignificant cost to figuring out where to draw the line for open core so I’m not trying to say I think you took the wrong path here, I just don’t see any reason to deride open core at all. Different means to the same end.
p.s. I applaud this sort of licensing experimentation as I believe there is ample room for it, especially in middleware. Hopefully this new breed of open licenses won’t proliferate past a handful of options most suitable to the vast majority of projects.
how is it illegal for AWS to “steal” an open-source project and claim as theirs
The “steal” phrase came from your previous comment, I was mirroring your word use- but I probably wasn’t clear that I was using it in a bit of a ironic way. It would be almost impossible for AWS to steal BSD licensed code. Even infringing the copyright would be hard, given the extremely liberal terms. And that is the point I was making. My apologies for not being more clear, that part of my comment probably came off a bit more aggressive than I intended it to be.
What solutions are there?
Well, lets first define the exact nature of the problem. I don’t think that Sentry has done a great job of outlining why they think this move is necessary. Perhaps a follow-up from @zeeg could clarify better what challenges they are actually facing? I don’t know of any major platform provider that is offering Sentry as a Service? Some smaller players seem to have- but it seems like as of a few years ago, Sentry wasn’t too concerned with this. What has changed since Oct 2016? (There's only two things we really consider as protection of our product and bran... | Hacker News)
The Above FAQ mentions Sentry’s size- but as I believe was rightly pointed out by Sentry’s CEO in 2016 (above HN link), their size is a strength and protection to them against competition simply re-using their code to offer a competing service.
From the above FAQ:
Some recent events have shown that there is potential to abuse our hard work through the very permissive BSD license.
But there is no explanation of what these recent events are… it does seem that this is a move based primarily on fear, based on this comment.
Every company is different, and business models need to take into account the unique position of the company, as such, proposing an alternative solution when the problem isn’t clear would not be very productive. (Though arm chair quarterbacking can be a fun and some times useful exercise- it is of little value to the team on the field!)
However, I will point out a few open source businesses that have found models that work well for them:
Gitlab (as @kencjohnson can attest) has taken the popular
“Open Core” approach of releasing a core product as open source and selling hosting as well as additional proprietary “enterprise” features. This model can be dangerous, as companies can be incentivized to cut way back on the features they open source, and even refuse contributions that would compete with their closed source product. Gitlab has done a pretty good job of striking a balance here, and I would recommend anyone considering this approach to look closely at what they have done. However, I still find it to be sub-optimal in general, and I evaluate open core software with an extra bit of caution regarding these issues. I want to see a strong community that won’t put up with any BS from the company (Gitlab has a pretty good community in this regard!)
Sell Services: Redhat has mastered this business model. They contribute massively to open source- they have even bought companies like Ansible and open source thier previously closed source product! (It took them a while to open it, but they finally did it!). Canonical uses this model as well- though perhaps to a slightly lesser extent, s Canonical does have some proprietary software they sell (Landscape), but I still like Canonical a lot. Study these companies and learn from them!
SaaS model: Automatic does this with their popular Wordpress software. They operate a SasS service hosting wordpress sites. I chose Automatic as my example here because the Wordpress ecosystem is so strong and the company does well. There are many third parties offering to host wordpress as a service. But Automatic does just fine as a stand-alone hosting service. This is another great model! It seems to be the model that Sentry had previously used. What went wrong? I don’t know.
Foundation + Many companies and individual contributors providing services and contributions: These are my favorite open source operating models! I find projects backed by strong foundations that have many companies contributing to be the healthiest. Projects like Linux, Python, Django, Firefox, various Apache projects, LibreOffice, Postgres, even Kubernetes! Google even open sourced Kubernetes, donated it to a foundation, and continues to be a large contributor- while offering their own version of the service to customers! This is hard to build, and not every project will be successful in going this route.
Hybrid models: Many of the companies mentioned here actually use some hybrid mix of these models.
Create your own: There is lots of room for innovation in software business models! I really should start a blog so that I can elaborate more on these issues- as it seems like an increasing concern in the open source community. Then I could stop wasting space on other companies websites
We’re a bigger project now than we were in 2016 which puts a bigger target on it for one. However one big reason is that I think people generally would agree that our open source version has been not that much fun to run yourself. This is not something we’re particularly happy with and that’s why we have @BYK working now on proper docker releases to make it easier to run yourself. We want the experience to self host sentry to be an enjoyable one without having to worry that those images are then just offered from third parties at a charge.
I think a core difference is that we’re not really seeing the BSL as a restrictive license. For once it auto upgrades to a truely open source license after a while, secondarily even under the BSL there are very few restrictions on what you can do with it.
With an open core model there is stuff that’s just not there at all and I don’t think that’s in the interest of the community or users. We don’t want to force users into switching to a commercial version to get some locked away features. That has never been our model and we don’t want that to become our model now.
Additionally as David already pointed out we’re more than happy to selectively release parts of the code under the Apache2 license earlier if there is demand for it.
Many of us have a lot of Open Source background and the complex nature of how to make money with Open Source while doing Open Source is not a new problem. This is the best answer we found so far that we’re happy with. If think it puts some specific restrictions on what you want to do with Sentry we would be happy to learn about this and from this.
That’s not an accurate depiction of open core though. There is nothing about the open core model that excludes the use of a license like BSL for the proprietary layer. In fact that is exactly what Cockroach Labs is doing, and they call it open core.
We believe that the path we’ve chosen is how to build an open core company and still maintain a strong open source legacy in this new reality.
That’s not an accurate depiction of open core though. There is nothing about the open core model that excludes the use of a license like BSL for the proprietary layer. In fact that is exactly what Cockroach Labs is doing, and they call it open core.
As far as I remember, CockroachDB is actually open core. The BSL is in addition to that. I don’t have the cycles this morning to look that up, but someone can confirm. Sentry is not open core. We are free, source available, with a conversion to true “open source”.
We’re definitely done debating language here though. People can call it whatever they want for all I care. Our focus is on what you can do with our software, and I think our licensing change will achieve those goals. That’s what’s significant, not subjective definitions of words.
Thank you for your response! I read your accompanying blog post about this announcement, and I am a big fan of many of your projects- thank you!
I agree that making the project difficult to deploy isn’t a smart way to protect against competition! The Hacker News comment from your CEO seems to indicate that size was a strength not a liability. I see this move as being a significant shift in the companies business philosophy and its philosophy on open source as espoused in this 2016 blog post (the one that inspired the hacker news conversation- https://blog.sentry.io/2016/10/24/building-an-open-source-service). I am open to the idea that evolving business climate and lessons learned since that post led to this shift in philosophy- and I would love to hear more about that shift in thinking.
If think it puts some specific restrictions on what you want to do with Sentry we would be happy to learn about this and from this.
I’m glad that you are willing to have this conversation. The thing I want that the BSL can’t provide is the real threat of a fork. This helps ensure benevolence from the BDFL (The 2016 Sentry blog post acknowledges the company plays this role.) The Document Foundation was formed after Oracle acquired Sun Microsystems- and they forked OpenOffice.org and created LibreOffice. LibreOffice is now a much better product. If OpenOffice had a BSL with a 3 year time period before the code became open source, the DOcument Foundation either would have had to fork the three year old codebase, or stuck with the BSL license for at least three years, limiting its members ability to commercialize LibreOffice and support its development.
I am not accusing Sentry of being Oracle! You guys are much better than that. But I am saying that experience has shown that the value of the ability to hard fork the community is tremendous! Other examples include NodeJS, which ultimately resulted in re-unification and new project governance. Also, OpenWRT, which similarly resulted in re-unification.
It sounds like Sentry is open to opening more of their componenets, and I would encourage giving consideration to that. I am not familiar enough with the product architecture to give specific recommendations at this time. But I would encourage consideration to at least enough to have a basic working product that is open source- if not something more substantial. I would also recommend considering a shorter period of time before the BSL reverts to the Open Source license.
While I don’t like this new business model, I recognize Sentry’s rights to pursue it if they feel it is the right choice for them, and they are honest with the community about their new model. I remain willing to consider whatever open source code the company is willing to release, just as I would any other open source code, and I am willing to promote supporting the developers/company in a manner that aligns with the use of their open source code.
It’s very important to remember that not all open source is created equal. Sentry was primarily built by me in the early years, and since then it’s by people that we employ. It’s fairly different than something like Node.js, or many of the open source libraries/frameworks out there. We’ve always thought of it as an open source service. We offered it as open source because we appreciate the knowledge share (we know thats complicated now), but also because without the free bit (which is why we’re anti open core), many companies wouldn’t be able to adopt Sentry at all. That last point is what we mostly care about: helping all software teams.
We’re talking internally about how we can create a small minisite/portal to explain these things, but as part of that also include processes to request license grants (e.g. “can i get a grant to do X” or “can you open source Y”). We’ll also be evaluating how the three year window works, but ultimately we saw that as more of a kill switch. We still don’t want someone forking or running their own Sentry, but we also wanted to protect the future of Sentry if (albeit very unlikely) Sentry the company no longer existed.
We’re going to get that fixed. There’s another number of pages that need updated.
That said, our core intentions are still there in Sentry, and we have a huge amount of free licensed open source that many developers benefit from. If anything we just need to clarify what is open and what isn’t, and how you request changes to that.
THanks for your reply and for your willingness to engage on this topic! I really do wish you guys the best, and I hope I get to collaborate with you in the future on the code that you decide to keep open source!
To me, the primary value of open source is not that it is free as in cost- but the freedom that the Open Source Definition provides. Community is an important part of my evaluation matrix. Not having a strong community of contributors is a weakness from this perspective. I appreciate that your product is different, there is lots of room in the marketplace for different products with different strengths and weaknesses. While I am sad to see you move to this new licensing model, I really do wish the best for you. I look forward to seeing more open source developments from Sentry. I also look forward to new developments within the open source APM market.
No disrespect to the Sentry team, you are welcome to do whatever you want. However, if I were to make an OSI Approved Open Source fork on Sentry, what am I allowed or not allowed to do when referring to the original Sentry project? I wouldn’t want to create any confusion with the company Sentry. Can I say this not yet named project is an open source Sentry fork? Can I link to the open source integrations and claim it to be Sentry compatible?
You are free to do that, there’s a few things (of practical sense) that would matter here:
We hold a trademark on “Sentry”, so you would have limited use of that name
You’d have to fork the BSD-licensed code (which would have been swapped sometime yesterday)
We wouldn’t support it, so you’d be on your own, and could plausibly face community backlash
Your other concerns (can I use other third party code that is licensed differently with it?) should generally be fine. Some licenses aren’t compatible, but I’m not knowledgeable enough on how they all work together (other than GPL is incompatible w/ Apache 2).
Aside these notes are exactly how we prepped for “what if Amazon decided to sell Sentry”, but in that case we would have been much more aggressive (changing the code, deciding if we would have to close source, etc), whereas in this case we’d just feel sad/annoyed.
To be clear, that would be a unintended and very unfortunate side effect. The one and only motivation here would be to create continuity of an open source error tracking platform.
So what about the open source volunteers? So if any open source project self host Sentry they can not give access to their volunteers? Is it possible to explicitly add volunteers/contributors also?
Going forward will patches also be accepted under 3 clause bsd or Apache 2 without the BSL additions?
The elephant in the room is of course the AGPL3, which I assume was considered at some point. Could you provide any sort of guideance as to why you went with BSL instead? A quick skim through the Zerotier post which you referenced had the following passage - does this also hold true of Sentry ?
That’s why we’ve always used licenses that are intentionally problematic for companies that want to “SaaSify” ZeroTier. If it weren’t for the problem of GPL-phobia we’d likely have stayed with the GPL (with a dual licensing model) or even considered the slightly stronger AGPL, but GPL-phobia prompted us to consider other options.
edit: links stripped due to Discourse restrictions
