The Changelog: Software Development, Open Source - Re-licensing Sentry (Interview)

Episode Date: December 8, 2019

David Cramer joined the show to talk about the recent license change of Sentry to the Business Source License from a BSD 3-clause license. We talk about the details that triggered this change, the specifics of the BSL license and its required parameters, the threat to commercial open source products like Sentry, his concerns for the "open core" model, and what the future of open source might look like in light of protections-oriented source-available licenses like the BSL becoming more common.

Bandwidth for ChangeLog is provided by Fastly. Learn more at Fastly.com. We move fast and fix things here at ChangeLog because of Rollbar. Check them out at Rollbar.com. And we're hosted on Linode cloud servers. Head to Linode.com slash ChangeLog. This episode is brought to you by Linode, our cloud server of choice. It's so easy to get started with Linode.

Servers start at just five bucks a month for your big ideas. Head to Linode.com slash changelog. Choose your flavor of Linux that works for you. Then pick a location that's right for you. London, Tokyo, Dallas, and many other places in the world. They've got you covered. Go from having that amazing shower idea to a hosted website in just minutes. Start small.

Expand as your idea blossoms into a huge hit. And we trust Linode because they keep it fast. They keep it simple. Check them out at leno.com slash changelog. What's up, everyone? Welcome back. This is the changelog, a podcast featuring the hackers, the leaders, and the innovators of software development.

I'm Adam Stachowiak, editor-in-Chief here at Changelog. On today's show, we're talking with David Kramer from Sentry about their recent license change of Sentry to the business source license from a BSD3 clause license. We cover the details that triggered this change, the specifics of the BSL license, and its required parameters, the threat to commercial open source products like Sentry, his concerns for the open core model, and what the future of open source

looks like in light of protections oriented source available licenses, like the BSL becoming far more common. So David, you re-licensed 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 backstory of the company or the project in terms of, you know, if you intended to be the company you are today or the project you are today. So take us into the position of like 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 one, your business and to open source software

at large. Yeah, for sure. So, you know, like you said, Century's been around a long time. When I started the Century project, it was very much on a whim. You know, it's, you build open source software, you just open source a lot of things you do, right? 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, go from there. So that's really not only 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 is 10 plus years ago, I was much younger, much more naive. 11. Yeah. So you kind of pick a 10 plus years ago, I was much younger, much more naive. Yeah. So you kind of pick a license, right? And I didn't have opinions back in the day,

other than I knew, 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. So because 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, right? But it's not about how do we force a company to do business this way by using our open source software, right? That was never our goal. It's just accessibility. So when we did that, we chose the BSD license, which is super free, but it was still licensed, right?

It wasn't just arbitrary. And if I went back, I would not choose the BSD. I would choose Apache. Okay. And I think Apache and MIT, they're 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, right? So 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.

Didn't really know what it was going to be. Thought it might have turned into a lifestyle business, but it was going well, right? 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? We have trademarks and all these other things. How can we ensure that a legal entity will understand this and sort of 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. And 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. Like 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 like, 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, 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 has been built by our company. So if you look at the contributor graphs, but that's only one piece of Sentry. We have a ton of libraries that are different repositories. We have a ton of other projects that are different repositories,

and those are actually under different licensing mechanisms. So, and we always had that, right? 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. And, you know, we had this hodgepodge of licenses. We had these companies doing things that we didn't think were right. And so we're 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 thought was 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. Yeah. I think what we've done is we've really aimed of 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 like 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 like the choice of the business, 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, I guess, their reasons for it. And they had a large history into MySQL and, you know, or MySQL, however you want to say it, and all that separation. So they've been down that road.

You mentioned this change was triggered by other companies. What do you mean by that? How so? Like what specifically? So 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. So I'll give you a real example. If you take one of our SDKs, so we capture errors in a variety of languages, right? So we build a software development kit to capture those errors, basically to instrument your application. Right. 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, like 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, et cetera. We should be the team that's able to monetize it. That's like the ideals behind it, right? Right. Let's pause there for a second. That's kind of what I want to talk to you about because that seems to be a big change

and a big shift is like, which seems obvious. It seems logical. If you're making the software, you want to be the ones to be able to monetize off of it. And that does make sense. And where you're going with that is pretty interesting. Yeah. So ignoring the internet debate about open source and what all this is, there's a lot of

people with ideals, like the really extreme edge cases of the world. And I sort of exclude all them because they're just out there shouting on the internet as if they would shout about any random topic, right? But almost everybody, when we made this license change, and we explained it, 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 kind of, 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 going to 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 would probably die and get replaced by something else. And sometimes that's okay, but that's not really what we want as developers. We want to be able to use something and trust that it's going to exist and that we can build off of it, right? Right.

Because otherwise open source doesn't really matter. If it's constantly us having to plug in new dependencies and worry 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. And so in my opinion, everyone needs a push for supporting some kind of sustainable models behind all kinds of open source. And those models are going to be drastically different depending on the type of project. So Sentry is, it's an infrastructure piece. It's a SaaS business. It's a service at the end of the day, right? 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? 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 that 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 the same way you can century in a service? Is that unique to a service? And is it obviously it is, but you, but is that the only place where projects are rethinking their licenses because of, I would say maybe the lack of maturity

and 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 like 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?

Cockroach DB, 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 want to 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 spent a lot of time on pricing and packaging and that's core to a business, right? If you think of an open source project as a business, your license is your packaging and your pricing is just bundled into that, right? And I don't think people actually sit down and think about how that works. Like, how are we going to offer this to our customers in a way that they want it? So one, that they're willing to use our software. Two, that they're willing to buy it, which is sort of accepting the terms of the license. And three, 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 biased lens these days. But that's how we thought about it. We said, what do we want to achieve as a business, which is the same as what do we want to achieve in our open source project? And it's like, well, 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. 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. What are they doing? Is it worth $1,000? Then charge $1 thousand dollars. Is it a small, tiny five line snippet 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 century open source repository the title of it was switch license to Apache 2 that's that kicked things off which if you look deeper into it it's basically you talking to yourself a little bit until young Leonard 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 kind of spelled that out. You said our goal is a more universally understood license with potential future protections.

And 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 relicenses, you mentioned concerns around protections-focused licenses. And you chose business source license. Yep. But it also changes after a while too. You've got like a time period in there. Can you kind of break down why you chose that license in particular? Maybe some of the parameters around, you know, why 36 months it 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. So I worked at Dropbox and Dropbox is much like big

companies. If you want to 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, you can't use a lot of licenses freely, right? So 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 going to do. That's their business-critical infrastructure, right? And 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 going to have to make a strong case for it. Right. Because they've already kind of pre-checked which licenses kind of meet some of their necessary legal criteria. And that's why you have those parameters. Yeah. And so that was the idea behind a universal license. Like we should standardize things that we know fit in a checkbox. Now, the counterside 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 am not an expert on this, but I'm going to tell you what I know. So big caveat. Is there any expert really in licensing? Maybe aside from Heather Meeker, maybe she's pretty much an expert these days. 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, right? 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 want to 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 a, we are a significant business at this point, we have to evaluate those concerns. Meaning that Amazon would use Century. They would sell Century. Okay. Gotcha. So we don't want Amazon or Google or Microsoft selling Century without our consent, right? Like we don't want them profiting and not contributing back to the fundamental R&D investment that goes into Century, right? That's the only goal. And I think everybody can get

behind that goal, right? So that's a version of protection. But 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. And they never helped. Like they weren't here for the 11 years of building it, right? Yeah. And even in many cases, you know, what you're doing there too is not just protecting your business you're also protecting all the contributors who have joined you know the century fight the cockroach db 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. Like if you want things to be sustainable, if you want something to be long lasting, then it has to have like financial backing of some sorts. And that's the guarantee we created out of this. But that's a business protections at the end of the day, right? So going back to the BSL. So what we said is we want those things, right? We want

those protections, we want a license that can be universalized. And the biggest thing was like, we didn't want GPL, we didn't want to have two versions of Sentry where we create an open core model. We just, 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 in 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. And that's free, or 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, you know, 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, right? 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't take that chunk of century and use it somewhere else. Now, 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 of, we'll say 2020, four years from that date, 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, that Cockroach chose it. And I talked with them and I liked their reasoning. Three years is enough time that it protects us because we think in three years that version of Century 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 and that's a nice flexibility. But after that, it 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, et cetera.

But unrelated to legal side, we made the commitment internally, and we've even committed this externally. If there is something that makes sense for the wider community, petition us, we'll open source it in a free license. We can do that. And we can also grant one-off licenses for things. 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. Can you help me understand more so this stamping in the timeframe? Because are you stamping the entire repository and new commits? So basically, are you stamping the entire repository and new commits? So basically, if 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 two, is that how it works? Or is it per commit? What do you mean by that? It's a little tricky. So this is a legal gray area. So 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 at a different file and all these other things. We're 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 two and

a half years, right? So you're just giving 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 going to 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 well enough? It's almost like releases. Yeah, that's the best way to think about it. You're essentially, that release will eventually, as itself, and is departed, divorced from any future work, that release, you know, I don't even know what version you're at,

let's just say 2.2.2 for whatever crazy reason, right? You know, 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 of time, this code base converts to Apache 2 and has the affordances of that license. Yeah, exactly. So two things. So one, it's easiest to think about it releases because that's how any reasonable company would go about this. It's N years from the timestamp of that release, and that's written in a 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 an 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, right? So maximum of four years, but your choice. And the license clause, I forget what it's called, the use clause. And that's where most people would have the most opinion. And so that is going to 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 is, in layman'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. And that's very different than MariaDBs, 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. This episode is brought to you by Git Prime. Get Prime helps software teams accelerate their velocity and release products faster

by turning historical Get data into easy-to-understand insights and reports. Because past performance predicts future performance, Get Prime can examine your Get data to identify bottlenecks, compare sprints and releases over time, and enable data-driven discussions about engineering and product development. Shift faster because you know more, not because you're rushing. Get started at getprime.com slash changelog. That's G-I-T-P-R-I-M-E dot com slash changelog. Again, getprime.com slash changelog. so obviously when you're building a business there's some inherent fear that will creep into

any business you know every business has. So one big part of surviving a business is winning over competition. But then you also have this flip side 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. So in terms of your business, upset your business, you know, and I guess one thing I have curiosity about is like this fear of, you know, 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 backstory. So Century is very much a venture capital-funded company at this point. We've raised something like $67 million, which is pretty significant. The first time we raised money, our seed round, a long, 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 stuff. It's fine. 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, like hosting this themselves and selling it? Like 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, right? And my response was, it's not happening today. We'll figure it out. I'm not worried about that. And 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, right? Like Amazon, I'm going to use Elastic. I don't know that much about how Elastic's worked internally and all these other things, but Amazon sells Elastic, I don't know that much about how Elastic's 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. It's the way I'd reason about any of it. 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 going to invest in that because it's a high risk move. And 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. And 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 riffing, like, well, what would we do if tomorrow Amazon's like, well, we're selling Century, right? And for many people, that's a much scarier idea than us. I think we're a little bit, I'm going to 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, you know, we're the market leader,

and we've had a lot of stiff competition for many, many years. And 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, right? 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. 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. Adibis alone is like so unbelievably successful, like unheard of success, right? Yeah. Well, I mean, it's like four times bigger than its next competitor. 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 kind of patting yourself on the back, pretending everything's going to be okay. You 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 want to make weak bets, right? Right. Ignorance does not bliss in this case.

Yeah. And so, okay, maybe the community would rebel and they would keep using Century, 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. And 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 that we think we've done 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. And 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, right? And we're 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 could make that really, really tricky, but then they could just fork it or patch it or whatever. So it's not really

sustainable. We talked about, literally there were conversations of like, what if we put like a bunch of if statements in the code that's like if Amazon, like 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're like, the only way we'd be able to like 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. If you like, realistically, and this was before we knew about the BSL or this even kind of license scheme. And so we're just like, 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 is this focus. 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, are not trying to do it today. But there are other companies that try 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 an infringement. right? And our product and everything. And it was, this is when Sentry's domain was get sentry.com. And I think their domain was something like get sentry.cn. Oh boy. Yes. Yeah. We didn't care, whatever, like that's not going to 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 like a small company. We're not going to 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 going to 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. Like you can go take Century from a month ago, and it's the old license,

right? So you can still run that. You could fork that. You can do whatever you want. Yeah, it's almost rewinding up in a month. You have the same affordances you had before with the other license. But it's like, when you think about that, Century is really complex. We have a team of, I think, probably 60 across engineering, product, and design building century every day. And so you can fork our month-old code, but you are not going to be able to keep up. And frankly, it's probably filled with bugs. If we're honest with ourselves, everything's filled with bugs. 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.

It's like, if you are a company that wants to sell Century, you ask yourself the same question from a business risk point of view, I'm going to invest a bunch of time and money into this, probably. And am I going to 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. And I actually think, 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, you know, 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. So we feel good from that point of view. And again, it's not like it caused harm to our business. It's just like, it doesn't feel good. It feels like somebody's stealing from you. And that's like, I actually honestly believe the emotional hit a lot of these times is worse than any financial hit. Like the emotional hit that you see of your peers or your employees or the community getting aggravated by something is just, it's awful, right? Like, and you saw this with Node.js, right? Like that huge emotional hit that they had when that one company took sort of ownership

and again, not an expert there either, but like took ownership sort of of Node.js. And they're like, oh, let's fork this. We hate this. Like 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 like all really angry.

And we're also ultra competitive at Sentry where the only rule at Sentry is we have to be the market leader. Like we have to be the market leader. We have to be the best at what we do. And so when somebody steals our work or tries to rip it off, we're very aggregated because we put so much effort and pride into the output of what we have. Yeah, I can tell that about you. I guess siding up for those listening, there's a whole separate interview with David on Founders Talk, my other podcast, where we talk at length about, I can't recall what we talked about, honestly. There's a lot of fun stuff. 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. And that totally makes sense. You mentioned that you're venture-backed. So I guess, you know, coming out of that meeting, you know, one of the questions you have is what if Amazon or someone else started to sell your product? And, you know, the question was that, and the solution was, well, let's get some licensing that protects you. And so now you have that protection, you can move forward. But, you know, 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. Co-founder of Chef.

Okay. Yeah, yeah. I wasn't sure if you knew him or not, but we had him on the Change Log a little while back. And we were talking to him about the soul of open source. And he was giving a keynote at OzCon, 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 makes 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 Century is just a bigger distribution channel for your brand name.

It's almost free marketing for you, even though they're selling Century. So I want to hear what you think about this. And I might be paraphrasing some of his response. So please go back to this podcast and kind of listen to his exact words. But paraphrasing is essentially, if Amazon did sell Century, even if they were profiting from it, that would be marketing the Century brand, the Century 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 ads for delivering Century 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 going to 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 going to 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. If you're like, well, Amazon's going to grow the top of the funnel by a lot, how much of that money is going to go to you versus Amazon? That's the truth, right? Elastic, again, 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, right? 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? Whereas like how much, like 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 Elastic search as Elastic themselves do. So let's just say Elastic overnight had double their revenue. Could they evolve? Like, could they take their products and their technology and that R&D and amplify it much more significantly than two different people building, especially now, there's two different versions of Elasticsearch, right? That's where I think the problem comes in.

So it's like, great, there was this big type of funnel. Diversified effort, you mean, like forked effort. So there was something on Hacker News, take it for what you will, I really enjoyed about 50% of the conversation around centuries 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 agree 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 just, it wastes money and effort of the collective world. Right? Right? I truly agree with that person. Like that idea that 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, the other one has a different nice feature. It just, it's not good. It's not good if you think about like if everything was great in the world and there was no money or anything involved, we'd all, like, 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 kind of what we see often

in some of these kind of competitive businesses. And in all honesty, in many cases, this just comes down to just trying to, I guess, circumvent your ability to do that innovation for whatever reason, right? Like 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, right? 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, 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's from competing with you, but essentially stealing your ability to build it better because of this diversified interests and this diversified, you know,

solution solving, how you're building different products in the same exact way. Progress. It's 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? They 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, right? 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 is a collective group that's taken ownership of it that is, to some degree, that is the business behind it now. It's like that collective group. So they're going to, ideally, not all the time, it doesn't have to work this way, but ideally, they're going to push the needs of everyone combined and forward that project versus for duplicates of that project. There's no reason that you would want to fork Kubernetes. Maybe? Like, maybe there's like some technical reason, but like, it's never going to go anywhere. But if Kubernetes was only owned by Google, well, then Amazon's going to create its own probably from a fork.

Microsoft's going to create its own probably from a fork. And none of them care about doing that because that doesn't benefit any of them. Like, they want a universal solution. And I actually think that mechanism for those kinds of projects actually works really, really well, especially when you can get big companies on board with sort of funding it, right? And that's what Kubernetes has been able to achieve because it's also funding a lot of 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.

How sustainable are they? But to some degree that if they're not, and they follow that 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 want to call it commercializing, but like not bringing in sort of revenue to sustain their, I don't know, employees, because they do have employees, right? Or whatever it is, versus is the technology not valued enough to be sustainable? And I think that's like an interesting conversation piece that you see with a lot of open source where we often talk about, like, well, like, how can I like, you know, fund my little library, like, this is probably really

popular in the Node.js world where there's infinite libraries. But like, again, going back to like, you've got five lines of code. Nobody cares. It's like 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 how should this open source thing 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, right? And if Elastic had built this foundation and tried to give up a little bit of that control,

could they have retained full commercialization? 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 benefited like the whole of the community in that case. Do you mean if Elastic took a play out of the playbook of Kubernetes in the fact that the Cloud Native Computing Foundation was formed and sort of invited a community and created a community, for lack of better terms, for exact terms, around cloud native. They coined the phrase, everybody bought onto 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. 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 going to do this because it doesn't make any sense. Yeah. 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. And the way 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 going to try and change this in any shape or way or form because it's a you know 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 because

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 sort of siloed project and, you know, this is not Century. Century is not a technology for people, right? It's not infrastructure, so it's different. But when you have a sort of siloed project and you know this is not century century is not a technology for people right it's 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 actually i wonder again not an expert but if you go back to dot net or microsoft languages so c-sharp visual basic you know they've they've stuck around forever but they weren't very open And adoption did not seem to really go anywhere. .NET's 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 could go to your funnel conversation, right? By them creating a more open environment, an 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.

It's kind of just like an interesting thought exercise of how you can approach these different businesses, these open source projects, and draw a matrix or a bunch of Venn diagrams. Where can you learn from that can be applied in different ways versus 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. So, and I do think there is, it is, you know, 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, it is a good time to keep thinking about that and to make some changes. Like, I love like what GitHub's done for the sponsor stuff, right? Like I was never doing Patreon or any of these other sites. Like we did a little bit as a business at Century, we'd give back.

But like GitHub, as a person, I've probably too much money now. I'm sure I was giving like $100 a month at least, which adds up. I was like, I don't know, this is accessible. It's good. And I actually think that's going to 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. What is up, everyone? We are working with Infinite Red to promote their machine learning course. It's called Beginning Machine Learning with TensorFlow.js. Learn more at js.infinite.red. AI used to just be for academics and data scientists, but not anymore.

You do not need a PhD, a master's degree, or even a four-year degree to learn about machine learning with TensorFlow.js. All you need is a working knowledge of JavaScript. Artificial intelligence and machine learning is a fast-growing field that anyone with basic JavaScript knowledge can learn, and the potential upside is so huge. Do yourself a favor and start learning how to apply machine learning to your code today. This is a three-week course covering an introduction to machine learning models, tensors, and the TensorFlow.js framework. The course includes real-world examples, actionable assignments, and quizzes to cement your learning. The course starts now and never ends. Plus, you'll have lifetime access to the course and materials. And of course, because you're a listener, you get a special bonus.

You get $100 off. Use the code CHANGELOG when you enroll. Learn more and enroll at js.infinite.red. And by our friends at Square. We're helping them to announce their new developer YouTube channel. Head to youtube.com slash square dev to learn more and subscribe. Here's a preview of their first episode of The Sandbox Show, where Shannon Skipper and Richard Moot deep dive into the concept of item potency.

Welcome to the pilot episode of The Sandbox Show. A show- Well, a YouTube show. Where we'll deep dive into subjects that developers find interesting. Don't worry, there will be plenty of live coding. I'm Shannon and this is Richard. We're going to cover a broad range of topics as the show evolves, but for today, what are we going to be covering?

On this first episode, we're going to be covering item potency. We had talked to people in our community and the thing that people seem to be really confused by is this concept of item potency and how does it relate to interacting with an API. And so I didn't do some Googling on this beforehand, but I know that you did. I did. So the definition of item potency comes from item and potent. So item being same and potent power or potency. So it's the same potency.

All right. Check out this full-length show and more on their YouTube channel at youtube.com slash square dev or search for square developer. Again, youtube.com slash square dev. 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 could solve our problems. Yeah, I think the first time I heard about it was when I read Cockroach Labs, their post for Cockroach TB, when they had made the change. And 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. Well, the post was June 4th, 2019. So it was earlier this year. So it's summertime. Yeah. Very fresh in mind then. Yeah. And, you know, I think coincidentally around that same time was, you know, one of these cases where we had seen a, you know,

another startup plagiarizing our work and weren't, you know, so emotional. And we're like, oh, I wish like 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, right? That wasn't one of these known quantity things. And 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, right? So it's somewhat standardized. And 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, you know, maybe we should just do the license change. And then should we actually evaluate other licenses if we're going to do the license change? You know, I chatted with the cockroach folks and tried to get their take on why, why the BSL,

why their choices with it. And, you know, to the best of my ability, I would say it was one-to-one with our goals. Like it really resonated with me in the conversation, the reasons they had made the decision, which helped me a lot with my framing and thought process of like 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 OpenCore in a second, but OpenCore is a closed source license to some degree, is what happens if Sentry fails? I don't think we will, but what happens if it does, right? I want Sentry to be able to live on in some way. If nothing else, for the knowledge that we had discovered, I don't know how you want to phrase that, but our learnings, I want to be able to stick around. And if it's closed source, they can't really stick around. So it's a really good example of, I think they do

this. I don't know how patent technology and IP and everything works, but take a game from the 90s, like a video game. Or I don't know when Doom came out. That's got to be earlier than that. But take Doom. Mid-90s? I don't know, early 90s? Yeah. Could be wrong.

Correct me. I don't know if you know either, but I think Doom might have been open source or something along those lines. Or there's some old style, like 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, right? And that is a really important idea to me. And 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 request accepted. Like, I don't need you to do my work for me.

If I find a bug in your software and you want to fix it, that's great. If you don't, that's great. I don't care, right? 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, right? Or a closed source in general. And the BSL doesn't lose that. And that's such a big deal because it does convert. And that component is when we said we could do this. Like 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 like my conversation with them. I'm like, I don't want to ever deal with another one of this. And I won't name the companies, but it's just like, came up like once every three months. And I'm just like, I am so emotionally drained from this that I never want to be distracted by it again. And then 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. Like even when people had full protection,

it was like, you felt bad for the what they had to go through to enforce that protection either way right yeah and so the board was like supportive they're like do what you think is right but it wasn't on like it the reason we made the license change was like 100 like the sort of early team was like you know we think this is the right way to protect ourselves going forward but we did think about like 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. I don't need your random library to be GPLed. 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 going to put my forceful opinion on how you use my software on you. If you want to use this in this specific way, then you must do X. Is that really that much different than a proprietary license? To me, it's not. And now you can argue like 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.

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, right? It's like we think about it holistically. But that's very different than OpenCore, which OpenCore is often also GPL. I'm sure there's a reason for it. And I'm by no

means an expert on OpenCore. But when I think about OpenCore, 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 want to use this software. I wish I could use the version that starting price is $100,000 a year. That's OpenCore for me in a nutshell. It's like free bad version, ridiculously high priced paid version because they have no other way to monetize. Sentry is like free great version, low price great version, scales the high price great version. That's what it should be. It's kind of like you expect with OpenCore that there's this

arbitrary paywall made for the enterprises, which is what it is because the enterprises can often pay more. But they often, you end up with this dilemma of like, well, what features am I going to 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, it's just a personal thing that 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 want 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 shape or form. And because of that, it also makes no sense to do open core. Like we're not benefiting

from any version of that, right? Like 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, right? Like it just, it doesn't align with our business goals. It could still protect us in certain ways, but it just, it seemed like a distraction. Well, you're not already doing that. You would actually have to change your business model to enable open core. 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 want to sell that anyways. So that's like ultimately how it'll look for us. And that makes, it makes no sense. And 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. Like 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 like the straight up truth. So you can just build a SaaS business at this point. It's harder in some industries. We're in a 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, right? Again, it's about the shape of what you're making a decision on. 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, you know, 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 parameter, required parameter, based on some sort of time, it's going to 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, you know, how do you use the software? That's usually what the legal teams are concerned about. Can you kind of 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. You know, why would I choose it essentially? Answer the question of why should someone out there in your situation choose this license? Yeah, so 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 is fine.

And then they helped us come up with scenarios for the parameter clause, the use case clause or whatever, the grant. I forget what it's called. And that is the hardest thing because that's just legal language. And that's frustrating. It's like, if you've ever been in like a sales negotiation thing, there's usually like this, this red line of your terms of service. And it's so annoying all the time. It's like, I don't know, we changed 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, right? So our risk is somebody takes Sentry and they sell it as a SaaS service. If they want to take the open source Sentry and provide

services for it, like if they want to 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 gray legal area, right? That's a challenge with this. Our intention for what it's worth is that they can. So we're going to 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, right? 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. And 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. But- Crushing fingers. Yeah. I would say if nothing else, there's a legal risk there. So if a company is in the gray zone, they're still going to question themselves, like, is this a liability for me to try to do?

And 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. Like, 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, doesn't harm your users or customers or however you, but also, again, doesn't harm your users or customers or however you would frame that, your community. And 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 perimeter for the grant as a human. Switching gears a little bit, I want to, if you can, can we 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, like bundled, right? And that, by definition, because GitLab, like bundled, right? And that by definition, because GitLab is offering a service and that would constitute monitoring, that is what we want to 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? And so

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 want to 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 are helping build Sentry, which is unlikely to happen if you're reasonable. And ultimately, it's like, we want to make sure that if those situations do exist, there can be a conversation. Because if you, going back to Windows, which is a really easy one, if you want to give Windows to your users, I don't know, pay Microsoft a portion of their effort on it, right? Pay for the technology you are giving away.

And I think that can be win-win on both sides. Like think about marketplaces. Like you have a marketplace where, so Heroku, for example, I don't know if this is all public, but it doesn't really matter. Like 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. So like there, it's like a, 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 we build Century and somebody completely benefits with no return. And again, the emotional protections behind the license were the fundamental goal, but those emotional protections were that exact scenario where

somebody was not contributing back. Does that make sense? Did that answer the question well enough? It does. I mean, so 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 too. 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 to, even through 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 going to promote them. We 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 going to promote them. We expect kind of a two-way deal, so we both can benefit from a relationship. Yeah. When it comes to the original shift away from your original license, what was your original license? So, our original license on the Sentry server itself was BSD3, 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? Does that change? What happens? So this is, I'm sure I'll get some flack for this. I do not like this idea that language is coupled with legal ideas or something like that. So I'm going to give you 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 like, 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. And I think that's an important idea to think about. Like, language is a very flexible thing. So 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. And then I would also say, well, like, why is GPL open source? Who ultimately gets to decide what open source means? And I think that's a big, like, you know, it's just my opinion versus

somebody else's, right? So there's 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, 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 whittling down to a known criteria or set of licenses that we have leaned upon, believe in, that contribute back to the idea of open source. But, however, by definition, Sentry isn't open source anymore.

I think that's all it is. And I would love to see the flexibility of that change, because I think you again, you have to break down what does it mean? Like, what does a license translate to? And so 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 better, right? Like, okay, I can use it in any way I want. I can redistribute it in any way I want.

All I have to do is, you know, retain this notice. Like that's easy to reason about as a developer or any kind I want, all I have to do is, you know, retain this notice. Like that's easy to reason about as a developer or any kind of human, right? And I think that's important. And to me, that's the actual benefit of OSI or even just GitHub, like 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. And 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, like open source, it's language and it means different things to different people. And 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, right? And I don't want to debate who is responsible for that definition or not, but I frankly don't care. I care about what are like the goals of it and what are you allowed to do and is it achieve those goals? And to us, we've been joking and I might have stolen this from Cockroach. I almost certainly did was like, it's like an eventually open source license. And that's, it's like a really good way to reason about it. Right. Cause that's literally what it is at the end of the day.

Well, you can also, you can adjust that time parameter too, right? So this might be going a little too deep, but I think it's important is if you can, you know, shave that time parameter down to, you know, 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, you know, 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 12, but even then it will still be eventually open source, not open source, based on definition and language, as you've said. Yeah, yeah, exactly. But I think it is like, you know, what do you want out of open source? I don't know, find the 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, century and six months, we may say this is an awful idea. Let's find a better license. 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 one, I've had a conversation with you before. I know you're pretty wise when you think about how you deal with your business. And we obviously hear laser focus in 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 the hows and the influences you've had around this subject matter and speak to, you know, as you mentioned before, your risk factors, the fact that you're venture capital backed and the fact that, you know, that you want to kind of protect yourself from certain things. And in the case that you said before, specifically a new relic from being able to sell Century, you know, 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 are influenced by you or building similar businesses that you've done. And that's important because we want to 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. But any closing thoughts, David,

from you? No, I think I'd echo what you say. I think 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 plus years in sort of open source technology. And they're going to 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? You know, a lot of the licenses that we use today didn't even exist, you know, a decade ago. So I think there will be a lot of interesting stuff coming.

And, you know, 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 businesses. So we're constantly looking at how we move forward. Cool. Thank you, David. Appreciate your time. Yeah. Thanks for having me. All right. Thank you for tuning in to this episode of The Change Log.

Hey, guess what? We have discussions on every single episode now. So head to changelog.com and discuss this episode. And if you want to help us grow this show, reach more listeners, and influence more developers, do us a favor and give us a rating or review in iTunes or Apple Podcasts. If you use Overcast, give us a star. If you tweet, tweet a link. If you make lists of your favorite podcasts, include us in it.

Also, thanks to Fastly, our bandwidth partner. Rollbar, our monitoring service. And Linode, our cloud server of choice. This episode is hosted by myself, Adam Stachowiak, and Jared Santo. And our music is done by Breakmaster Cylinder. If you want to hear more episodes like this, subscribe to our master feed at changelog.com slash master. Or go into your podcast app and search for Changelog Master. You'll find it.

Thank you for tuning in this week. We'll see you again soon.