Re-licensing Sentry

So David, you relicensed Sentry. Sentry is, I guess, what we might consider an old open source project. 2008 I believe was your initial commit to that. I don’t know the full back-story of the company or the project in terms of if you intended to be the company you are today, or the project you are today, so… Take us into the position of the fact that you’ve been around since 2008, and this idea of relicensing and how you had to rethink about it because of various changes to 1) your business and 2) open source software at large.

Yeah, for sure. Like you said, Sentry has been around a long time. When I started the Sentry project it was very much on a whim. When you build open source software, you just open source a lot of things you do; you don’t really think about what they could be, what they are… You’re just like “Yeah, I can do that. I’ll just create a repository and go from there.” So that’s really not only in the origin story of Sentry, but it is to some degree how Sentry was developed for most of its life.

And when we did that - this was 10+ years ago - I was much younger, much more naive…

Eleven, yeah.

Yeah. So you kind of pick a license. And I didn’t have opinions back in the day, other than I sort of knew what GPL was and didn’t like it. I didn’t like the infection of it, and I didn’t like people’s inability to use your software. We weren’t trying to commercialize anything, it was just like utilities, and infrastructure… It’s just like “Well, you pick a license that people can use, that keeps your name and protection intact.” But it’s not about “How do we force a company to do business this way by using our open source software?” That was never our goal. It was just accessibility.

So when we did that, we chose the BSD license, which is super-free, but it was still licensed; it wasn’t just arbitrary. And if I went back, I would not choose the BSD, I would choose Apache… I think Apache and MIT are kind of interchangeable, ignoring the legalities (there’s minor differences). But these days I would go with Apache or MIT from that perspective… But it was what it was.

Fast-forward seven years, we had started a small business out of it. It was very much a hobby business, running it on the side… We didn’t really know what it was gonna be. We thought it might turn into a lifestyle business… But it was going well. And at that time we thought a little bit more about relicensing, getting off of BSD and onto something like Apache, which was a little bit more understood in legal proceedings, had a little bit more protection around it, depending on which direction we went… And that protection stemmed from like “Well, what if we did end up with patents?” or like “We have trademarks, and all these other things. How can we ensure that a legal entity will understand this and take our side in the things where they should.” But it was still a free license, so it still basically had no consequence to anybody running it.

[04:15] We never wanted to go open core. We never wanted to say “You can only use part of our software.” And I mean this in the way of we wanted it to be accessible, not open source. Open source was a great benefit, and we really much believe in the education that open source brings, being able to look at code and understand how it works, and adopt that code… I think that’s hugely important in open source. But open source means I don’t know how many different things… But to many people it just means free software. To a lot of other people it means software where you can go contribute to it. To some people - and I think actually very few - it means software that you can take and copy and use in whatever way you want. I actually don’t think that’s super-common. And that certainly wasn’t common with Sentry.

Most of Sentry has been built by myself early on, and then over time it’s been built by our company, if you look at the contributor graphs… But that’s only one piece of Sentry. We have a ton of libraries that are on different repositories, we have a ton of other projects that are on different repositories, and those are actually under different licensing mechanisms. And we always had that. We had a mismatch of licenses everywhere.

When we finally said “Okay, let’s redo the licensing”, it was mostly triggered, in all honesty, by an annoyance of other companies. We had this hodgepodge of licenses, we had these companies doing things that we didn’t think were right, and so we were like “You know what, now’s the time. Let’s invest in this. Let’s get it done, rip off the Band-Aid… But let’s do it in a way that we think is right.” To some degree, it was just the evolution of the project, the business, kind of all things combined, but still trying to keep our ideals intact.

Right.

I think what we’ve done is we’ve really aimed at like “How can we have something that checks these boxes of what people ultimately care about, but allows you to still commercialize it?” And for us that was accessibility, so to some degree the free version of it more than anything else.

We’ll get into some of the details around this change, specifically the choice of the business source licensing, and that being an option nowadays. MariaDB - we talked to them a while back around that license and what it meant for them, I guess their reasons for it, and they had a large history into MySQL, and all that separation… So they’ve been down that round. You mentioned this change was triggered by other companies… What do you mean by that? How so? What specifically?

We had various behavior over the years, where a company would take a bunch of our code, and that’s fine; it’s annoying, it’s fine. And in some cases, they would take it in a way that felt morally wrong. I’ll give you a real example. If you take one of our SDKs – so we capture errors in a variety of languages, so we built a software development kit to capture those errors, basically, and then submit your application. A lot of people have taken our work there and used it to build their own product or commercial entity on top. We’re accepting of that, if nothing else, because we didn’t do a lot of that work ourselves. That was the open source community building that for us, and we’re not protective of the ability to collect that data in general. It doesn’t matter to us. That’s a universal idea.

On the counter side, we’ve had people take our server code, or our documentation, or our assets; literally, screenshots and all these other things. And that’s very different. Nobody should be building their business off of our business, effectively. I think you see a lot of this concern in other open source projects, where it’s like “We are the team building the product, the software etc. We should be the team that’s able to monetize it.” That’s the ideals behind it, right?

Right. Let’s pause there for a second. That’s kind of what I wanna talk to you about, because that seems to be a big change and a big shift, which seems obvious, it seems logical; if you’re making the software, you wanna be the ones to be able to monetize off of it. That does make sense, and where you’re going with that is pretty interesting.

[07:49] Yeah. So ignoring the internet debate about open source and what all this is, there’s a lot of people with ideals, the really extreme edge cases of the world… And I sort of exclude all of them, because they’re just out there, shouting on the internet, as if they would shout about any random topic. But almost everybody, when we made this license change - and we explained it, and I thought we did a pretty good job of explaining why - they fully supported it. And I think the reason for that is they understand that – it’s like, if you want nice things, they have to be able to financially support themselves; otherwise they go away. And the ideals of open source frankly don’t work.

The idea that – I’m gonna use cURL. I don’t know much about the author of cURL or how the maintainership works, but I do know that there’s kind of this primary individual who’s responsible for cURL for a very long period of time. And it’s great that that person’s been able to do it, but without that person what would happen to that project? Frankly, it’d probably die and get replaced by something else. And sometimes that’s okay… But that’s not really what we want as developers. We wanna be able to use something and trust that it’s gonna exist, and that we can build off of it, right?

Right.

Because open source doesn’t really matter. If it’s constantly us having to plug in new dependencies, and worrying about security and polish and stability of these dependencies, it’s not really better than building it ourselves, which is what most companies end up doing because of that problem. So in my opinion, everyone needs to push for supporting some kind of sustainable models behind all kinds of open source… And those models are gonna be drastically different, depending on the type of project.

Sentry is an infrastructure piece, it’s a SaaS business, it’s a service at the end of the day. It’s very easy for us to monetize a service in the way that we do. It’s very hard to monetize something like the Django web framework in the same way that we do, right?

Right.

So I think everybody needs to be in support of that and needs to be creative in finding ways to achieve that, and we need to find the right compromises along the way to achieve those goals. And to some degree, we just have to be accepting that there will be different versions of compromise to different people, but I think we all need to understand there’s a compromise that we have to make to be moving in that direction.

This license strategy or concern… Is it unique to, say, open source projects – because you mentioned Django and the framework, and not being able to monetize it the same way you can Sentry in a service… Is that unique to a service? Obviously, it is, but is that the only place where projects are rethinking their licenses because of maybe the lack of maturity, maybe the lack of clarity of how licenses would be used or misused, and cripple the teams from being able to monetize that project to sustain?

I definitely don’t think it’s only cloud services. It’s hard to say that MariaDB is a cloud service, right? It’s more of a run-it-yourself infrastructure piece. It’s a commercialized database, right? CockroachDB - same thing; it’s a database. Now, maybe you build a cloud service out of that, but databases are very, very different, because you often wanna run those on your own infrastructure, so it has to be approached differently. And honestly, I genuinely think – now, this is probably hard for individual developers if they’ve never done this, but I spend a lot of time on pricing and packaging, and that’s core to a business.

If you think of an open source project as a business, your license is your packaging, and your pricing is just bundled into that. I don’t think people actually sit down and think about how that works. Like, how are we gonna offer this to our customers in the way that they want it, so 1) that they’re willing to use our software, 2) that they’re willing to buy it, which is sort of accepting the terms of the license, and 3) that we can somehow expand that customer over time. Now, “expand” might not be revenue in an open source project, but it means like adoption, or maturity, or something like that. And I think you can reason about these projects in the same way you can reason about a business… And I honestly think you can reason about most things in the same way you can reason about a business. And maybe that’s my bias lens these days… But that’s how we thought about it.

We said “What do we wanna achieve as a business?”, which is the same as “What do we wanna achieve in our open source project?” For us, it was like “Well, we want every developer to be able to use Sentry”, which is why it’s dirt cheap to get started, it’s why it scales from the tiniest company to the largest companies in the world, and it’s why the open source thing is basically no strings attached, other than you can’t steal our code, effectively. And that was a very important principle for us when deciding it, but that’s not everybody.

[11:55] I think it’s perfectly acceptable to have an open source project that says “You must pay $1,000 to use this at all.” That’s fine, that’s totally acceptable. But what are they doing? Is it worth $1,000? Then charge $1,000.

Right.

Is it a small, tiny, five-line sippet of code? Well, you can’t monetize it; just be honest with yourself. It doesn’t make sense; why would anybody pay for this? And I think that’s where the gap is in open source, where people compare drastically different things to each other.

Help me walk through the thoughts around this change… Because I did a little research and it came back to issue 5698, which is on your Sentry open source repository. The title of it was “Switch license to Apache 2.” That kicked things off. If you look deeper into it, is basically you talking to yourself a little bit, until [unintelligible 00:12:37.18] jumped in there and threw some thoughts in there… Which you sort of described some of your goal, and I think it was kind of interesting how you spelled that out. You said “Our goal is a more universally-understood license, with potential future protections.”

I think you’re kind of touching into this evolution of open source software meets commercial open source software, and the need to protect yourselves. And even later on in your post that sort of talked about these relicense, you mentioned concerns around protection-focused licenses… And you chose business source license.

Yup.

But it also changes after a while, too. You’ve got a time period in there… Can you break down why you chose that license in particular, and maybe some of the parameters around why 36 months of transitions, or changes… Break that down for us.

Yeah. So let me talk you through a little bit about our decision process, and I’ll explain the BSL as well. So at first we just wanted a universal license, and we wanted a license that ticked what I would call the legal checkbox of a company. I worked at Dropbox, and Dropbox is much like big companies - if you wanna use open source, there’s very stringent processes around how that works… And there’s a lot of good reasons for that; if nothing else, because of security. But on the business side you actually can’t use a lot of licenses freely. Take GPL - if GPL were to be embedded in… I forget which projects it was, but maybe it’s the Dropbox desktop client; if GPL were to be embedded in that, they might have to open source the entire Dropbox client, which they’re never gonna do. That’s their business-critical infrastructure, right?

Right.

So that’s why legal teams have a lot of protections. And what they’ll often do, ignoring security review and these kinds of things, is they’ll say “If it’s this license or this license, legal does not have to sign off. But if it’s any of these licenses, legal will probably not sign off. And if it’s anything else, you’re gonna have to make a strong case for it.”

Right. Because they’ve already kind of pre-checked which licenses meet some of their necessary legal criteria, and that’s why you have those parameters.

Yeah. So that was the idea behind a universal license. “We should standardize things that we know fit in a checkbox.” Now, the counter side to that - and I’ll explain what the BSL is - but BSL does not fit in those checkboxes, which is a very big, negative issue of it… And there’s two reasons for that. One, it’s not commonly used yet, and two, it’s parameterized. And because it’s parameterized, it basically means you have to review every single version of it. So it’s basically a custom license at that point.

Okay, and the way BSL works, in the most simplistic fashion - and I’m not an expert on this, but I’m gonna tell you what I know, so… Big caveat.

Is there any expert really on licensing? Maybe aside from Heather Meeker. Maybe she’s pretty much an expert at it these days.

Yeah. I think there are some, but they’re usually biased towards one set of versions of licenses.

Right.

And lawyers like to be lawyers, and add a lot of language all over the place, and I think that’s what a lot of licenses are… Okay, so the BSL - when we started down this process, we said “Universal license - it’s known, Apache 2.” We really like Apache 2. We like MIT, but we sided with Apache 2 because of patents protections, even though we have no patents. Again, future-proofing, thinking through that. So that was one aspect. And then we’re like “Okay, we have all these other concerns… We wanna prevent an Amazon situation in the future, which we’re not super-worried about, even though the news likes to say these things… But it is still a very real business risk. And as we are a significant business at this point, we have to evaluate those concerns.”

Meaning that Amazon would use Sentry…

They would sell Sentry.

Okay, gotcha.

[15:53] So we don’t want Amazon or Google or Microsoft selling Sentry without our consent. We don’t want them profiting and not contributing back to the fundamental R&D investment that goes into Sentry. That’s the only goal, and I think everybody can get behind that goal. So that’s a version of protection.

We also don’t want these VC-funded startups plagiarizing our work; taking our code, our assets, and then building their business off of it, when again, they’re not contributing back to the core of it. They weren’t here for the 11 years of building it, right?

Yeah. And even in many cases what you’re doing there too is not just protecting your business, you’re also protecting all the contributors who have joined the Sentry fight, the CockroachDB fight, whatever it might be, to solve a problem. You’re also not just protecting your business, which is great, but you’re protecting the asset that everyone’s worked so hard to make a solution to a problem.

Yeah, and I actually would go farther than that, take away the contributors… We are protecting the ability for somebody to have great software for free, in our case. We say “Sentry is free. It’s a version of open source; describe that how you will, but Sentry is available to everybody at a price point that is reasonable for everybody…” And by us being able to continue to fund that, we ensure that future. If somebody else comes along, uses our code - well, one, they’re never using it in an open source way, and they’re certainly not contributing back, so it doesn’t actually ensure that future. And I think that’s the most important thing you can take - if you want things to be sustainable, if you want something to be long-lasting, then it has to have financial backing of some sorts. And that’s the guarantee we created out of this. But that’s a business protection at the end of the day, right?

So going back to the BSL… What we said is we want those things - we want those protections, we want a license that can be universalized, and the biggest thing was we didn’t want GPL, we didn’t wanna have two versions of Sentry where we create an open core model… We didn’t like those models of open source, ignoring the headaches that go behind it. And it’s also important to know that not all of Sentry is open source. We don’t open source any of our infrastructure. It’s all closed source. It’s how we run our servers, how we run on top of the cloud… That’s all proprietary, and we won’t ever open source that. It just doesn’t make sense, in all honesty. But the service is the exact same service that powers our entire business, it was free open source, and now it will eventually be free open source. So that’s where the BSL comes in.

What I really liked about the BSL was it allowed us to check all the boxes, first off. It said “We could protect our business, we could still let basically anybody use it for free, and it opens up a lot of flexible possibilities around that.” And the one caveat was it meant you couldn’t take Sentry code and use it in a different way, for good and bad. So if we came up with a really clever way to solve a problem, I would like to be able to share that with the world, because there’s no reason for us to reinvent the wheel all the time.

Now, legally speaking, you can take that chunk of Sentry and use it somewhere else. That’s what the BSL prevents, which we don’t love. Now, our compromise was twofold; one, the BSL is a time-based license, with a maximum time period of four years. That means that when the license is stamped - which it has to be stamped… So say it’s stamped January 1st (we’ll say) 2020, a maximum of four years from that date it must convert to a more open source license. Those are the requirements of it. But that four years is flexible, so we chose three years. And we chose three years – to some degree it’s a little arbitrary. We chose it in the same way that I think - and I won’t speak for them - Cockroach chose it. I talked with them and I like their reasoning. Three years is enough time that it protects us, because we think in three years that version of Sentry will be so outdated that it doesn’t matter from a business risk point of view, and it’s not too long where we feel like it’s just completely useless.

Now, maybe two years would be better… I also don’t know if there’s a minimum time. I don’t know if you could say every month, or every day even… But our thinking was like two or three years felt good, and we might change this in the future. We might go to two years. That’s a nice flexibility. But after that basically for us – and this is something you can choose, again… We said “After that time period it converts to Apache 2.” And that’s pretty nice… And that’s nice because it allows us to solve that eventually you can use this code in any way you want, which means you can learn from it, you can reuse modules, components etc. But unrelated to legal side, we made the commitment internally - and we’ve even committed this externally - if there’s something that makes sense for the wider community, petition us and we’ll open source it in a free license. We can do that. And we can also grant one-off licenses for things.

[20:22] So to me it was the right set of compromises that still allowed us to eventually achieve those goals… But it’s not technically open source anymore, even though a lot of the components resemble open source.

Gotcha. Can you help me understand more so the stamping and the timeframe? Are you stamping the entire repository and new commits? Basically, are you stamping the whole entire repository of the project January 2020, and then three years later - because that’s the choice you made, to choose three years versus four years - it becomes converted to Apache 2… Is that how it works, or is it per commit? What do you mean by that?

It’s a little tricky. This is a legal grey area. Our solution to this is – so one, we were advised that the timestamp needs to be in the repository, with the files, even though it could be in a different file, and all these other things. So we were advised that… Which then means - say we stamp this on January 1st; say we don’t change the date come July 1st. That three-year time window is still the same time window, even though now it’s 2,5 years, right? So you’re just giving it an explicit window of time there. So our solution - I think, and I’m not in charge of this; somebody that’s doing the open source stuff at Sentry is running this, but… I believe what we’re doing is every single month, pretty much automatically, we’re gonna refresh the timestamp. So you’ll basically have between two years and 11 months to three years where something becomes open source… And it’s basically like the state of the repository at any given SHA is how it works. So if you check out a SHA, the license is bundled in that SHA - that’s when that becomes Apache 2.

Okay.

Does that make sense? Did I describe that one enough?

It’s almost like releases.

Yeah, that’s the best way to think about it.

You’re essentially [unintelligible 00:21:58.01] and is departed, divorced from any future work, that release - I don’t even know what version you’re at; let’s just say 2.2.2, for whatever crazy reason… That version will eventually become Apache 2 based on the parameters that are unique to the BSL license. Because you can define those, and say “After a certain point in time, this codebase converts to Apache 2 and has the affordances of that license.”

Yeah, exactly. So, two things. One, it’s easiest to think about it as releases, because that’s how any reasonable company would go about this. It’s N years from this timestamp of that release, and that’s written in stone. It’s more complex when you think about it from the version control point of view, right? And then the other big thing to think about is there’s only effectively three parameters in the BSL. There is what does the license convert to, with the restriction that it must be more open source… And it might actually have to reflect in OSI-approved license, but I’m not 100% sure on that. But it has to be more open source, more free. The time period is a parameter; a maximum of four years, but your choice… And the license clause - I forget what it’s called; the use clause. That’s where most people would have the most opinion.

So that is gonna be very specific to a business, and that’s the problem, because that’s where legal comes in. The other two sides are very easy to reason about, but once that use clause comes in, it’s a completely custom, proprietary license… So ours, in laymen’s terms, is like “You cannot operate application monitoring SaaS service. Or you cannot commercialize a SaaS service that sells application monitoring. So technically, you could give it away for free, completely free, and not breach our license at all. But as long as you don’t charge for it, you’re good.

That’s very different than MariaDB’s, which is – I think this is what it is, but please don’t hold me to this… I think it’s like that you are able to use it on one core, one CPU, or something like that. It’s got a very different kind of restriction. And then CockroachDB is a little bit similar to us. It’s basically like “You cannot use this license if you are operating a commercial database as a service kind of platform”, which very much covers Amazon and the big cloud providers for them.

Obviously, when you’re building a business, there’s some inherent fear that will creep into any business. Every business has competition, so one big part of surviving a business is winning over competition. But then you also have this flipside of like – in your shoes, or others’ shoes that are producing open source software and building a business around it is if the big dogs come around and begin to take your software… As it should, based on licensing, totally free to do that, but then essentially stomp on your yard and do things that sort of upset you in terms of your business; upset your business.

And I guess one thing I have a curiosity about is this fear of how that manifested inside your business. What were meetings you had with, what were some scenarios people brought up around this inherent fear of – not just winning a business, but then competitors using your stuff in ways that don’t sustain or don’t build upon what you’re trying to do.

Yeah, so I think there’s a little bit of an interesting back-story. Sentry is very much a venture capital-funded company at this point. We’ve raised something like 67 million dollars, which is pretty significant. The first time we raised money - our seed round, a long, long time ago, which was very small in comparison, a lot of people asked “Why would people pay for this? It’s open source.” Fair question. Nobody asks that anymore; people pay for this stuff, it’s fine.

Yeah.

The next time we fundraised, which was our series A, that question didn’t come up anymore, because we had proven them that there was no fear. And also, for what it’s worth, when they were asking why people would pay, we had revenue, and it was fine. But the next time around, the question was very different; it was “What stops Amazon from running this? Hosting this themselves and selling it? If you can make money here, why would Amazon or any of the big companies - why would they not capitalize on that? …as they’ve shown themselves to do in many ways.” And my response was “It’s not happening today. We’ll figure it out. I’m not worried about that.” I said that with conviction, and I believed in it because Sentry is a product, not an infrastructure piece. So it’s a little bit different than what their status quo is.

[unintelligible 00:27:15.29] I don’t know that much about how Elastic worked internally, and all these other things, but Amazon sells Elasticsearch, right? Elastic sells Elasticsearch. There’s competition there. But Elastic is just an infrastructure tool. It’s basically a database. That’s the way I’d reason about anything; it’s a database, or a web server, or something like that… And that’s what the cloud providers ultimately sell. Because a product is very different. You have to constantly build and change and evolve the product… And our bet was that Amazon isn’t gonna invest in that, because it’s a high-risk move. They could have chosen to try to run the open source thing and assumed that we would invest in it, but we just didn’t think that would happen. So we took that risk and we accepted it, as did our investors and everybody else.

[27:55] That question didn’t come up in the future after that, for what it’s worth. Nobody was concerned going forward. But we did always think about it, and we had many, many conversations, kind of just like riffing… Like “Well, what would we do if tomorrow Amazon’s like “Well, we’re selling Sentry.” And for many people, that’s a much scarier idea than us. I think we’re a little bit – I’m gonna call it confident; probably arrogant… But we’re very confident in our ability to win and execute in our space, and I think we’ve shown that really well, where we’re the market leader, and we’ve had a lot of stiff competition for many years.

So when we talked about this, other than like “Oh yeah, we’re confident we’ll win against Amazon”, our confidence was a little shaken… And the way we thought about it was like “Okay, what would we do if Amazon did this tomorrow? What would be our recourse?” And the idealistic approach is that the community would come to your calling and they would battle and rebel against Amazon, and even if that happened, it wouldn’t matter. Amazon would still just completely demolish anything, and it just wouldn’t matter. It’s like one of the biggest businesses in history at this point, right?

Yeah, it’s a behemoth. I mean, it even dwarfs behemoths. It’s just enormous. There is no word, really, to describe how big it is.

AWS alone is so unbelievably successful. Like, unheard-of success, right?

Yeah. I mean, it’s four times bigger than its next competitor.

Yeah. And those are all bigger than any other real IT provider had ever been before. So you can be idealistic about that, but you don’t run a business based on you patting yourself on the back, pretending everything is gonna be okay. You have to say “I have to think about these risks and think about how I would actually address them, and mitigate them with the utmost control.” You don’t wanna make weak bets, right?

Right. Ignorance is not bliss in this case.

Yeah. So okay, maybe the community would rebel, and they would keep using Sentry, but the enterprises don’t care, at the end of the day. And that’s where a lot of the revenue comes from long-term. So we said “We can’t just rely on that, even though we have a lot of faith in the community…” Because we’re idealistic in two ways. We believe that there’s a moral high ground with the way we’ve approached business and things. We think we’ve done it in a way that people will defend, and we actually see that, even with the license change.

And then two, we think we are just so much better at what we do with our product than somebody else could be with our product. So we thought we could still remain competitive enough, but it would be risky… So then we asked ourselves “What else could we do? What other kind of protections could we have, besides relicensing?” And we were like “Okay, if Amazon did it tomorrow, we’d have PR stuff”, which probably wouldn’t save us. Then it’s like “Well, would we have to go closed source? Would we push really hard to make this not run on AWS?” Because we don’t even use AWS ourselves. We can make that really, really tricky. But then they could just fork it, or patch it, or whatever, so it’s not really sustainable…

Right.

We talked about – literally, there were conversations of like “What if we put a bunch of if statements in the code, that’s like ‘if amazon, crash’, literally.” Like, good luck. Every release, there’s a bunch of randomly-generated problems in there for you to deal with… Which is also not sustainable. They’re very smart, they have a lot of money, they can solve those problems.

And honestly, every time we talked about it, we were like, the only way we’d be able to fend them off is with – we have some trademark protections, but that doesn’t do much; they could just rename it. It’s not a big deal. We’d be able to fend them off with licensing, which we’ve now done, or by going closed source, which is basically licensing, right? And all of that sounded awful, realistically. And this was before we knew about the BSL, or this even kind of license scheme… So we’re just like “You know what - we take the risk for now. We don’t worry about it unless it actually happens.” And that’s a big methodology that we’ve focused on.

This focus, like - think about things, reason about them, be willing to address them, but don’t spend time unless you have to.” And we were confident that we wouldn’t have to spend this time. And we never have. Amazon, Google and Microsoft, to the best of my knowledge, have never tried to run Sentry and sell it, or commercialize it, and to the best of my knowledge they’re not trying to do it today… But there are other companies that tried to.

We had somebody pop up in China one time that was literally ripping off everything. Our marketing website - which was probably closed source at the time… So that’s actually infringement, right? And our product, and everything… This was when Sentry’s domain was GitSentry.com, and I think their domain was something like GitSentry.cn.

[32:10] Oh, boy… Yes.

So yeah… We didn’t care, whatever. Like, that’s not gonna threaten us. But then we had startups using our software, which it’s hard to confirm if they’re violating licenses when they do it, because it’s closed source… We’re obviously a small company, we’re not gonna go legally after a lot of these businesses. We’ve had bigger companies than us try to commercialize our software. Again, we take the same approach that we took with Amazon, where it’s like “Good luck. You’re gonna fail.” But again, that’s not a good way to think about business, “Good luck, the other person will probably fail.” And so ultimately, when we did the license change, to some of this it’s like a weight off of our shoulders. You can go take Sentry from a month ago and it’s the old license, right? So you could still run that. You could fork that, you can do whatever you want.

Yeah, it’s almost rewinding it a month.

Yeah.

You have the same affordances you had before, with the other license.

But when you think about that – Sentry’s really complex. We have a team of probably 60 across engineering, product and design, building Sentry, every day. So you can fork our month-old code, but you’re not gonna be able to keep up, and frankly, it’s probably filled with bugs. If we’re honest with ourselves, everything’s filled with bugs…

[laughs]

And that’s acceptable from our point of view, because we’re constantly tackling them, creating new bugs, fixing new bugs… But it doesn’t really work when you branch off. So that whole thing breaks. And we’ve always made a bet that that’s why this is safe now. If you are a company that wants to sell Sentry, you ask yourself the same question from a business risk point of view - I’m gonna invest a bunch of time and money into this, probably, and am I gonna get a return on it? That’s our calculated risk. Before, we didn’t think AWS would make that calculated risk. We thought they would come to the same conclusion as us. And now we especially don’t think anybody will take that risk… Because it’s just so hard to do.

For me, when we did the license change - huge weight off my shoulders. I’m like “Okay, I feel good about this. We’re protected.” Even if we never had to enforce this, now at least if you’re a small startup and you try to rip us off, we can just DMCA you, done. Problem solved. Never have to think about it again.

Yeah.

So we feel good from that point of view. And again, it’s not like it caused harm to our business, it just doesn’t feel good. It feels like somebody’s stealing from you. And I actually honestly believe the emotional hit a lot of these times is worse than any financial hit. The emotional hit that you see of your peers or your employees, or the community getting aggravated by something is just – it’s awful. And you saw this with Node.js, that huge emotional hit that they had when that company took sort of ownership – and again, I’m not an expert there either… But it took ownership, sort of, of Node.js, and they were like “Oh, let’s fork this. We hate this. We’re so mad.” And that’s the same thing internally when we see somebody rip off our stuff; it’s like this big, internal drama that just wastes everybody’s time. We’re all really angry.

We’re also ultra-competitive at Sentry, where the only rule at Sentry is we have to be the market leader. We have to be the best at what we do. So when somebody steals our work or tries to rip it off, we’re very aggravated, because we’ve put so much effort and pride into the output of what we have, right?

Yeah. Yeah, I could tell that about you. I guess a side note for those listening, there’s a whole separate interview with David on Founder’s Talk, my other podcast, where we talk at length about – I can’t recall what we talked about, honestly; it was a lot of fun stuff, and it was about the background of where you come from… A lot about your personal history even… So if you’re curious about David’s background, you can kind of see why he’s so passionate, and in some cases defensive towards his hard work. That totally makes sense. You mentioned that you’re venture-backed, so I guess coming out of that meeting, one of the questions you had was “What if Amazon or someone else started to sell your product?” The question was that, and the solution was “Well, let’s get some licensing that protects you.” So now you have that protection, you can move forward… But one thing that we talked to Adam Jacob about – are you familiar with Adam Jacob, by any chance?

The name does not ring a bell, but…

[36:05] Co-founder of Chef…

Okay, yeah.

I wasn’t sure if you knew him or not… But we had him on the Changelog a little while back, and we were talking to him about the soul of open source; he was giving a keynote at OSCON, which I believe is on YouTube. I’ll have to look up the link and share that with you and others if we can find it… But he was essentially talking about business and competition, and a lot of the stuff you were just talking about. These natural, totally-make-sense fears that you might have as a commercial open source software business, doing what you’re doing. But his rationale was that if we look at all things as a funnel, the fact that Amazon could sell Sentry is just a bigger distribution channel for your brand name. It’s almost free marketing for you, even though they’re selling Sentry…

So I wanna hear what you think about this. And I might be paraphrasing some of his response, so please go back to this podcast and listen to his exact words… But paraphrasing it is essentially if Amazon did sell Sentry, even if they were profiting from it, that would be marketing the Sentry brand, the Sentry business, and at that point you could at least compete with them at the bottom of the funnel, which is the actual service, and give better value-adds for delivering Sentry as a service like you do now. What do you think about his rationale of being okay with letting them sell it because it’s just good marketing for you?

I understand where he’s coming from, but you would only come to that conclusion in the open source environment – like, if you’re Microsoft and people are giving away Windows, or selling Windows, and they’re not giving you a cut, you’re not gonna be like “That’s great marketing for us.” You’re much more like “Why would we be okay with this?” It’s not that I would disagree that it is a funnel, but it doesn’t mean you’re gonna ever monetize that funnel. Honestly, it’s called a funnel for a very specific reason - because the top is very big and the bottom is very small. And if you’re like “Well, Amazon is gonna grow the top of the funnel by a lot, how much of that money is gonna go to you versus Amazon?” That’s the truth.

Elastic – again, I’ve never worked at Elastic, but Elastic’s been very successful, right? How much more successful could they have been if they did not have this ongoing competition or dilemma with Amazon? Like, could they have done so much more? I think they could have. Ignore the business, ignore profit, and stuff like this; think about R&D investment. I truly believe it’s your responsibility as a successful business to continue to invest and innovate. Look at what Microsoft is able to do for the world right now… Whether you like Microsoft or not, it doesn’t matter. VS Code is great software. Microsoft builds that, gives it to all of us for free. And sure, it benefits them; call it marketing, call it whatever, but they do a lot of stuff that impacts us. It’s them investing in R&D.

How much does another company selling your software continue to invest in that R&D? If Elastic had – I don’t know how much Amazon makes (I don’t even know if it’s public) off of Elastic, but let’s just say Amazon makes probably at least as much off of Elasticsearch as Elastic themselves do. So let’s just say Elastic overnight had doubled their revenue. Could they take their products and their technology in that R&D and amplify it much more significantly than two different people building – especially now, there’s two different versions of Elasticsearch, right?

Yeah.

That’s where I think the problem comes in. It’s like, “Great, there’s this [unintelligible 00:39:31.16]|”

Diversified effort, you mean. Forked effort.

Yeah. So there’s something on Hacker News – take it for what you will; I really enjoyed about 50% of the conversation around Sentry relicensing, because it was good discussion. It wasn’t just trolls being trolls. And one interesting – I don’t know who it was or how much of it was, but there was something I remember from it where somebody mentioned “Well, forking creates competition, and competition is good.” And somebody countered that, and I agreed with this person countering it - that that’s not actually what it is. It’s not creating competition, thus creating the natural competition where people evolve their products in different and better ways, and it creates a lot of good growth. It just creates a copycat that looks almost the same, and it creates decision paralysis, and it wastes money and effort of the collective world. I truly agree with that person and that idea.

[40:23] Forking a project and keeping it almost the same, with the same goals, is not valuable to anybody. It just makes everything worse. It compounds every problem. You now have two products that are almost identical, probably equally defective. Maybe one has a nice feature and the other one has a different nice feature… It’s not good. If everything was great in the world, and there was no money or anything involved, we’d all as much as possible take our resources, funnel as many of them that are trying to solve the same problem into one group… Right? You don’t want two people solving the same problem in the exact same way; you want two people solving it in a different way. That’s innovation and that’s competition; that’s what it needs to be… And you don’t get that off of forking projects, or what we see often in some of these competitive businesses.

And in all honesty, in many cases this just comes down to just trying to circumvent your ability to do that innovation, for whatever reason. If you and your team have worked so hard to create Sentry - whether as a service and commercial open source company or not, you created the software; if the intent is to simply take this free thing because of the affordances of open source licensing, and sell it for profit with no give-back - while that may be legal, is it moral? You’re kind of dancing on ethical moral grounds.

While it may be possible, and that’s how it’s supposed to work for some way, shape or form, but I think as businesses build their businesses over and on top of their open source software, you have to really do what you’ve done which is rethink how you license the software. How can you enable your team to keep building great stuff… Not so much how can you limit other people from competing with you, but essentially stealing your ability to build it better, because of this diversified interests, and this diversified solution-solving, how you’re building different products in the same exact way. Progress is not happening because of that; they’re just circumventing it.

Yeah. So what I think is interesting is you could defend GPL in this regard, right? So you build a product, build a database, somebody forks that database, they’re forced to open source all their changes, right? You might think that’s good. So it’s “Oh yeah, all the changes are back in open source.” They’re not forced to contribute to the original project. So that argument is immediately blown up, right? Now, I think the only solution - and again, not an expert here… I think the solution when you’ve got a community-driven project is effectively these foundations. Kubernetes is doing extremely well from an adoption point of view. Everybody is building on top of it. And from a contribution point of view. And I think one of the reasons it’s doing really well is because there’s a collective group that’s taken ownership of it that is – to some degree, that is the business behind it now. It’s that collective group. So they’re gonna - ideally; not all the time, it doesn’t have to work this way… But ideally, they’re gonna push the needs of everyone combined and forward that project, versus forward duplicates of that project. There’s no reason that you would wanna fork Kubernetes. Maybe there’s some technical reason, but it’s never gonna go anywhere. But if Kubernetes was only owned by Google, well then Amazon is gonna create its own, probably from a fork, Microsoft is gonna create its own, probably from a fork… And none of them care about doing that, because that doesn’t benefit any of them. They want a universal solution.

And I actually think that mechanism, for those kinds of projects, actually works really well, especially when you can get big companies on board with funding it… And that’s what Kubernetes has been able to achieve, because it’s also funding the cloud provider infrastructure spend. Now, I don’t know if that scales to a lot of these other companies. I don’t know how well for example Rails or Django does from a financial point of view, like how sustainable are they… But to some degree if they’re not, and they follow the same model, then you have to ask yourself “Should there be something else that comes in?” If they’re not sustainable, is it because they’re not – I don’t wanna call it commercializing, but not bringing in revenue to sustain their employees… Because they do have employees, right? Or whatever it is… Versus “Is the technology not valued enough to be sustainable?”

[44:24] I think that’s an interesting conversation piece that you see with a lot of open source, where we often talk about “Well, how can I fund my little library?” This is probably really popular in the Node.js world, where there’s infinite libraries… But again, going back to, like, you’ve got five lines of code; nobody cares. Anybody can write those five lines of code. It’s not intended to be sustainable, because it’s not providing enough value. And I think that’s an interesting conversation that often gets left out of like “How should this open source then be approached?”

But sorry, taking away the rant, going back full circle, I do wonder, if you look back on some of this tech – I don’t mean to keep picking Elastic; it’s a recent example… If Elastic had built this foundation and tried to give up a little bit of that control, could they have retained full commercialization? Hm, probably not… So maybe it wouldn’t have changed anything for them. But at least for the Elastic project it probably would be a little bit more universal, which I think would have benefitted the whole of the community in that case.

Do you mean if Elastic took a play out of the playbook of Kubernetes…

Yeah.

…in the fact that the Cloud Native Computing Foundation was formed, and sort of invited a community and created a community (for a lack of better terms, or for exact terms) around cloud-native. They coined the phrase, everybody bought into it, every cloud provider wanted to be a part of it, and they created a thriving ecosystem. And rather than having to do what they’re doing with Kubernetes – it’s licensed Apache 2, which is essentially what you convert to after 36 months, right?

Yeah.

…so that’s three years… They’re already at Apache 2; they don’t need to go to a BSL and have that, because the community is already ethically and morally bought into the fact that no one’s gonna do this, because it doesn’t make any sense. We’re all driving towards this direction… But Elastic probably can’t do that with a database quite that way. They might be able to do that, but they won’t have the inertia… It’s not low-level infrastructure the way Kubernetes is. Kubernetes is like the glue that ties all cloud-native together. It’s the underlying thing for which everyone believes in, builds upon, commits to, invests in, and they operate around sort of a known ethical standpoint that “We’re not gonna try and change this in any way, shape or form.” Because they could fork an Apache 2 license and do what you’ve just said, but that just wouldn’t make any sense.

Yeah. This is where I think it’s interesting… Yeah, I don’t think Elastic could achieve this, but I don’t think it’s because of the type of technology Elastic is, like that it’s higher-level…

Okay.

I think it’s because the business would not be able to commercialize itself in the way it has been. Or I don’t think it would succeed in the way it has without more ownership of Elastic. And I don’t know if that’s good or bad. But what I will say is Kubernetes allows us collectively as a group to move forward.

It’s a unifier.

Yeah. When you have a siloed project – and this is not Sentry. Sentry is not a technology for people; it’s not infrastructure, so it’s different. But when you do have something that is more siloed, it doesn’t really move forward. And I wonder… Again, not an expert, but if you go back to .NET, or Microsoft languages, C#, Visual Basic - they’ve stuck around forever, but they weren’t very open, and adoption did not seem to really go anywhere. .NET is used a lot more today than it was in the past. Not in the sense of just by volume. Obviously, there’s a lot more developers, there’s a lot more software companies, so it’s used more… But it’s used in a lot more different ways, and I think that’s because it’s more open now. And I think that’s really interesting, because – you know, you could go to your funnel conversation; by them creating a more open environment and open platform, they’ve widened their funnel to adoption. The difference is they’re not necessarily monetizing .NET, so it doesn’t matter. It’s more marketing than it is anything else for larger Microsoft plays, or larger community plays. But yeah, I don’t know.

[48:15] It’s just an interesting thought exercise, of how you can approach these different businesses, these open source projects, and where are the – draw like a matrix or a bunch of Venn diagrams, like “Where can you learn from that could be applied in different ways?” vs. “Where are models that only work in a specific way?” I honestly think – at least our version of the BSL works very well for a SaaS service. Does it actually work well for something like Kubernetes? Probably not… I don’t know why – it just doesn’t make sense to me. So I kind of wonder, what are those different classifications of these projects or businesses, and how could you approach the problem of sustainability differently? …which usually sustainability just means money, to most people.

This is always a conversation now, and I think there’s a lot of cool stuff going on in the world around it, but I think it is a good time to keep thinking about that and to make some changes.

I love what GitHub has done for the Sponsor stuff. I was never doing Patreon or any of these other sites. We did a little bit as a business [unintelligible 00:49:18.24] probably too much money now. I’m sure I’m giving like $100/month at least, which adds up… And I’m just like “I don’t know, this is accessible. It’s good.” And I actually think that’s gonna be really good for a lot of these smaller projects, it’s just that platform alone… And I think we need more of that kind of evolution in the industry.

David, let’s talk specifically about how you got involved with the BSL license. Where did you first hear about it, what were the use cases that other businesses like yours may have used to protect themselves against the things you’ve already talked about… Take us into how you learned about it and what influenced you to think “Okay, this can solve our problems.”

Yeah, I think the first time I heard about it was when I read Cockroach Labs, their post for CockroachDB, when they had made the change. I don’t remember the timeline, I don’t know if that was earlier this year or late last year… It wasn’t too far back in history.

The post was June 4th, 2019, so it was earlier this year. Summertime.

Yeah. Very fresh in mind then.

Yeah.

And I think coincidentally around that same time was one of these cases where we had seen another startup plagiarizing our work, so we were emotional; we were like “Oh, I wish we could just do something about this.” And I didn’t ever think about the idea of a standardized license that had protections like this that wasn’t a GPL-style license, that wasn’t one of these known quantity things. So that was the first time I was made aware of even this entire version of a license could exist, that people might know about or might understand… So it’s somewhat standardized.

I didn’t read too much into it at the time. It was just kind of like “Make a mental note of this. This is really interesting.” And then when we had started talking more realistically about “Maybe we should just do the license change” and then “Should we actually evaluate other licenses if we’re gonna do the license change?” I chatted with the Cockroach folks and tried to get their take on why the BSL, why their choices with it… And to the best of my ability, I would say it was one-to-one with our goals. It really resonated with me, and the conversation, the reasons they had made the decision, which helped me a lot with my framing and thought process of why that actually might be the right decision for us as well… Because one of the biggest fears of any kind of closed source license - and we’ll talk about open core in a second, but… Open core is a closed source license, to some degree… But what happens if Sentry fails? I don’t think we will, but what happens if it does? I want Sentry to be able to live on in some way… If nothing else, for the knowledge that we “discovered” - or I don’t know how you wanna phrase that, but like, our learnings I want to be able to stick around. And if it’s closed source, they can’t really stick around.

It’s a really good example of like – I don’t know how patent technology and IP and everything works, but take a game from the ‘90s, like a video game. I don’t know when Doom came out; that’s gotta be earlier than that… But take Doom.

Mid-nineties, or early nineties… I could be wrong.

Yeah, so correct me – I don’t know if you know either, but I think Doom might have been open source, or something along those lines. There was some old-style, really innovative idea at the time, that the software, the technology behind it became open and free for people to learn from and to draw inspiration from. And that is a really important idea to me. That was one of – like accessibility is a big thing about open source; it’s huge. And then the ability to take that knowledge is the other big thing for me. Those are the only two reasons I care about open source. I don’t care about the contributor graph, I don’t care about everybody can – like, I hate the idea of pull requests accepted. Like, I don’t need you to do my work for me. If I find a bug in your software and you wanna fix it, that’s great; if you don’t, that’s great. I don’t care.

Ha-ha!

[55:48] If I care about it, I’ll fix it myself. I’ll contribute back when it matters to me… But I care about that knowledge share, and you lose that with a closed source license, or closed source in general. And the BSL doesn’t lose that, and it’s such a big deal. Because it does convert. And that component is when we said “We could do this. We would be willing to use a license like this because of that component.” Otherwise, I think we would have just stuck it out and gone fully open source, and just prayed. Again, not a good business strategy, but… If you want your business to survive, you don’t just roll the dice.

But it was interesting, because one of the things that came out of this was like “Oh, they’re a VC-funded company and that’s why they did this”, and our board was literally like “I feel like open source is fine. It doesn’t matter.” And I’m like “You have no idea how annoying these people are though.” That was my conversation with them. I’m like “I don’t wanna ever deal with another one of this…”, and I won’t name the companies. But it came up like once every three months, and I’m just like “I’m so emotionally drained from this that I never wanna be distracted by it again.”

I talked to a bunch of people how they’ve had to deal with IP infringement… Because again, we had trademarks, right? And those protect a little bit of stuff… And they were always just really sad, frustrating stories. Even when people had full protection, it was like – you felt bad for what they had to go through to enforce that protection, either way, right?

Yeah.

So the board was supportive. They were like “Do what you think is right” [unintelligible 00:57:06.16] The reason we made the license change was 100% that the early team was like “We think this is the right way to protect ourselves going forward.” But we did think about open core, and GPL, and all these other things at the same time… And I know that’s interesting to people, but I think GPL can be okay. I don’t like it because I think too many people default to GPL when it is not valuable for them at all. Like, I don’t need your random library to be GPL-ed. It’s not valuable to me. I will just not use your code if it is.

We even as a small company who has no fears of GPL - for the most part - don’t really tolerate GPL internally, because it is a much more like “I’m gonna put my forceful opinion on how you use my software on you. If you wanna use this in this specific way, then you must do X”, which… Is that really that much different than a proprietary license? To me it’s not. And now you can argue it is, in different ways, but that’s my personal opinion, is that it’s still forcing things.

I can agree with that. They’re kind of a gatekeeper to what it can do, in a sense.

Yeah.

You must get approval, essentially.

Yeah. So you have GPL, which is one whole thing… And you could debate about that, and I’m fine with GPL, I just personally don’t choose it for projects. But as a company – it’s not so much my personal thing; we think about it holistically. But that’s very different than open core. Open core is often also GPL; I’m sure there’s a reason for it, but… And I’m by no means an expert on open core, but when I think about open core - this is very emotional and sentimental - I think about software that has a (best-case) mediocre free version. It’s like “Yeah, I can kind of use this, but it sucks. I really don’t wanna use this software. I wish I could use the version that the starting price is $100,000/year.” That’s open core for me in a nutshell.

[laughs]

Free bad version, ridiculously high-priced paid version, because they have no other way to monetize. Sentry is like free great version, low-priced great version, scale is the high-priced great version. That’s what it should be. It’s kind of like you expect with open core that there’s arbitrary paywall made for the enterprises, which is what it is, because the enterprises can often pay more… But you often end up in this dilemma of like “Well, what features am I gonna put where?” and the only way you make it work is by putting any kind of valuable feature into the version that you’re charging for at the end of the day.

So that to me is just a personal thing… I don’t like that model. I don’t think it’s a good model in general, and we never wanted to have that model. We never wanted to have two versions of Sentry - one that was bad, and one that was good - because we’ll always be conflicted. We’ll be like “Well, people really value this feature. Can we give it away for free, or should we give it away for free, or do we need that to be the decision point of ’Will you pay?”

And then on the other side, Sentry’s entire business - 100% of our revenue - is SaaS. We don’t sell anything else. We refuse to actually sell on-premise software. So even though you can run Sentry yourself, you cannot pay us money to help you run it, in any way, shape or form. And because of that, it also makes no sense to do open core. We’re not benefitting from any version of that. It’s like “You use our SaaS or you don’t pay us.” It’s not “You use our SaaS, use our free version, or use our expensive version that you can run yourself.” It doesn’t align with our business goals. It could still protect us in certain ways, but it just seems like a distraction.

[unintelligible 01:00:17.13] you would actually have to change your business model to enable open core.

Yeah.

[01:00:24.09] So if we’re going back to the fears and the transition and why change, and which was essentially give yourself protections, moving to an open core model wouldn’t have made sense because that’s not the direction of your business. It would have been foreign, it would have been alien to how you actually operate now.

I would say it would have been closed source at that point. It would have been like “We have a free version of Sentry, that is really basic, that is the open source version of Sentry, and then we have a great closed source version of Sentry, that you can never run on-premise because we don’t wanna sell that anyways.” So that’s ultimately how it would have looked for us. And that makes no sense.

In all honesty, I’ve never really thought thoroughly about that before today, but… We just knew we didn’t want that kind of business model either way - the free bad version, and the great paid version that costs a lot of money… And you can’t really do the great version that doesn’t cost a lot of money, because you never make any money. But I even think that we’re in the cloud era very much; you can still argue one way or the other, but… There’s no business that will exist in 20 years that will not use cloud providers. That’s the straight up truth, so… you can just build a SaaS business at this point. It’s harder in some industries… We’re in the middle zone, so it’s a little bit hard for us, but also acceptable… But that’s the decision we made, and that drove a lot of our business decisions. Again, it’s about the shape of what you’re making a decision on, so…

Yeah. Can we go back into the parameters that are associated with the BSL? Because I think this is important just to make very clear, because this is what really drew you to it, was the ability for it to convert. So the three parameters I understand that are required is what does it convert to, which means it converts from the BSL license, and eventually, based on some sort of time - which is the second required parameter - it’s gonna convert to an open source, or we’re not sure if it’s an OSI-approved license or not, if it has to be… But then the last one is this use clause, which is sort of like a legal scenario, where “How do you use the software?” That’s usually what the legal teams are concerned about.

Can you reframe that to kind of – not so much sell the BSL, but… We have a lot of people listening to this show that’s like “This is the first time I’m hearing about it… Why would I choose it?”, essentially. Answer the question of why should someone out there in your situation choose this license?

Yeah, I agree, the first two clauses I think are mostly straightforward… And we worked with our legal team - rather our highly-paid, outsourced legal firm - to come up with what the right solution was for us. One, they validated we could do this time window, they validated we could do it this way, like how we’re doing these date stamps, they validated that Apache 2 was fine… And then they’ve helped us come up with scenarios for the parameter clause, the use case clause, or the grant; I forget what it’s called. And that is the hardest thing, because that’s just legal language… And that’s frustrating. If you’ve ever been in a sales negotiation thing, there’s usually this red line of your terms of service, and it’s so annoying, all the time. It’s like, I don’t know, we change the word “the” to the word “a”, or something like that. That’s my view of these red lines… And the fear of this use clause that you have to adopt is you need it to scope to your risk.

So our risk is somebody takes Sentry and they sell it as a SaaS service. If they wanna take the open source Sentry and provide services for it, like if they wanna go say “Hey, if you pay me, I can help you run Sentry” - we don’t actually care about that. I don’t know if legally they can with our clause; it’s like this complex, grey legal area. That’s a challenge with this. Our intention, for what it’s worth, is that they can. So we’re gonna figure that out in the near future… But we said we don’t want another SaaS service to be able to sell Sentry.

I’ll give you a real example that would never happen… But we don’t want New Relic to be able to run Sentry and sell it to their customers. That’s the most straightforward version we can give. It’s kind of obvious; that’s obviously a competitor to us long-term, and them running Sentry would be very threatening for us, if they could do it successfully.

[01:04:09.21] So we’re like “How can we craft language that stops that kind of company from doing that specific thing? Because that’s our definition of risk.” And then it’s just on the lawyers that come up with something that hopefully is targeted… So not too wide, but also not so narrow that there’s easy loopholes.

Right…

And we’ll see if we got it right, ultimately…

[laughs] Cross your fingers.

Yeah. I would say if nothing else, there’s a legal risk there. So if a company is in the grey zone, they’re still gonna question themselves, like “Is this a liability for me to try to do?” So I think at least we’re protecting ourselves… But the long-term thing we have to solve is like “Is it too wide? Is it causing some friction in areas we don’t want it to?” I think you should be a business to use the BSL. If you’re just an open source utility, just BSD. I don’t care, it doesn’t matter. But if you’re operating some kind of business, and you need some kind of protections, scope those very specifically and then bring it to a good legal team. That was how we did it, I’m sure that’s roughly identical to how Cockroach did it, and I don’t think it can work any other way. And that has to be very defined… So they can create this structured legal language that hopefully covers you, but also, again, it doesn’t harm your users or customers or however you would frame that. Your community.

That was frankly the biggest challenge with it, because the rest is easy. It’s just like, you have a license template, I can reason about time as a human, I can reason about what is a license to convert to as a human, but I cannot reason about the parameter for the grant as a human.

Switching gears a little bit, I wanna, if you can talk about – there was an FAQ and discussion around your relicensing Sentry post. Ken Johnson from GitLab reached out and sort of explained the scenario in which GitLab uses Sentry, and your response back to him was “Unfortunately, that’s the kind of thing we’re trying to prevent.” Can you kind of go into the details of that, that seem obscure? Was there a conversation that came out of this, and what specifically were you trying to prevent when you say that?

So I won’t talk too much about specifics; I don’t know exactly what GitLab does, but to my understanding, GitLab was trying to somehow ship Sentry with GitLab, bundled. And that, by definition - because GitLab is offering a service, and that would constitute monitoring - is what we wanna prevent. Because at that point there’s nothing that forces GitLab to contribute back to Sentry at all. They’re just offering Sentry to their customers, ultimately, right?

In that scenario it’s like we could give them a special grant if we chose to. We could give them a special license that says they can do X, Y and Z. That’s totally fine. But in our case, it’s like, we wanna prevent that scenario by default. We don’t want anybody to commercialize Sentry in any shape or form, unless they contribute back… Whether that’s financially, or some kind of agreement where they’re helping build Sentry, which is unlikely to happen if you’re reasonable.

And ultimately, we wanna make sure that if those situations do exist, there can be a conversation. Because - going back to Windows, which is a really easy one - if you want to give Windows to your users, then (I don’t know) pay Microsoft a portion of their effort on it. Pay for the technology you are giving away. And I think that can be win/win on both sides.

Think about marketplaces. You have a marketplace where – Heroku, for example. I don’t know if this is all public, but it doesn’t really matter. Heroku takes a rake on every add-on you buy on there. It’s probably 30%. It’s like the Apple Store, right? And they’re providing some value, but they’re giving the majority of it to you. It’s a mutually beneficial relationship… Versus what I would describe as more of a parasitic relationship, where it’s one way completely. So we just don’t want it to be where like we built Sentry, and somebody completely benefits, with no return.

Again, the emotional protections behind the license were the fundamental goal, but those emotional protections [unintelligible 01:07:58.10] that exact scenario, where somebody was not contributing back. Does that make sense? Did that answer the question well enough?

[01:08:05.12] It does. I mean, what I like about hearing that is that this license doesn’t prevent you from being able to grant additional opportunities, but you’re trying to prevent certain things to protect your business by default, as you’ve said… But there are ways around that, and I can understand that. As a business, you want to run your business and your open source project as a way that enables you to keep it going and to sustain it, rather than having it be used in capacities that don’t give back to the main project and influence its future and enable it. But I’m sure that companies like GitLab would, because of their focus on open source as well, would come back to you around your license and say “Could we operate in these ways?” and you’re still able, even with the BSL, to grant a different affordance to them.

Exactly, that’s the idea. It forces that discussion, which ensures we can create a mutual relationship, versus something which we actually have no control over anything… Which we just – again, going back, we pray that something works out in our favor, or that benefits both of us. And I think that’s actually really good; to me, that’s the right kind of relationship these things should be, and it’s the same way we’d work on our SaaS service with any other partner. It’s not like we’re just gonna promote them. We expect a two-way deal, so we both can benefit from our relationship.

Yeah. When it comes to the original shift away from your original license - what was your original license?

The original license on the Sentry server itself was a BSD 3, I guess.

Okay. When you transitioned from that to the BSL, that means you moved away from an OSI-approved open source license. Was there any implications to that transition? Because even though there’s a time clause that you will eventually convert to an Apache 2, which is OSI-approved (or it’s on the list of the approved licenses), what are the implications of that transition, that change? Did you have to change anything about the way you say your software is? Can you continue to say “Hey, Sentry is open source”, or does that change? What happens?

So I’m sure I’ll get some flak for this… I do not like this idea that language is coupled to legal ideas, or something like that. I mean, the way a bunch of the internet would reason about this - you cannot call Sentry open source, period. Because it’s not OSI-approved as open source. And that’s fair. But who controls the word open source? What does open source mean? Because open source means a lot of different things to a lot of different people. I think that’s an important idea to think about. Language is a very flexible thing.

I would say that Sentry creates a lot of the benefits of open source, but is per those definitions not open source, because it is per definition technically a proprietary, closed source license, that just offers a bunch of the same things you would get out of open source licenses.

Then I would also say, like, why is GPL open source? Who ultimately gets to decide what open source means? I think that’s a big – it’s just my opinion versus somebody else’s. So there is that. I think there’s a component of this that matters. So OSI-approved doesn’t really matter, at the end of the day. It’s just a license. OSI-approved, or this idea – it’s like, sanctioned and known. It’s just like “Here’s a list of licenses that we kind of understand and we think are good ideas.”

Right. It’s similar to the analogy we had earlier, which was like “Okay, you go to the legal team, you’ve got these two licenses, good to go. If you’ve got any of these licenses, maybe. If you’ve got any of these licenses outside of that, probably not at all.”

Exactly.

Or petition a good reason for it. So this is essentially a whittling down to a known criteria or set of licenses that we’ve leaned upon, believe in, that contribute back to the idea of open source. However, by definition, Sentry isn’t open source anymore.

[01:11:59.00] Mm-hm. I think that’s all it is. And I would love to see the flexibility of that change… Because again, you have to break down what does a license translate to. I think OSI does this, and maybe GitHub’s implementation is just a copy of it or it’s using it, but what are the bullet points of what this license provides, and what does it restrict? And that’s a very valuable idea, because that helps me as a developer - I’m not a lawyer - understand these things betters. Like, okay, I can use it any way I want, I can redistribute it in any way I want. All I have to do is retain this notice. That’s easy to reason about as a developer, or any kind of human.

I think that’s important, and to me that’s the actual benefit of OSI, or even just GitHub, of explaining and educating people on these things. So I’d love to see BSL explained in that same kind of way… But the challenge is that it’s like “It’s probably this, and it’s probably this, and then interpret this clause to the best of your ability.” So you can’t actually just distill it into something standard. So I don’t know.

I know there was a big push on an opinion that OSI should recognize that this is a good, standardized license, and that maybe we should classify things like this as open source. But again, open source - it’s language, and it means different things to different people. So does the BSL fit with the term open source? That’s unclear. It depends on what it means to you, it depends on which version of the definition you read from who.

I don’t wanna debate who is responsible for that definition or not, but I frankly don’t care. I care about what are the goals of it, and what are you allowed to do, and does it achieve those goals. To us, we’ve been joking - and I might have stolen this from Cockroach; I almost certainly did - it’s like an eventually open source license.

[laughs] That’s funny.

That’s a really good way to reason about it, right? Because that’s literally what it is, at the end of the day.

Well, you can adjust that timeframe, too. This might be going a little too deep, but I think it’s important - if you can shave that time parameter down to, let’s say, the longest necessary time period for which a fork of this or a version of the release of the software would be less usable by the things you’re trying to protect yourself from, right? That’s what you need to do. So if it’s three months, if it’s six months, if it’s a year… It doesn’t have to be three years like it is, like you said before. This is sort of a first step. If three years is too long, eventually you can move it down to six months or twelve… But even then, it will still be eventually open source-not open source, based on definition and language, as you’ve said.

[01:14:42.24] Yeah, exactly. But I think it is – what do you want out of open source? I don’t know, find a license that makes sense. But I do think BSL is a good license, and it will take some understanding… And it may never get adopted. And frankly, for all I know, at Sentry in six months we may say “This is an awful idea. Let’s find a better license.” It probably doesn’t happen, but it’s always an ongoing conversation. Not just with us internally, but the whole collective open source ecosystem.

The whole community, yeah. Well, that’s why I wanted to have this conversation with you, because 1) I’ve had a conversation with you before, and I know you’re pretty wise when you think about how you deal with your business… And we’re obviously here laser-focusing on various parts of open source, but one in particular over the last several years has been commercial open source and what’s going on in and around open source companies, and things like that… And I think it’s pretty important to have someone on the show like you to kind of share the whys and hows and the influences you’ve had around this subject matter, and speak to, as you’d mentioned before, your risk factors - the fact that you’re venture capital-backed, and the fact that you wanna protect yourself from certain things, and in the case that you said before specifically, a New Relic from being able to sell Sentry.

Those are very specific reasons, and I think that you can come on a show like this and speak to that to a wide demographic of people who were influenced by you, or building similar businesses that you’ve done… And that’s important, because we wanna be able to have great services and great open source-ish, if not straight up open source projects out there… And allow them to be sustained and thrive in ways that make sense for them and their business. Any closing thoughts, David, from you?

No, I think I echo what you say. It’s interesting to think about how things have changed over the past – I don’t know, it’s been a long time… I don’t know, 30+ years, in open source technology. And they’re gonna change a lot more I think even faster going forward. Like, what do the next businesses look like? What do the next projects look like? A lot of the licenses that we use today didn’t even exist a decade ago.

So I think there’ll be a lot of interesting stuff coming, and I think it’s on the community collectively to figure out that balance, of like we need to be able to grow open source, we need to make it sustainable, especially with the fragmentation that goes on these days… But there’s a lot of new challenges in the world, and in the community, and in businesses, so we’re constantly looking at how we move forward.

Cool. Thank you, David. I appreciate your time.

Yeah, thanks for having me.