The Changelog: Software Development, Open Source - Community perspectives on Elastic vs AWS (Interview)

Episode Date: February 17, 2021

This week we're talking about the recent falling out between Elastic and AWS around the relicensing of Elasticsearch and Kibana. Like many in the community, we have been watching this very closely. Here's the tldr for context. On January 21st, Elastic posted a blog post sharing their concerns with Amazon/AWS misleading and confusing the community, saying "They have been doing things that we think are just NOT OK since 2015 and it has only gotten worse." This lead them to relicense Elasticsearch and Kibana with a dual license, a proprietary license and the Sever Side Public License (SSPL). AWS responded two days later stating that they are "stepping up for a truly open source Elasticsearch," and shared their plans to create and maintain forks of Elasticsearch and Kibana based on the latest ALv2-licensed codebases. There's a ton of detail and nuance beneath the surface, so we invited a handful of folks on the show to share their perspective. On today's show you'll hear from: Adam Jacob (co-founder and board member of Chef), Heather Meeker (open-source lawyer and the author of the SSPL license), Manish Jain (founder and CTO at Dgraph Labs), Paul Dix (co-founder and CTO at InfluxDB), VM (Vicky) Brasseur (open source & free software business strategist), and Markus Stenqvist (everyday web dev from Sweden).

This week on The Change Law, we're talking about the recent falling out between Elastic and AWS around the relicensing of Elasticsearch and Kibana. Like many in the community, we've been watching this very closely. Here's the TLDR for context. Last month, on January 21st, Elastic posted a blog post sharing their concerns with Amazon and AWS misleading and confusing the community saying, quote, they have been doing things that we think are just not okay since 2015, and it has only gotten worse, end quote. This led them to relicense Elasticsearch and Kibana with a dual license, a proprietary license, and the server-side public license, also known as the SSPL. Of course, AWS responded two days later, stating they are, quote,

stepping up for a truly open-source Elasticsearch, end quote, and share their plans to create and maintain forks of Elasticsearch and Kibana based on the latest ALV2 license code bases. There is, of course, a ton of detail and nuance beneath the surface here. So we invited a bunch of folks on the show today to share their perspective. You'll hear from Adam Jacob, co-founder and board member of Chef, Heather Meeker, open source lawyer and the author of the SSPL license, Manish Jhan, founder and CTO at DGraph Labs, Paul Dix, co-founder and CTO at Influx Data, Vicky Brasore, open source and free software business strategist, and last but not least, Marcus Stinkvist, an everyday web developer from Sweden. Huge thanks to our partners Linode, Fastly, and LaunchD not least, Marcus Stinkvist, an everyday web developer from Sweden. Huge thanks to our partners, Linode, Fastly, and LaunchDarkly. Linode is our cloud of choice. Check them out at linode.com slash changelog. Our bandwidth is provided by Fastly. Check them

out at fastly.com. And our feature flags are powered by LaunchDarkly. Learn more at launchdarkly.com. Linode is simple, affordable, and accessible cloud computing the developers trust. Linode is our cloud of choice. We trust them, and we think you should build anything you're working on, a fun side project, or that next big info move at work with Linode. The best part, you can get started on Linode with $100 in free credit. Get all the details at linode.com slash changelog or text changelog to 474747 and get instant access to that $100 in free credit. Again, linode.com slash changelog. What's up? Welcome back. We have an awesome show today.

We're here to get community reactions around the Elastic versus AWS situation and the SSPL license change of Elasticsearch and Kibana. Elastic re-licensed with the SSPL. And there's a few people on this show that believe they went about that license change the wrong way, but this is not the beginning of the story. This conversation has been going on for a while. In fact, Adam Jacob brought up the subject of Elastic and AWS on episode 353 of this show. On that episode, we talked with Adam about the war for the soul of open source,

and the title of that episode, we talked with Adam about the war for the soul of open source, and the title of that episode could not have been more prophetic. To kick things off, we're going back to that conversation with Adam. For context, Adam is co-founder and board member of Chef, and we're talking about business models and how they correlate to open source business models and how, from Adam's perspective, the AWSs, the Azures, and the Google Clouds of the world, they provide a humongous marketing funnel for open source businesses like Mongo and Elastic. Here's the conversation with Adam. Let's talk about the business challenges commercial open source companies face. You said earlier in the call that things are thriving now, and we see Elastic and others out there thriving as well that have been in similar situations as Chef.

Talk about the business side of things for Chef. I mean, I think in order to really go deeper into business, we've got to just set some ground rules for how we think about business. So how I think about it and how I think a lot of people in the sort of modern era of software startups think about it is, in the smallest nutshell, you can imagine that you have this funnel, right? And at the top of the funnel is everybody who might, could ever use your product. right? So every possible person who would ever care. So that's your target market. The bottom of the funnel is customers, people who pay you money for the privilege. And what you're trying to do is get people from the top of the funnel to the bottom of the funnel, right? It's

just how many people at the top can I push to the bottom? And there's a ratio there where you want that number to be as high as possible. You'd love to get 100% of them. You know that you want, right? And so you're trying to just extract dollar bills from the top to the bottom. There's a bunch more we could go into in terms of metrics and recurring revenue and all kinds of stuff. But sort of the TLDR there is people at the top, money at the bottom. So with open source there really we

talk about it as an open source business model but that's wrong in the same way that like devops isn't a job title so like you can't devops isn't a job title it still isn't a job title it never was a job title but we lost the war you know like there's plenty of devops engineers in the world and so the idea that that's not a thing it doesn't matter that I'm a pedant about it, right? The same thing's true in open source business models. There is no open source business model. There are business models, and then there is open source.

And they're two very different, very separate things. There is nothing unique about open source and business. Business is business. You get people from the top of the funnel to the bottom of the funnel. You either do that with the unit economics that make you money or don't make you money. If they make you money, then you can pour more dollar bills into the acquisition of people at the top of the funnel to get to the bottom. Even if that

means you don't turn a net profit and still be a great business, because as soon as you stop burning money to acquire more stuff at the top, but you make a lot of money at the bottom, right? And so in open source, when we talk about open source business models, what we really are talking about is how do I create a channel at the top of the funnel? So people come in in multiple different ways, and we talk about those as channels. So one channel will be, I'm an open source user of your software. I download MongoDB. I download Redis. I used it. Therefore, I'm in the open source channel to the bottom of the funnel, right? Another channel would be my boss, the CIO, heard about

Redis and CIO magazine tells me you should use Redis, right? Now I'm in a very different channel than the open source channel, right? Now I'm in an enterprise, or I get a cold email from a rep that says, have you heard about Redis Labs, right? That's a different channel, right? So we have all these different channels. There's a partner channel where like, maybe the guy at Pivotal who was consulting on your Cloud Foundry deployment

tells you that you should use Redis. That's a partner channel, right? So like we have all these different channels that people come into our businesses through, right? This is true of every business it's again it's not unique to open source but that open source channel is interesting because it's humongous right if you're a successful open source project that channel is full of people right because lots of people are using the software that's why it's successful open source software. So it kind of dwarfs the others in pure numbers, right? Just the sheer magnitude of what's possible is really high. And so when we're designing and thinking about our businesses,

what tends to happen is we think about the revenue that that channel produces as belonging to us, right? If I'm the chef people, I look at that channel and I go, any chef user belongs to me. And if there's competition in that channel, I don't like it because it means somebody else can compete with me to monetize the people that are at the top of the funnel, right? right so a good example here is if i'm uh mongodb and i sell atlas which is their hosted sass product for mongodb and amazon and microsoft are both going to offer mongodb as a service that competes with me to monetize the bottom of the mongodb funnel right i mongodb make this investment at the top of the channel i i expect a return at the bottom of the MongoDB funnel, right? I MongoDB make this investment at the top of the channel. I expect a return at the bottom. And now they're competing with me in the bottom. And this comes back to, you know, how do you feel about that competition is the question. Because

in one point of view, you're like, well, competition sucks, right? I'm the one who put all the money into building it. I'm the one who did all of this stuff. And so you look at this thing and you're like, I deserve the money at the bottom of this channel. Well, flip that over though. The value of the channel is that it's massively huge. It's adoption. The size of the number of users is why the open source channel was valuable in the first place. If Amazon or Microsoft create services that sell what I sell, what's the impact at the top of the channel, right? What's that do to cement MongoDB as an excellent choice for users at the top of the channel, right?

The answer is it jacks it up, right? Like Amazon has a chef service they sell it for money they do revenue share right so they sell my what used to be my proprietary software but now my distribution you can buy it from amazon as a service directly from amazon we do rev sharing together amazon runs and maintains that service i promise you that my channel got bigger my open source channel got bigger when they did that, right? The fact that that button exists meant more people were willing to use Chef than they were before, right?

The pie got bigger. So what's happening when the Redis and the Mongos of the world look at that problem is they decide that the top of the funnel doesn't get bigger or that they don't care about it getting bigger. And instead, they care about the extraction at the bottom of the funnel, right? So they're nervous about it. They're like, oh, Amazon will out-compete me. They'll sell it for less.

They'll bring better features. But this, to my point of view, is completely bonkers, right? Amazon's never going to invest more in MongoDB than MongoDB. It's insane on its face, right? And Elastic went public that whole time with Amazon as a competitor. But you know what? I've ran Elasticsearch. I use it as a component in my product.

One of the reasons is that it was a dominant standard. How did I know? Well, everybody offered Elastic as a service, right? It was the de facto thing. So that choice was easy. So I wound up in your channel. So from a business point of view, they're making these decisions because they believe that that's what's best for the extraction of capital or revenue at the bottom of the channel. And

they're doing it at the expense of the spread at the top of the channel. In your case, you got a rev share with Amazon. Is that the case with Mongo or with Redis or was that unique to Chef? And would that change your outlook at all if that rev share was gone? It's not the same. I don't know. I certainly am not privy to whatever negotiations they may have had, right? I know the ones I had. You know, one of the things that Amazon or any partner, anybody who's going to run your code as a service needs is the assurance that they'll always be able to provide that service to their customers, right? And you know what's hard to do that with? Proprietary software. Because I have no, my only hedge is the business arrangement. Do you see what

I mean? Like, I can sign a contract that says so, but if I change the terms on my proprietary software, or I build a new SKU, well, can I still run that thing as a service? Have we bifurcated it? Like what's the deal? So the mechanism there is really complicated. So one of the reasons that that rev share exists is because so much of those assurances about what's in the open was in the open, right? Even more so now. That doesn't mean that that's always what Amazon will do or even what they should, but that's how it worked for us. If it didn't exist, it wouldn't really change my point of view. Because if the question is, can I, as the primary producer of the product and owner of the brand, and the reason that people attach to those things out-compete someone who is essentially selling a generic version of what I sell, if I can't out-compete that person, shame on me. Like, you really can't

convince me, you really can't convince a customer that the best person to service their MongoDB is MongoDB. Because man, if you can't, like, there's something fundamentally broken in the value proposition here, right? And I think the truth is that they can. If you look at Mongo's performance, if you look at Atlas's sales numbers, it continues to go up. It was going up before they changed the license, right? And the reason is it's a good product. And it's a better product than the one that you receive if you just turn on DocumentDB on Azure. Because it's kind of bare bones when you turn it on in Azure, right?

And the Atlas version has all kinds of stuff that the other one doesn't have. The idea that that competition in open source, where the reason you're here is because you have this massive channel, it doesn't make much business sense to me that that's the conclusion we would come to. I understand how you get there, but it doesn't make much sense. Aren't disruptive products, though, not necessarily better? They're usually actually worse, but they're usually actually worse but they're good enough

and the cost is disruptive and so in the case of an AWS version of Mongo yeah it's not going to be as good or as maybe well supported or have as many features as Mongo's version of Mongo but it's satisfactory and it's way cheaper so it's disruptively cheap

and then you add to the fact that there's no there's no R&D there's no development costs from Amazon's side. So you're not competing with them on features. They're just free-riding all the features that you're building. Well, but here's the thing. So this is where we come back to the funnel, right? So now we're back to the business.

So sure, maybe Amazon, but this is why it's good business for Amazon to launch your stuff as a service instead of just compete with you directly. So like you brilliantly elucidated why they would want to launch a Mongo service in the first place. Right. But as soon as they do that, if the top of the funnel was fixed, if that if that created no more interest in your product than it did before, then you'd be right. But it doesn't. Instead, it turns out that the single largest pool of software developers on the planet are the ones that use Amazon and AWS or Azure or Google. How many of those developers are using one of those platforms? And if your stuff is on all three of

those platforms and it's not on the others, how many eyeballs do you get that Cockroach doesn't? The answer is a ton of eyeballs. So many eyeballs. And so the size of that funnel, your possible monetization gets bigger, hugely bigger than it was before. And in that moment, your ability to capture that revenue, every single one of those cut rate document DB users is a potential lead that's already using your product. So all you have to do is go find them and be like, yo, did you see how much better our console is? How much better our operation stuff is? How you can get on a Zoom with the dude that wrote that indexing feature when it's broken? I dare you to get that out of Amazon. And next thing you know, Citibank is like, you know, Atlas looks pretty good.

I think those kinds of ideas, though, sometimes are so, seem so logical, but yet not everybody thinks like that. I think this is a great idea of how could you leverage the fact that these platforms are so massive that they actually become your marketing channel for you. They are your marketing channel for you. And the only thing you have to give up is that they're also going to monetize some number of your customers. Back to open source's punk rockness, right? Like, there's a, like, F the man vibe, where, like, when you're saying that Amazon's a net positive for your business,

everybody's like, but they're the man. And Amazon's going to destroy Elasticsearch. And you're like, dude, Elasticsearch is worth $1.5 billion with a B. It's like that commercial where the guy's like, sir, you are the man. Remember that commercial? Like, who exactly are we protecting here? Because last time I checked, they were public and killing it. Next up is Heather Meeker. Heather is a well-respected open source lawyer and a specialist in open source software licensing and strategy.

She wrote the book Open Source for Business, and it serves as a guide to open source software licensing. We're talking to Heather because she's a lawyer who wrote the license. The SSPL license is a result of her work with MongoDB, and we wanted to understand the design and the intention of the license. All right, here we go with Heather. Heather, let's open up with the SSPL. You were the person behind writing it. Is that correct? Yes, I helped MongoDB draft the license with, of course, the help of Mongo Legal Counsel and their business team. I think it's fair to say that I led the drafting of it. Gotcha. And full title of it is

the ServiceSide Public License. Yes, that's right. Take us back to, I suppose, the early days of drafting it. What's it intended to do? What's the goal of this license? SSPL was drafted in order to meet a need in a particular way. So I'll explain what I mean by that. At the time, and this would have been late 2018 to early 2019, many companies that were providing software under open source licenses were very concerned about the use of the software by cloud services providers. And what they were concerned about was that the cloud service providers were using the software, not contributing back and not, you know, participating in the development of the software. So at that time, there were actually quite a few companies,

and most of these, by the way, were companies in what I would call the platform software space or middleware software space, and they were trying to figure out what to do about that. They basically went down two different routes. The first route was the source available route in what we call an open core business model. And that's not what SSPL is. But that's where you have a core of open source software, usually under, say, Apache. And then you reserve some of the upsell elements for under proprietary or source available licenses. That's the route that most companies went down.

Mongo, on the other hand, wanted to see if they could create a license that was an open source license, but that managed this issue. And that's how the SSPL came about. So they drafted the license, submitted it to open source initiative for approval as an open source license. And eventually it was withdrawn after quite a bit of comment without a particular ruling from OSI on whether it was appropriate for approval as an open source license. What happened in that proceeding? Why wouldn't, like what were the deciding factors? I guess they didn't reject it, but it was just like being debated to a certain degree and then withdrawn eventually.

I assume it was withdrawn because it was not going anywhere, or was there a different reason for withdrawing it? It was a long and fraught debate, and the debate had to do with a number of concerns. I would encourage anybody who's interested to go and read the archives of what's called license review or license discuss. And, but, but I'll try to summarize, understanding that there were a lot of comments and I can't summarize them all. Sure. The first was technical commentary about whether the license met the open source definition. So there is a definition of open source. There's also a free software definition. One of the main tenets of that definition is that the license can't have any license

restrictions. So that would be source available if you say you can't use the software for this purpose. It also says that it can't discriminate against users or technology contexts and so forth. I'm paraphrasing, of course. So there were those aspects and there were some comments about that aspect of the license. There were also a lot of comments about who had drafted it, the process by which it was drafted, and what Mongo's intent was in creating the license. So those were like meta comments, not about the license itself, but about the context.

And so all of those things were being discussed. And if you've ever been on one of these discussion groups, you know that they get discussed in a non-sequential format. And it can be very confusing to follow, but I'd say those were the main themes. Okay. And so do you think that, I mean, I don't know if bias is right, but as the author of the SSPL, do you believe that the SSPL represents, I guess, even the spirit of open source if it's not officially an open source license, or do you think it's something different? Well, we drafted it to fit the open source definition. And as a lawyer, you have to have concrete things to go on. And the open source definition is what we had.

I think the discussion brought out that people felt that there was something beyond meeting the open source definition that needed to be satisfied. And there was a great deal of debate about that. So we looked at the open source definition that needed to be satisfied. And there was a great deal of debate about that. So we looked at the open source definition. We definitely avoided license restrictions. We avoided things that were discriminatory according to the requirements of the OSD. But all of the meta issues were things that really kind of couldn't be addressed by the draft itself. There is some discrimination built in though, right? Or how does it actually, how does it work in order to stop that particular problem that was trying to be addressed?

Isn't that discriminating the use? I know we get into legalese here, but you're good at this, so help me understand. I would say not discriminatory because in a way, all copy left licenses apply different conditions when you do different things. So if you use discriminatory in that way, then GPL2 is discriminatory because it only applies certain conditions to redistributors. So that is actually fair game in copyleft licensing. SSPL applied specific conditions to use of the software. I'm paraphrasing now, but as a software, software as a service to provide the same

functionality of the software. And so, yes, there were conditions that were imposed in those situations that weren't imposed otherwise. But that, I think, for most people, isn't the meaning of discriminatory, according to the OSD. Discriminatory would be more like you can only use this in a particular field of use. Like you can use it in medical devices, but you can't use it in nuclear weapons or something like that. You can use it for good, but not for evil.

Well, it's interesting that you say that because there is now a new licensing movement, I guess, called the ethical licensing movement that actually does impose conditions based on ethical concerns and moral concerns. And those are clearly not open source licenses because they actually do impose license restrictions. In other words, you can't use the software for this particular purpose. I heard about this too, where I believe it was in China, there was a specific license about companies that didn't adhere to work ethics, where I think it was like a 999 or something like that. The anti-996 license.

That was actually very interesting, if you'll permit me to make a comment about it. It was, first of all, a very well drafted license. So it was professionally done. It did address labor conditions. And again, I'm paraphrasing, but the license says you can't use this software if you are violating the international labor standards. It was intended to raise consciousness about labor practices in China. What was really interesting about that is that the license was released on GitHub. By the way, I think it may have been more a thought experiment than anything else. But it then caused that GitHub repository to become a vehicle for people to discuss the issue. So it became almost like a

social networking initiative to raise consciousness about the issue, rather than specifically to develop a license document. So I thought that was a very interesting phenomenon from the point of view of what happened around putting the license in GitHub and around the development of the license. This episode is brought to you by our friends at Retool. Retool helps you build internal tools fast and easy. From startups to Fortune 500s, the world's best teams use Retool to power their internal apps. Assemble your app in just a few minutes by dragging and dropping from pre-built components.

Connect to most databases or anything with a REST, GraphQL, or gRPC API. Retool empowers you to work with all your data sources seamlessly in one single app. Retool is highly hackable, so you're never limited by what's available out of the box. If you can read it in JavaScript and an API, you can build it in Retool. You can use their cloud service or host it on-prem for yourself. Learn more and try it free at retool.com slash changelog. Again, retool.com slash changelog. Again, retool.com slash changelog. It's interesting how, you know, there's so many usages of licenses, and you mentioned the OSI approval process and how it was contextual in terms of their Mongo's on the cause community you mentioned how many of the

legacy license in the OSI approved long ago would probably not be approved today and then you mentioned that the criteria for the approval has changed but the OSD has not so it seems like there's like a lot of moving targets in terms of getting approved by the OSI and Jared mentioned like you know in terms of this isn't an OSI. And Jared mentioned, you know, in terms of this isn't an OSI approved license. Do you feel it is open source? It's kind of an interesting perspective, just the fact that there's this OSD that's been drafted. I think the last time it changed was 2007, if I recall correctly. It was a long time ago. It basically, you know, hasn't changed in the time that I can remember looking at it. But I think what's interesting about that is that what OSI is doing is trying to create community consensus and isn't wedded to this written definition.

By the way, I say that because that's what they say. Approval of a license does not merely require it to meet the open source definition. So it does raise an interesting question about the clarity of the criteria and the process. But this is a community process. So those are always living, breathing things. And they get developed as they go. And people are always pushing for transparency, but it can never be, you know, perfect. The fact that this OSD document hasn't changed in a while, though, is that a good thing or a bad thing? Because you might say it's a bad thing, because it doesn't reflect the way that modern software is developed and deployed into consumers' hands. And then you might say it's a good thing because it's so strong it doesn't need to change.

The definition is so strong that it doesn't have to change. What do you think about the fact that it hasn't changed in so long that it's a good thing or a bad thing? Well, I actually agree with you. It's kind of a good thing and a bad thing. It has worked pretty well over the years, and it's been remarkably robust over the years. Maybe it's time to revisit it, but that would also be a very long process and possibly very controversial. There are other definitions, by the way. There's the free software definition, and there's a

WN, I think it's called the software contract. Sorry if I'm getting that wrong. But those are much shorter and less complicated. So I think if it were revised, there might be some interesting possibilities to harmonize those definitions. I would say that whether the definition changes or not is one question. I do think that the transparency of the criteria for approval is very important to the community. What's at stake for these companies and organizations? Maybe they pick SSPL.

Whether or not it's an approved license or not, what do they win or lose based on that? Is it the marketing value of the term? Is it goodwill? What's at stake? SSPL is used as part of a dual licensing model. And that is something that has been around for a long time, but it's not as popular as it once was.

So it was really pioneered by MySQL. And so what they did was they said, here's our software. It's under GPL. Actually, they used a variant of GPL. And if you don't want to abide by the GPL requirements, you can negotiate with us for a commercial license. And that's a process that's sometimes called selling exceptions. So the strong copyleft licenses like GPL, and then later AGPL, and then finally SSPL were all used in other contexts as well, but as part of these dual licensing initiatives. The reason that companies adopted them in a dual licensing strategy is that they were intending that people who are using the software commercially would

probably have to come negotiate for a license. And what happened over time was that the MySQL model, which worked pretty well, began to break when software moved up to the cloud because the requirements of GPL only kicked in on redistribution and that wasn't happening anymore because of cloud deployment. So then companies that were doing dual licensing models moved to AGPL when it was released in, I think that was 2007. And SSPL is, I think, you know, kind of a logical extension from that. So that's what they're trying to do.

They're trying to allow people to use the software for certain, you know, in a, say, to test it out, to use it on a small scale, to use it to do certain things, but to require people to come to the table when they want to do things at scale or certain kind of commercial activities. Yeah, because a cloud provider is a user, essentially, right? I mean, at that point.

Yes, that's actually a very perceptive comment. They are users. They're not distributors of software. It's a little bit of a complicated question, but I don't think there's too much doubt about that. So what that means, if you look at the GPL, say, it specifically says that the license doesn't control the use of software. And so that is where the issue comes to play because the cloud providers are users. And so under, say, GPL, they don't have any, you know, basically don't have any conditions at all. Right. And it's kind of odd to say, I mean, sure, they're not distributing it out to, you know, individual installations, but they are providing it to many. So it's still one of many, it's still many scenarios. So, and that seems to be where the issue is, the language of the future of software, the way it is,

is not so much, especially in cloud, is not a distributed model. It's a single installation that means a distribution of change. You're no longer sending a binary or source code to be compiled by a bunch of people. You're setting up a service and then charging for the service. It's a new way of doing it, newer. Copyright law treats use and distribution a little bit differently.

I think that one of the things that maybe it didn't anticipate properly was use And, you know, copyright law treats use and distribution a little bit differently. I think that one of the things that maybe it didn't anticipate properly was use, was copying at scale in order to deploy software for hundreds or thousands of users. That is something that is, you know, relatively new. So as software licensing has progressed, certain things worked pretty well when we were in a model where one person would use one copy of the software, but that isn't the world we live in anymore.

So when it comes to the letter of the SSPL as reactions to Mongo initially and now Elastic relicensing now, there have been critics. This is a debated thing about the topic. Is it open source? Is it fopen source? Which I think is a terrible term. I can't believe I just hopped on the bandwagon and used it,

but this is the verbiage that's out there. There are those who think it's a business risk, this SSPL. So now I'm reading from Vicky Brasuer's blog. You probably have read this. And she says, she showed it to some IP lawyers, and she says, by using an SSLP project in your code, you are agreeing that if you provide an online service using that code, then you will release not only that code,

but also the code for every supporting piece of software all under the SSPL. It's not a stretch to interpret the wording of the license as requiring users of the SSPL software, therefore, to release the code for everything straight down to the bare metal. This is one interpretation of the license itself, saying effectively that there's perhaps this collateral damage that might happen because of the way that it's written. I would just love to hear as the author of it, and I'm sure you've thought through these things, how do you respond to that? What do you think about that statement? Is it feasible? Is it outlandish? Well, I do think it's an oversimplification of the terms of the license. And don't get me wrong, these kinds of provisions are very complicated to read. So it's hard to reduce them to soundbites. I do think on the question of business risk, this is the way I look at it. I work with many, many companies to develop open source

compliance policies. And so what companies do when they develop those policies is they have like a stop-go caution list. And you would not expect even a GPL to be on a go list. In fact, it's usually on a stop list already. And SSPL will be there too. Any network copyleft license, meaning any license that has source code sharing requirements when you deploy over a network, those will all be on a stop list. So when you say it's a business risk, well, yeah, but already a lot of the copyleft licenses were defined as business risks. So you know, this isn't blindsiding you, this concern. It's known from the out, the outstart. Yeah, of course. I mean, you would not expect people to greenlight SSPL software.

What they would do is they would look at the license and say, okay, this is okay with us, or it's not, and then they would make a decision about it. So that's something that users have to decide for themselves. I do think that what you quoted was overstating the risk somewhat, but it's not useful to get into the details of it. You have to actually look at what the license requires. And it really is focused on particular use contexts where people are providing software as a service. I want to say thank you to Vicki for writing this post because I'm going to quote one more and ask you about this, but very, very helpful, Vicki, in doing this call with Heather. She said, basically, in regards to the SSPL, basically it's a hostile proprietary license masquerading in open source clothing. Now it's getting vicious.

I don't know what to say about that. Whether it's proprietary. Proprietary is not open source. So, you know, it's really the same issue. I actually think if you look at the FAQs and announcements and so forth for Mongo and Elastic, you know, they're pretty forthcoming. So I'm not sure what is being masqueraded there. So I think that's, you know, it's language intended to incite an argument, but I don't know that it's terribly meaningful in an objective way. Yeah.

The primary concern with the SSPL really is Section 13. A lot of the concern isn't really elsewhere in it. Obviously, it's a loan license, but it's primarily Section 13, which describes what we talked about here, which is redistribution, restrictions on usage, etc. Yeah, if you were to redline it against a GPL or even GPL 3, you would find that almost all the substantive changes are in Section 13. Well, Heather, thank you so much for joining us and explaining these things in ways that we could only fumble around in the dark to understand. I think it's been very helpful. And anything else that we didn't ask you or anything about the license itself or about the situation that is being discussed and debated that you want to say that we haven't asked you about? Well, I would say that I would remind people that the alternative is probably

to go to a source available license. So if people, you know, are calling it names and so forth, you know, what they should consider is that businesses are going to do what their business strategy requires. And so most companies that don't adopt something like SSPL are going to go down the source available route, which is definitely not open source. So it's a question of whether you think half a loaf is better than none, I think. And there are definitely differing views about that. I would say the reality is that most companies are actually going to use licenses that are truly restrictive in a way rather than SSPL. So I would say anybody who is using SSPL is at least trying to go down something like an open source route,

even if you don't believe it's open source. Up next, we're talking with Manish Jha, founder and CTO at DGraph Labs. Manish came on this podcast a little over two years ago on episode 322, talking about licensing and relicensing DGraph. So we thought it'd be fitting to get him on this episode as well. Here we go. So Manish, you and DGraph are in a somewhat similar situation to Elastic. You're not Elastic, but you're set up a lot like Elastic is set up. Is that right? That's true. So Elastic's licensing, the way they have done it is that they have their open source code co-located with their proprietary code

and it's all source visible except the open sources under Apache if I'm not wrong and then the proprietary code is under Elastic and similar to Dgraph where our open source code is Apache and our proprietary code is under Dgraph license. So as a meta note where did you hear about this news? And did you read both sides?

Have you read what AWS has had to say? And what's happened after the relicense? What's your purview? I mean, I think, I mean, Hacker News, right? Hacker News went into flames over this. And so that's where I came to know. I don't know, actually, I did not have a chance to look at what AWS actually had to say about that but I did read through the multiple blog posts that Elastic sort of released about

what they're changing and some of the reasonings for why they're changing and this is a story that it's not the first time right this is the same story that we already had for CockroachDB we had the story for MongoDB. We have this, you know, across Confluent and Redis Labs. You know, this is just a series of changes that are happening in the entire open source ecosystem. And you guys went through similar things as well, because we even have a whole show for you back in October of 2018, where we have you on the changelog there and back again d graph's tale an excellent name if you're a fan of the hobbit uh yeah like i am episode 322 so you've told us this story before but like i guess

we don't need to rehash the entire thing but this has been an area of struggle for you and your company as well it is something of uh you know i wouldn't say it's such a big struggle as something like Elastic where Amazon is directly sort of like, you know, quote unquote, attacking them, right? For us, it's more of like a forward thinking scenario where we, you know, we realize that we love open source. And just like Shea mentioned, the founder of Elastic mentioned in his blog post, you know, I got my feet dabbed into open source like long time ago and really believe in it.

And when I was starting Dgraph, I was not inspired by any sort of business motives, right? Like I was not planning out, hey, how would like five years from now, we will make money. I didn't know how to make money from open source. I just wanted to build open source software, right? And that's how we got started.

So similar sort of like trajectory there in terms of like our interest towards the open source community. And so, you know, I mean, yeah, I think the open source theme is similar there. So what's happened since is that AWS has forked both Elasticsearch and Kibana and are going to carry on open source forks,

community forks, as they're kind of being pitched as. What do you think about that? Are they going to succeed? Are they going to fail there? Is it a real risk for Elastic or no? They did that once before with the Elastic open distro. And I think people were really concerned about how that would pan out. And remind me, Elastic's share price has not decreased too much, right?

It hasn't gone into a spiral downward. So I guess they're doing well, right? They'll probably survive another attack from AWS. But I think, you know, some of the criticism that I see online about MongoDB's SSPL and other companies is that these open source companies are motivated by business and therefore they are somehow being moralistic.

Morally, they are being challenged. But I feel like, you know, the same people then turn around and say, Amazon is completely okay with doing these kind of things because there's well within their rights to do so because of the licensing put together by the open source. And so the conflict that I feel is right there, right? You cannot have two different moral bars. One for the company who is making money out of your inventions

and the second for the inventor themselves, right? And sometimes I just wonder, right, how many open source infrastructure software has Amazon created and launched in open source, right, how many open source infrastructure software has Amazon created and launched in open source, right? Like, do we, when do we expect to see DynamoDB coming out in open source, so someone else can build a business like Amazon has done with DynamoDB? That'll be great, right? I mean, that'd be a great day for open source, if Amazon does that, but I don't think they have any plan to do it it because that's not how they operate.

And so, you know, it's well within, I think it's, in fact, I would say it's recommended for open source companies to make sure that they are able to build a successful business just like Amazon is building, just like everybody else is building. And so the motivation to make money out of your inventions

is completely justified on, I would say, moral grounds. Well, there's a concern too, at least based upon Shay's blog post on Elastic saying that Amazon and AWS wasn't putting back into the open source buckets, so to speak. So from two avenues, one, the perspective you just shared, which is DynamoDB, for example, isn't open source, and that's not part of their business plan to do that. But then the concern and I suppose what led to this scenario we're in now is essentially AWS not playing by the community rules. The license doesn't depict this, and that's kind of what this move is doing. It's like, hey, if you can't operate by community rules,

then we're going to put a license out that makes it illegal for you to do things another way. So not pitching back into the open source thing. But then you can sort of draw some sentiment from just simply the titles of their blog post on the AWS open source blog back in 2019 from Adrian Cockcroft, keeping open source open, open distro for elastic search, which is something you mentioned. And then the second one is the more recent around elastic search, which is stepping up for a truly open source elastic search.

It's an interesting perspective you've drawn there where they haven't open sourced certain things they have because of business reasons, but then wanting to be a good community player in these ways. It seems, I don't know. What do you think? It is questionable, isn't it? It is kind of questionable. And I think like, you know, if you look at SSPL, the server side public license, I think from MongoDB, it's actually really, it's, I actually, I'm still a bit baffled that it's not approved by OSI because it, to me, is a fork of derivative of GPL,

just like AGPL is, which also makes GPL a bit more permissive, right? If you look at AGPL, it allows you to not have to release your source code if you are using it over the network or something of that sort. Actually, I forget exactly the details there. But SSPL says that you don't have to release your source code if you're not directly competing

by providing the core product as a service. So it's more permissive than a GPL. And so I think it has all the merits, I feel, in my opinion, to be open source approved. And guess if SSPL in a world where SSPL gets open source approval, I don't think we have any problem here, right? Then everybody has already sort of like gathered around SSPL, which we could not do around the Commons Close, right? I mean, that was the same idea for Commons Close, but it could not get us there. But MongoDB is a big name, and so MongoDB could get the industry around SSPL. And then we don't have a debate because it would be open source, right?

Yeah. There's some details around that. We had a conversation with Heather Maker on this exact subject, and something she had said which will be in the same podcast is if you redlined SSPL versus AGPL the primary differences that sort of come out is essentially section 13 which describes you know if you make the functionality of the program or modified version available to third parties of the service blah blah blah that's where the change is, is Section 13. Everything else is essentially AGPL. And there is a lot of debate around the nuance and the process to be approved. So OSD is very clear, hasn't changed in a long time.

OSD being the open source definition, that's very clear because it hasn't changed. And it's even derived from Debian's existing rules on what open source definition is. So there's some history there. But the criteria and the ways that you go about getting these licenses approved by OSI is a bit more difficult. You can read the transcripts and the notes from the meetings and stuff, but that takes a very motivated listener slash reader. And so some of this intention of this show is to sort of demystify some of that stuff and maybe give you a TLDR or TLDL. Too long, didn't listen. But that's essentially this criteria for getting it passed. You say that the SSPL should be or could be open source.

You're baffled, as you said, that it's not. Yeah. That it hasn't been approved by them. Yeah, and to be honest, I haven't looked at the counter arguments to that, right? And I'm sure there are smart people there on the other side and they have some counter arguments. But from a slightly distant perspective,

without having to go into the intricate details, it seems very similar. And maybe if it was built in 1990s, it might have already been involved in OSI, right? But I think one thing that we should probably take away from Elastic's stuff is that the holy grail of license here is to, so if you look at Elastic license as well, right? It's divided into two portions.

One is the open source part and the other one is the completely proprietary part. And so proprietary part, they are not changing from my understanding. They are changing the open source part of their code and making it available via either SSPL or the Elastic License. And both of them sort of in some shape or form

disallow building a competing service. Restricts cloud service providers from offering, this is quotes. Yeah. That's what it says. Restricts cloud service providers from offering our service as a service. Right. That's in violation of OSD 6. And they are very clear about it's only to third parties, not for internal usage.

So if I am a big company and I need to build a product, I can provide it as service to my other teams in the company, just not to your users directly. That's a commercial restriction. Don't compete with me, essentially. Exactly. Yeah. Right. Because you can compete internally inside your own company, not make any money from it, but get great usage of the software. But you can't create a competing company against the inventor. This goes back to what you were saying before, the inventor or the user of the invention. Exactly, yeah.

And they can still build a commercial product on it, just not a competing service, right? But the holy grail would be to offer a single license, right? That takes away, hey, this is proprietary part of the code and this is the quote-unquote open source or similar to open source part of the code. Ideally, what looks like what they want to get to is to offer a single license that can cover both their free

and their paid features while being as open as possible, right? And if that would be there like i think we would jump on it immediately because we also currently have dual license which is what cockroach has which is what uh elastic has and you know many others have uh but having that single license would be would be the holy grail and i don't know if you wanted to talk also about bsl right which is the maria db's um license where they say that uh the the initial code is going to be uh proprietary but after a certain amount of time three to five years it would become open source and it would become apache 2 or something, which is what Cockroach is doing,

CockroachDB is doing. So they're open source. They switched to Cockroach BSL modification slightly. You know, that's also like a great way to, but essentially say the same thing, right? Which is, you know, please don't compete with us by providing a service, which is providing a service to our core product right like you know and and if you think in terms of what's the core product for amazon

you know let's say let's say like e-commerce is a core product and if you were to like use amazon machines to uh or amazon technology to actually build a competing stuff i'm pretty sure they'll be pretty pissed as well. And so all these companies are doing is that we have spent a lot of time and effort into building, and this is our main source of living, right? Let's just play nicely, right? Otherwise we have to invent new licenses.

Yeah, David Kramer shared some of his sentiment on that subject because Century was licensed BDS3 and transitioned to the BSL. And I'm paraphrasing, but what I can recall from that conversation, episode 371, relicensing Century, was essentially David was saying, I want to do whatever it takes to help me run this commercial business, but also respect open source. Because without the business making the thing, there is no thing. And that's a paraphrase of David's sentiment on that. But that's essentially what he boiled it down to was his concern in regards to transitioning away

from BDS3 to the business source license, which you mentioned. And actually, if you think about what is happening, I mean, again, I argue that SSPL is very close to open source, to the AGPL or GPL, right? But SSPL is not open source. So what's actually happening right now is a bunch of open source companies, which truly believe in open source are having to switch to quote unquote, non open source licenses. And that's not, that's not great. Right? Yeah. And that's not great. And the that's not great and the funny thing is

they are all talking about the same one player in the market right they're not talking about about a google or about microsoft or anybody else in fact in the elastic blog post they mentioned that they have played very nicely with all the other players in the ecosystem just the um just the aws right um Much I do about AWS. Yeah, exactly. I mean, I have no personal thing against AWS, right? Like we run on AWS,

we are completely fine. And from what I understand, they're not trying to build a D-graph alternative, right? But there is something there where if a bunch of companies are talking about the same, you know,

quote unquote, curious actor. Yeah. Let's call him an actor. I don't want to say a bad actor, right? Exactly. Because we just don't know. But a curious actor, I think there must be something there, right? MSI, it's in their best interest for open source to help these businesses that have this concern, have this trouble, to create an open source license that gives them the needs they, it seems like they're intending to respect and live within a world of open source,

whether it's for the, in quotes, open source brand name that can't be trademarked because it's not trademarkable, but it certainly has a marketability to it. Like if you masquerade as faux open source, is that right, Jared, faux open source? That's right. Then you're not open source.

But there is a marketability to saying you're open source. For sure. Absolutely. Yeah. And I think, you know, we do open source because it allows, it's not just a way to have more eyes and make sure that the product is, the score is of high quality and so and so forth

but there's also it's a distribution model right it's a distribution model it's a way by which you think your software could be consumed by anybody without necessarily having to pay you right and again they're not saying that if you build a commercially successful product using our software pay us they're not saying that they're just saying like just don't build a competing service against us um and and also at going back to the first the the the initiation of a bunch of these open source companies it started with like one or multiple like people who just believed in open source right they they just wanted to make things in open source because they have consumed open source software their life right so when i was like in college i was all into linux and i was playing with gen 2 and ubuntu and i don't know like whatever other linux

flavor there was out there freebsd netbsd and i just believed in open source um and that was our stance against you know windows at the time right. And so I've created multiple projects, some of which actually got popular, including Dgraph. And then we have Badger, and then we have Ristretto, and they are all open source because we just believe in it. It's a bit of pain to have to move away from that, even in theory, just because of this one problem. So Manish, clean slate, start Dgraph over today, same exact software,

same business, pick a license. I love it. What are you going to go with? I think SSPL is looking pretty attractive. SSPL is looking pretty attractive right now. And also, just notice one more thing, right? From 2010 or 2015, the world has changed to be more cloud-first and on-prem later than on-prem-first and cloud-later approach, right? And so if I were or somebody else were to build a service today, they might choose not to even make it open source.

They might say, you know what? Snowflake has done really well by being completely cloud-based system. And if I'm not wrong, Snowflake is not open source, right? And so why open source, right? Maybe that could be the question is like, open source already has tons of problems because there is actor or multiple actors like causing so many issues.

Like why bother with all that? Just avoid all of that and just go completely closed source. And you could still build a good business out of it, right? And so then it becomes just a question of principle, right? Do you still really believe in open source? Do you still believe that your code should be, we we should be other people should be able to check it and make sure that you're not doing anything fishy or help you find bugs or you know that kind of stuff um so it becomes a matter of principle and a matter of business it seems like This episode of The Change Log is brought to you by Render.

Render is a unified platform to build and run all your apps and websites with free SSL, a global CDN, private networks, and auto-deploys from Git. They handle everything from simple static sites to complex applications with dozens of microservices. Thank you. One-click scaling, zero downtime deploys, built-in SSL, private networking, managed databases, secrets and configuration management, persistent block storage, and infrastructure as code. Heroku customers running production and staging workloads typically see cost reductions of over 50% after switching to Render. Here's the best part. We work closely with the team at Render to ensure you have zero risk. By giving you $100 in free credits, plus they're going to assign a world-class engineer to your account to offer guidance and answer any questions you have. When you're ready to transition your infrastructure, they'll be there to help you with that too. Automate your cloud hosting with Render at render plus a world-class engineer assigned to your account to guide you along the way. Just send an email to our special email, changelog at render.com, to get access to those free credits.

All that begins at render.com slash changelog. Coming up in this segment, we're talking with Paul Dix, co-founder and CTO at Influx Data. Paul shares his perspective on running an open source business, how Influx Data is innovating their commercial offering while having a permissive MIT licensed version of InfluxDB. Paul also shares his thoughts on this standoff between Elastic and AWS and why he's long on Mongo and short on Elastic. Here we go. So Paul, tell us your name, tell us your company and kind of your view of the open source world, where your opinion is coming from. Yeah, so I'm Paul Dix. I'm the CTO and co-founder of InfluxData. We're the makers of ImpluxDB, which is an open source time series database. I created it in 2013 and I've been initially running the company and then as CTO, which I'm still doing to this day. So my experience over that time has basically been trying to build a business around an open source software project, particularly in infrastructure software

and in databases in particular. So Elastic, obviously, I'm very familiar with. I saw it when they were initially becoming a company. I remember the project early on. Some of the work that they've done served as inspiration to me as I was building out Influx and the various parts of our stack.

Very similar software, very similar business model. It looks like Influx and the various parts of our stack. Very similar software, very similar business model. It looks like Influx is MIT. Can you tell us your license selection and how your business works around it? Yeah, so all of the open source software that we create is MIT licensed. And our business model is basically, so we are essentially at this point an open core business.

So there's open source InfluxDB, which is MIT licensed. People can do whatever the hell, what they want with it. It works essentially as a single server. We have a fork of the open source projects that is closed source and proprietary. If you want high availability or scale out clustering of InfluxDB, that is our commercial offering, right? So essentially we don't put clustering features

into the open source. Everything else is fair game to go into the open source. If it has to do with a single server, optimizing query performance, APIs, functionality, all that kind of stuff, it goes into free open source. So we launched this as a managed service inside of AWS in, I think it was April of 2016. We launched it as basically like on-premise software product that people could buy in September of 2016.

Our AWS service is still running to this day. Essentially what that is, is it's the closed source software spun up, you know, a customer can come and sign up. They say what size, you know, instances they want, how much storage, how many instances. We spin up the, you know, the closed source enterprise version of our product on it. We add monitoring and backups and stuff like that. And then, you know, that's the hosted version of the product. The, what I say, on-premise version is essentially you buy the software from us, it's an annual subscription, and then you run and manage it yourself. And that's either in your own data centers,

but plenty of people are also doing it inside of AWS, GCP, all that kind of stuff. Last year, or I guess late 2019 now, we launched basically version two of our cloud product. And that essentially is, it's a very different kind of thing because it's not just a database and it doesn't look anything like the open source software that we create. The API is the same, but the underlying architecture and how everything works together is completely different. And that's for version 2.0 of InfluxDB. So the model we switched to with 2.0, we essentially moved to a cloud-first model. So we deliver that cloud product continuously as a SaaS service. And then over time, some of those features get pulled out into the open source in FlexDB. Is that because of a realization that the other way wasn't working well enough?

Or it's just, why did you switch to the cloud first model? Mainly because it has nothing to do with open source versus closed. It has everything to do with software delivery cycles so before we looked very much like an enterprise software company we'd have anywhere from two to four feature-bearing releases a year which could then you know get shipped to our cloud customers and shipped to our on-premise customers the problem with that is you don't get that many cycles of iteration and each each release is super painful to do because there's so much code wrapped up in it.

So I really wanted to move to a continuous delivery model so we could get much faster feedback, features out to customers quicker, and the individual releases would be much, much smaller. So that had to do with basically wanting to be a cloud company and deliver a cloud product, as opposed to deliver a packaged, on-premise enterprise product. How does that trickle down to your open source then?

How does InfluxDB, the open source, benefit or not benefit from this switch? I think the benefit is that by the time something lands in open source, we've already vetted the features and vetted its functionality and how it works inside our cloud products. The thing is with our cloud product, we're able to iterate on it and release fixes very quickly. Once you ship something in an open source release,

it's much more painful to ship a fix, ship an update. So I think that's a benefit. The drawback is it's less, I think it reduces the collaboration with the community in terms of what we're developing and how it's getting done and all that kind of stuff. It basically makes the open source

like a downstream kind of product. Well, that reflects the tweet you put out, which says, my own preference is to keep open code permissive and open and have a clear strategy, as you just depicted here, with how that code will be used in the commercial offering. So you're eating on dolphin, which is good. Yeah, so what I just described is basically our 2.0 model, but I'm actually trying to move even beyond that

over to what I call basically like complementary software model, right? So we have a new project that we announced a few months ago called InfluxDB IOX, which is basically the new core of the database written in Rust using Apache Arrow. And the way that we're building this out is essentially there's the open source thing. And then there's another piece of software that we have that is closed source. And as a whole, the system is designed to be two pieces of software, one of which is totally open and permissive, permissively licensed.

You can do whatever you want with it. You can compete with us. That's fine. That's by design. And then the other piece, which is the software that we're writing to be able to run the open source software in our cloud offering. So the reason why I say it's complimentary is because what I want is I want our cloud product to be running the open source bits exactly as is, like exactly as the open source community experiences them. Because it means we'll find bugs faster.

It also means we can have more of a collaborative effort with the community in terms of making improvements because we're not like right now with our cloud two offering, like InfluxDB 2.0 open source is one project. Cloud two is totally separate. Now we use some of the libraries from InfluxDB 2, but it's not like, it's not even like a fork of the project. It's literally two separate projects and products, and they have the same API. Yeah, two masters. Right, exactly, yeah. In terms of serving two masters is what I mean.

Literally, you're serving two masters. You have two different projects. It's very difficult to serve both easily. Absolutely, and internally we have a separate team literally you're serving two masters. You have two different projects. It's very difficult to serve both easily. Absolutely. And like internally, we have a separate team that works on the open source bits versus the people working on the closed source cloud product. Right.

Actually, the benefits of the open source, and it seemed like the benefit of the open source was obvious, but they're different because they're separate. That's what it seemed like. I was going to ask you about that because it seems like with your cloud too that you mentioned, you can obviously push forward, but it's downstream, the open source is downstream.

And it seems like maybe just disconnected basically. Yeah, it's a bit disconnected. Whereas with this new model, again, my goal is we offer it as a cloud product first. We're not doing that yet. But then later we'll offer it as an on-premise product. But the idea there is that people who adopt IOX and deploy a bunch of servers and stuff like that, if they come to us and they want the on-premise product, it's a product that

they add in addition to the open source software they're already running. They continue to do that. It's very, very different than our old InfluxDB 1.x enterprise model, where our enterprise product is a replacement for the open source InfluxDB. I think that's a heavier lift, and it's a bigger ask for users to replace their open source bits.

I think it's better if they're able to run the open source bits and continue to have that experience because one, it makes the contribution easier. It makes it easier for them to consider adopting a commercial product because at that point they're saying like, okay, I have this commercial product, but it's not like I'm still using the open source bits.

So I can still be sure that, you know, if the commercial relationship goes sour or I decide I don't want that functionality, it's still good, I can still continue to use the open source bits. There's definitely some interesting ramifications that I think I would love to see play out as you go about deploying that new idea. Am I understanding correctly, it's kind of like

the open source bits is like the core software offering and then the proprietary stuff is like a management controller or like a deployment type of a thing? Like it's all the things that surround it that you would be offering as a service perhaps, but this is as a licensable addition?

Yeah, that's a good way of thinking of it. It's basically all this code that we have to write to offer it as a service, right? a licensable addition? Yeah, that's a good way of thinking of it. It's basically all this code that we have to write to offer it as a service, right? Operations, backups, deploying new versions of it, management, all this kind of stuff. The other thing is we want to be able to offer that as an on-premise piece of software. Another way to think about this is

the open source thing represents the data plane, whereas our closed source product represents the control plane. But the way the two interact is the control plane interacts with the data plane through its public API. And that public API is open source. So literally, if somebody wanted to write an open source control plane for it or if they wanted to write their own competing software products they can do so and the license totally permits that yeah and the thing is like we don't have to worry about our open source bits competing with our commercial bits because the truth is like right there's like the the responsibilities of the two pieces of software are clearly delineated.

So it's like, there's no reason for people to put control plane bits into the main open source project. They would have to create a separate open source project to do it, which would make sense. Right. But at that point, you're kind of just deciding what is control plane and what is data plane. And that's kind of the same concept of like,

what goes in core and what goes in proprietary. Isn that's kind of the same concept of what goes in core and what goes in proprietary, isn't it? Like, what about backups? Well, it could go right into our core offering, but it's more of a control plane kind of a thing. So we'll put it over here. It seems like you still make those decisions. You just make them and the two pieces of software are further apart, perhaps. I view them as further apart. When I think of open core businesses, I think of businesses where the commercial product is a replacement for the open source product. This is not that, and it's designed specifically not to be that. Take DataStax, for instance. DataStax Enterprise is a replacement for Cassandra. And now DataStax is obviously offering it as a service called Astra. That's doing well. But again, like, that's an open core model.

Gotcha. So what about? I think a good example is, like, Google and Kubernetes, right? Like, Kubernetes, open source Kubernetes certainly doesn't represent the entirety of GCP and all the software that runs that. But obviously Google has a vested interest in driving Kubernetes forward, and GCP happens to be one of the best places to buy Kubernetes, to operate Kubernetes.

So what's your thoughts on the server-side public license and Elasticastics move? You obviously prefer this other way of going about it, but do you think this was smart by them, short-sighted? What's your take on that? So I don't think it's not the move I would make. And to be totally honest, though, to me, it's not really about a license choice. It's more about how they intend to drive innovation that drives commercial value.

And the truth is, I own stock in MongoDB, which is obviously SSPL licensed software, but I do not own stock in Elastic, nor would I buy stock in Elastic right now, yet I'm holding MongoDB, even though they're both SSPL. So from a pure mercenary investor perspective, I'm long Mongo, but I'm short Elastic, and it has nothing to do with the license. I think them changing the license is more a symptom of the fact that they're getting out innovated on their cloud offering. If they had a cloud offering that was demonstrably better than Amazon's Elastic service, they would continue to be able to drive revenue and drive people to it. If they're so upset because they feel like AWS is eating their lunch on the hosted offering, then they change their license like i mean ultimately like they had a choice which was they either write more

closed source code or they re-license their you know the they they continue to write code out in the open i'm putting air quotes around this uh but that code is under a different license they chose the different license path, which to me, I think, I mean, personally, I'm not a fan of source available licenses. I think they're a disservice to the community because then... Yeah, they're a disservice to the community

because then you can say like, oh, community members like saw your code or whatever. Like it just means that people can't start like competing projects with you without, you know, putting themselves at risk of being, you know, accused of taking your code or whatever. Right. Like I prefer open code is open, closed code is closed. And the thing that kind of annoys me about the whole Elastic AWS standoff

is both of them are trying to, you know, put forth this position that they have, you know, the moral high ground. They have moral superiority over the other one, right? Like Amazon saying like, oh, we're protectors of open source, so we're going to launch this fork or whatever. And the truth is like,

even when they did Open Distro, I called it a fork then, even though they said it's not a fork because it's just like, whatever, a build. It was always obvious like when they launched that, that fork is what it was ultimately going to become because Elastic was going to take the stance that Amazon's stealing from us, so we're going to take the stance that amazon's stealing

from us so we're going to change the license of more and more of our code which is then going to give amazon no choice but to fork right right so amazon's claim they they have the moral high ground it's not true like they just they're just doing what's best for their customers and their shareholders right they're trying to optimize shareholder value. And obviously, all their customers are saying, host Elastic for us. And then Elastic is trying to say, oh, we're doing this to protect ourselves from Amazon because they're stealing from us. I mean, the truth is there are tons of hosting companies that have been hosting Elastic for a long time. And if you look at where Elastic makes its money, it's probably mostly from log search. How many log search companies are built on top of Elastic?

And they just opened that up, right? Like, so Elastic is just upset because Amazon out-competed them on the hosting front. Whereas like other hosting providers like Compose and Avon and stuff like that didn't really make a dent in Elastic's top line, right? So their claim like, oh, we have to do this. Like, no, you don't. You could have kept the code Apache B2 and you could have like written more and more code in your service offering that's closed source and kept the two separate, right? And this is actually one of the things that I agree with Amazon about where they said the reason they created the open distro was because Elastic was polluting the open source repo with code under different licenses, right under the Elastic license and stuff like that.

And what they've done now is they've gone all in on that strategy. So basically, they want all the benefits of being an open source company, free marketing, free adoption, getting other people to talk about it, use it, whatever. But they don't want to pay the price. The price of being really open source is that you're giving software away for free. Yes. Being permissive. You're being permissive. But that also means that anybody can take your software and compete with you,

which you have to be okay with. Like any, any re anything that you can really call a platform is only a platform. If the total economic activity of it outstrips that of any single vendor, right? So if you claim your platform, but basically you're getting all the money from it. No, you're not like you're a monopoly, as said in your tweets right this comes back to something you were saying which in your stance for not 2.0 in terms of influx what you're doing but the next version i think you called it iox this maybe version 3 i'm not sure what you call it but you said by design it's permissive and you just you've designed your architecture in terms of commercial offering to expect other competitors. Whereas it seems like Elastic, based on what you say and others have said and even kind of what they're depicting, is that they're upset that Amazon is eating their lunch and it's not by design. Their model is not by design to be competed with.

Right, exactly. Like their hope was that they would get this massively popular project, which it is, Elastica's top 10 database project, right? Like used the world over, but then they want like the classic strategy is like you spend a bunch of money to get optimized growth.

And then once you have scale and a monopoly, you want to start collecting monopoly rents, right? So now Elastic can't collect monopoly rents because other people are hosting Elastic. So they're trying to change the model so they can do that. But the problem is like, then you're a different sort of business entirely, right? Like it's fine to be a closed source database company. There's Fauna Fauna which is new Firebase is closed source each of the cloud providers has a handful of closed source databases so that's a totally fine thing to do

but to try and say oh we're open source and then change it it's kind of ridiculous Will Paul, fascinating stuff thanks for sharing your take with us definitely want to come and have you back once you've rolled out this new, what do you call it, complementary model.

You have some real world results to report back how it's going, if it's serving the needs of you and your users and the open source community the way that you hope it will. We would love to have you back on the show. Yeah, I think that's just one closing thought on that really quick, which you reminded me of, which is like, I think for people to think about it can open permissive open source licensing survive in infrastructure software. I totally think it can,

but I think the people who are producing it have to think ahead of time about how they commercialize it over the long run. And for us with Iox, I've already defined what success looks like is tons of competitors, literally cloud providers adopting the software and competing with us. So what that, which isn't going to happen for years, best case scenario, right? If it happens at all. But what that means is we're developing a commercial product side by side with the open product right now so that if cloud providers decide they want to get in on the game three years from now we've already had plenty of time to actually build a product to you know compete stay tuned for results as

they come out thanks paul we really appreciate you coming on the show. All right. Thanks, guys. Next, we're talking with Vicky Brasore. Vicky has been in free and open source software for 30 years now, and she's been working with startups and enterprises doing open source and free software business strategy for quite a while. We use Vicky's post titled Elasticsearch and Kibana are now business risks as a reference on this situation. We even quoted her post a few times in our conversation with Heather Meeker. So naturally, we had to talk with her. Here we go. All right.

So we're here with Vicky Brasseur. And Vicky, share with us, first of all, your position in the open source world. What's your angle at the conversation that we're having? Where are you coming from? I do corporate strategy around free and open source software. So I work with startups and enterprises and various organizations to help them be more successful by contributing, releasing, and just generally becoming a good citizen in free and open source software communities in a way that's both good for their bottom line and for the communities. Okay. And you've been doing this for a while? Yeah, I have. I've been in free and open source software for over 30 years,

and I've been doing this specific thing for quite a while now. Awesome. Well, we're glad we got you on the show then. So you wrote a piece called Elasticsearch and Kibana are now business risks, and I want you to lay out the case for that headline. Do you want to share that with our audience, just the brief synopsis of why you believe that's the case with this service-side public license? Well, I mean, SSPL, I'm going to leave to the lawyers. This is a legal matter, but it is not an open source license. It is, however, being portrayed as open, which everybody is going to interpret as open source, because that's just the way we speak about things. So I

think that in and of itself is kind of deceptive, and that's a problem. But the bigger problem is that this is a license change. And if you are going to use something, you are agreeing to that license. If you upgrade Elasticsearch or Kibana to, I believe it was 7.11, if I recall. But if you upgrade, you are, tacitly or otherwise, you are agreeing to this new license, SSPL or elastic license, it doesn't matter. You're agreeing to that and you're taking on new obligations for your company, for your organization. Are you aware of that? Do you know what you're taking on? Do you know the potential risks you might have? Or maybe there are benefits? I don't know. But this is not something that you as a company can afford to ignore

because it can have huge ramifications to your code base. I see. So the side swipe is a big problem. The fact that so many people might upgrade and unbeknownst to them their agreement with the software that they're running and the companies involved has changed. Is there no transparency to that change? Is it not something that people are aware of? Or how does it play out? The only transparency really is going to be that blog post,

or I guess there's like two blog posts now with Elastic finger wagging at Amazon and also screwing over their entire community and ecosystem. But hey, that's their strategic decision to make. They seem to think that was the right move for them. More power to them. Yeah, that's really the only warning. You're otherwise not going to know.

As far as I know, I haven't obviously looked at the code, but it doesn't make any sense that there be some sort of a new click through on Elasticsearch and Kibana, for instance, as you're installing them on your server, how are you going to confirm that? Yes, I have seen that there is a new license. And yes, I agree with this new license. Nobody does that. Not for open source software, and especially not on the server side. So it's very likely people are going to upgrade and tacitly agree to this, whether they know it or not. Or maybe they know about this new license and they decide not to upgrade at all. Well, now you're not getting security updates to this software, to Elasticsearch, to Kibana.

That's another potential risk to your company. Maybe you're using these things for free. And a great deal of people build a lot of cool stuff on top of the ELK stack. There's a reason why there's an acronym that we all know, the ELK stack. It is that popular. So a lot of people are building on this and they might be building on the free version. Well, that free version is not going to get relicensed and you're going to be screwed. But if you are building a company on top of this open source software and your company relies upon it and you're not already paying for some sort of support, either from Elastic or someone else, you're also putting your company

at risk in that way. So there's a lot of really important strategic things that people need to be considering when they are selecting open source software. And you need to remain aware of your entire free and open source software supply chain because as we are seeing right here, it can shift out from under you. You can have license changes. You can have security problems. You can have maintainers who just, you know, peace out and they go away and suddenly are using something that's completely unmaintained. So there's a lot of risk there for a company.

And most companies I've worked with are completely unaware of this. And it's potentially a disaster waiting to happen. I mean, as we all know, this is what happened with, oh, that credit reporting thing starts with an E. Equifax. Equifax, thank you. I've been saying Elastic so often, that's all I can think of. That's the only E in your brain. We're here for you.

Exactly. Thank you, guys. Equifax was not paying attention to their open source software supply chain. They had a piece of software in there, I believe it may have been Apache Struts or something like that, that had been upgraded to fix a security hole, but they hadn't bothered to upgrade it internally because they weren't paying that much attention. Then they got compromised and billions of people

had their private information stolen. So if you're not paying attention to stuff like this, not only Elastic, but the larger picture, you are just one bad day away from being the next Equifax. Do you want to do that? Is there a right way that Elastic could have done this in terms of just forget the decision, the SSPL, but let's say I just want to change my license. Do you have to start a new project with a new license? Is there best practices for changing a license that doesn't sweep sweep out the rug from people potentially um for an open source project there there's obviously many different ways you can do it and elastic has their perspective which is going to come from a very you know corporate perspective

we're looking to make money um and then the community will be coming from a different perspective so it you can have different approaches but the one thing everyone should always do is be communicating with their community and their ecosystem. This caught everyone by surprise. That shows that Elastic is not respecting the community and the people who have been contributing and who rely on this software. So they have essentially looked at their ecosystem and said, yeah, we don't care. We don't care what you're doing because all we want to do is screw over Amazon and collateral damage be damned. So they should have communicated. They should have told people this is going to be coming. Maybe they should have done it, for instance, at version 8.0 rather than version

from 7.10 to 7.11. Yeah, go to a major version. Maybe that would have been smarter. Maybe cut a major version right there. Just do that. Maybe you could have forked it internally and start developing internally and then leave the open source project alone

for other people to build upon. And you can even, you know, push stuff upstream and pull stuff downstream. You can still benefit from that while having your proprietary internally developed software. You can still do that. I mean, there's lots of different options they could have done. But the one thing they should have done and did not it was communicate with their ecosystem with their community they popped this on everyone and it was kind of rude they violated the trust of their community and that you can't really get that back at this point so you kind of screwed the trust of your community and you've besmirched

your brand which is going to be incredibly difficult to fix. It's a somewhat to Elastic's credit, and maybe I'm wrong by even saying this, but it seems like they've gone through a lot. When Shea had mentioned, the CTO of Elastic mentioned the litigation and the behind-the-scenes discussions, I think from the outside it might be easy to say screwed over, but the nuance there, I think, is they've gone through a lot. And maybe they're in some ways quite wrong and reactionary.

But I'd say in some ways, at least depicted by these tweets and this post, maybe they went about it wrong. But their intention was to try to fix this problem, which is very difficult to fix because our permissive license does allow this competition. And maybe from a business standpoint, they've sort of hit their lengths with being able to take that in quotes, their quotes, at least abuse from Amazon. And they're just trying to tread water to some degree with the scenario. I know that this is a podcast and so people can't see me, but picture me rolling my eyes right now. Okay. So the trademark thing aside, that's a different matter.

That lawsuit for the trademark is a separate issue. If they are relicensing as a reaction to that, then it's essentially them stamping their little princess foot, taking their ball and going home. And it's a childish reaction to a trademark infringement lawsuit, which I do think that they are, I mean, they were totally justified in that lawsuit for their trademark infringement against Amazon. I have absolutely no problem with that. I do think that Amazon was rolling the dice on that one. And they lost. And I think they will lose in that particular trademark thing.

But I am not a lawyer. So that's just my- You're not going to get legal advice. Yeah. That's just your take. So, but the relicensing, you know, if they screwed up at the very beginning by not understanding what a permissive license allows and what that is, they screwed that up. They put it out there under a permissive Apache 2 license without thinking somebody can now build a better product offering on top of this very easily. And if they're building a better product offering than we are, I'm sorry, folks, we live in a capitalistic system. That's just the way these things go. It's your fault for releasing your intellectual property under that sort of license and not understanding

what it's going to mean. And if you did understand, not taking enough measures to make sure that even if that does happen, you can still be successful. And frankly, if you look at their numbers and their financials, they are doing quite well. So what are they looking to do? Are they going to looking to grab all these people who are using the Amazon ecosystem and move them over to Elasticsearch and to Elastic? I don't think that's going to happen from a market perspective. So it's very difficult to see strategically why they thought this might have been a good move to just give their entire ecosystem the finger while trying to take a shot at Amazon. It just, it kind of seems, I don't know, amateurish.

And I would have expected better of a company that's been around for this long. So let's say I was a happy Elasticsearch user a month ago. And here I am today, and I'm like, Vicki, what do I do? They changed the license on me. I don't know what to do. What do you say to that? Go to the Amazon fork? I will say, I don't know.

It depends. Of course, I have been known to do a fair bit of consulting. And so any consultant who isn't starting out with it depends is, you know, trying to sell you something. Right. So it totally depends. What are your needs? How much do you rely on that Elasticsearch or on that Kibana? We have to remember there are two really big projects here that have been re-licensed. It's not just elastic search. So what is the strategic value and the architectural

value of that piece of software to your product, to your company? Look at that first. What is the niche it is filling? And then will anything else fill it? And it could be that as you evaluate this and you look at it, it makes sense to just pay Elastic for their software. Fine. That is a valid choice. And I support you doing that. I want your company to be successful. But you might also find that there are other alternatives. You might, there are a couple of forks now. There's, as we all know, the thing that kicked all this off, which is Amazon's open distribution for Elasticsearch. From the last time Elasticsearch did something kind of goofy in their open source world.

And then they have their new totally open distribution that Amazon just forked. And I think there's a third one, which is from loves.io, something like that. There's at least one other version out there. There may be others. And maybe you don't need Elasticsearch at all. Maybe you just need Lucene. If you're using Kibana, yeah, exactly. Maybe Grafana would be better for you. I don't know. It depends upon your needs. Don't go doing something just because it's what everyone else is doing. Look at your needs, your company, your architecture, your budget, your staffing. Who knows what software?

Do you have to ramp up on something new? There's lots of variables in there. And so I can't give a one size fits all answer. I was hoping I could just ask you once and the whole community could just listen to you. Let's multicast the solution. Oh, no, there is no single solution to any of this sort of stuff because every one of these companies is going to be different if they were all the same then we wouldn't need them all right we we'd have one market one company boom you're done but we don't have one license one license gosh wouldn't that be oh my, that would be so easy that would be so nice

We wouldn't need a consultant at that point Well, yeah, but I do corporate strategy it's not simply about licensing it's about so much more than that that's just a tiny sliver Well, Vicki, we want to respect your time is there anything else that you want to share that we didn't ask you?

Any questions that you just want to put this out there that we haven't asked you a question to, at least? No, not really I think you've covered pretty much the highlights of the stuff and then it'll be interesting to see what others have to say um i don't typically listen to podcasts but maybe i'll actually listen to this one there we go well you might hear me thank you at least once before i thank you right now for your time but uh thank you really for your time and for this blog post that you shared it was very helpful for us to sort of get a different perspective on these concerns around open source. Quoted a couple of things you'd mentioned in your blog post in a conversation with Heather Meeker, which is a part of the show, too. But thank you for your post. And also today, thank you for your time. We appreciate it.

Absolutely. Thanks, gang. last up on this epic show is marcus stinkvist who self-describes as an everyday web developer from sweden let's do this please tell us who you are and your vantage point on the software world yeah well i'm just a normal everyday web developer from sweden My name is Marcus. So I work for a small company no one has heard of yet. Yet. There you go. Yeah, exactly. How did you first hear about the news of Elastic's relicensing? Just curious, like, where do you get your info? Yeah, well, I read the article from Elastic on Hacker News. So I saw them posting like, this is not okay or something in those lines. Awesome.

Well, we're gathering perspectives from all over the community. So it's awesome to have just a regular, everyday web developer here on the show. So welcome. And yeah, what do you think? What are your thoughts on the whole situation? There's lots of nuance, lots of ins, lots of outs.

Yeah, exactly, exactly. Well, I read a lot of comments and i read the amazon article as well when they posted about like forking the repo after they re-licensed elastic and i i really don't even use elastic or amazon web services that much but i i think i care a lot about open source in general. So I'm with you. I don't use AWS. I don't use Elastic. I also care a lot about open source.

What is it about open source that you like or that you care about and are trying to preserve or be a part of? That's a good question. I think it's a matter of fact that I can use stuff for free and share it with colleagues and people all around the world without any restrictions.

No one can forbid me from using stuff which I want to use. So when you first heard about the relicense to the SSPL, what was your hot take? What was your emotional reaction? Were you indifferent? Were you mad at Elastic? Did it feel like it's no longer open source? Or do you still think it's still in the spirit of open source?

Well, I think I'm actually very much on the Elastic side for me. I saw a lot of comments on Hacking News that were like, oh, Amazon is all in their rights and yada yada. But they have actually done the same with MongoDB like two years ago, I guess. Right. Where they pushed them to basically re-license because they simply don't want to pay,

I guess, their fees. I think Amazon could be a bit more friendly towards those open source companies, because right now when they use their products for free, and maybe they hurt the possibilities of future open source companies going forward. So if you were an Elastic user, an Elasticsearch user... Yeah, I have been in the past. You have been.

But if you were today, like when you read the relicense, you would have been pro-Elastic. This would not have concerned you or offended you or changed the way you looked at Elasticsearch. Well, I think it's sad that they have to do it that they have to re-license that they feel like they need to uh and that's that's what makes me think that their move is kind of okay anyway because i would still support them and i would rather use them than the fork created by amazon yeah so the fork still exists under the the new fork which is created by Amazon. So the fork still exists under the new fork,

which is created by Amazon and trying to carry on from that point forward. It still exists under the previous license, but you would continue with Elastic versus the Elasticsearch and Kibana forks that are run by AWS now. Exactly. And that's simply because I believe in their vision

or I believe in their product. And I think Amazon is going to have a hard time keeping up or maybe they won't. I'm not sure. Time will tell on that. Yeah, time will tell, of course. But the same goes with MongoDB and their DocumentDB, I guess. I still think MongoDB is a superior choice

just because it's their project and their vision. So you're not an open source purist then? Not at all. Not at all. More pragmatic. More about free and open and available. Have you thought about any of the other licenses like the source available licenses?

Are you cool with that? And these other things like business source licensing. Surely these are things that you've read about being in the open source world. Are these things that you're also just like, whatever you want to license your code as, if I can use it for free and contribute back somehow, it's cool?

Yeah, I think it's cool. Every license is their own choice. If you want to license your work in a certain way, it's your choice. And if you want to share your work with others, that's just a positive thing. And I feel in this case, like Amazon is hurting the possibility to do that. Awesome. Any other thoughts? No, I think people that are on Amazon's side should maybe read the article from Frederick Lardone,

or something like that. Okay. Which is on TechCrunch called AVS gives open source to middle finger. I think that's an article that sums up my views pretty well. Awesome. Hand that off to me and

we'll include it in the show notes for everybody. Appreciate you hopping on and sharing your opinion with us. Yeah, thank you. Alright, that was an epic episode. Thank you so much for tuning in. If you haven't heard yet, we have a membership. It's called ChangeLog++ because, hey, why not increment things? It is better, as they say. You can subscribe at ChangeLog.com slash plus plus. Get closer to the metal, make the ads disappear and, of course, support all of our podcasts.

Again, ChangeLog.com slash plus plus. And of course, huge thanks to our partners, Linode, Fastly, and LaunchDarkly. Also, thanks to Breakmaster Cylinder for making all of our awesome beats. And of course, thanks to you for listening. We appreciate your attention. We appreciate you listening. And one more step you could take

is to join the community. changelog.com slash community. It's free to join. Come hang with us in Slack. Call this place your home. changelog.com slash community. It's free to join. Come hang with us in Slack. Call this place your home. changelog.com slash community. That's it for this week. We'll see you next week. Game on.