In early July, 2019, I sat down with Daniel Meyer, Camunda CTO and Zeebe Committer #0, to talk about the new Zeebe Community License. This is the transcript of that conversation.
Josh Wulf: We have a change to the licensing for Zeebe – probably, people are going to be interested to know more about that. I know you’ve done a lot of work on it – you’ve been speaking with British lawyers most recently about it. Maybe you can give a bit of background on the thinking behind that.
Daniel Meyer: Right, of course – happy to. And let’s maybe start by just reflecting on the tremendous journey that open source had over the last twenty years plus.
So, I think open source has really changed the world. It has changed how we think about building software, how we think about collaborating, how we think about building things together. It brings together people from all around the world to work on common projects that excite them, and it’s just amazing what the community has been able to achieve. So that’s definitely one angle to it. And when I think about it more on a personal level, that’s what – after all these years – still gets me very, very excited about open source. So, that’s one thing that is just amazing.
Then, what’s also amazing, I think, is that over the last 10-15 years, open source has also proven to be a viable base for business models. So there are very successful companies out there who have been driving their open source projects with the community, but they’ve been able to be able to be successful as companies. Look at companies like Elastic, Confluent, MongoDB – there’s many of them – Red Hat. And they’ve been able to keep open source alive, contribute massively to the success of open source, investing into these communities, but at the same time they were able to monetize sufficiently on those open source projects so that they were able to build great companies, great businesses.
And here at Camunda, we’ve been doing that as well. We have our Camunda BPM open source project out there, and then we’re able to build a commercial offering on top of that, that we then sell to Enterprise customers, and that has made us successful as a company. And it contributes back to the community in the sense that this finances the community effort. So that’s where we are at the moment.
Josh: That’s a question I wanted to ask you actually – why open source? Why did Camunda start as open source, and why did you stay open source?
Daniel: I think it’s related to the fact that our vision was always to have a developer-facing technology that would do workflow. And when you think back – when we launched in 2012, 2013 – back in those days the BPM space was occupied by players like Appian and others who were very much pushing the “low-code” philosophy. That was about “thanks to BPM, as a business person, as a manager, I can do my own processes and I don’t need IT“. And that’s something that we don’t believe in. We said: “Look, there’s a large class of problems that need developers.” If I’m a company and I want to innovate the core of my business, then I need to be in control of the software that gets built to do that. You know, “Software is eating the world”. We see digital transformation, digital disruption – Netflix are not going to build their streaming pipelines as “low-code”, right? And our vision was always not about “thanks to BPM, business people don’t need developers anymore“, it was always about “thanks to BPM, business people can work with developers very, very effectively.”
And, now, where does open source come in to that picture? Well, if you build a horizontal technology for developers, then you want to make it open. You want to make it easy to understand, you want to give people opportunities to go into the code and change it, customize it. You want to make it very easy to try it out, and you want to create a community around it – of people who build extensions, who contribute to it by integrating it with the broader technology ecosystem. And that is only possible with open source.
So that’s more of an opportunistic reason. Then, I think the other reason is just that many people here, including Jakob – the CEO – myself, of course, and Bernd, the other founder of Camunda – we just believe in it. And we think this is just a better way of building products. That’s the second, more personal – or maybe emotional – reason behind it.
Josh: It’s pretty core to your DNA then.
Daniel: Right, and initially you asked “so why now this Zeebe license?“. So, as I said before, we believe that open source has been very successful in changing how software was built. We believe that open source is pivotal to building developer-facing technologies like Zeebe – but at the same time, at the moment, the industry is at a pivotal point – and that is related to SaaS and Cloud.
When we look at what is happening at the moment, we see that there are successful open source products out there. I named a few of them – Elastic, MongoDB, others… And these companies are currently faced with the challenge that there are cloud providers out there – predominantly AWS – who leverage their position of strength in the market to monetize on those open source projects in a way that they make it very hard for the original stewards of these open source communities to compete with them.
Though Amazon provides an Elastic Search service, Amazon provides a MongoDB service, Amazon provides a Kafka service – and they are similar examples to Zeebe – they haven’t necessarily invested in creating these technologies. And they are also not particularly investing in moving these technologies forward on the open source side. But at the same time, they are in a very strong position to monetize on those.
And when you look at what has happened over the last year, all these companies over the last year – Mongo, Elastic, Confluent – they’ve changed the licenses of their technologies to protect against this. And that’s reasonable, because we need to secure the ability of the stewards of these open source communities to invest into it. And that is only possible if there is a path to monetization in the cloud.
And now that we’re launching Zeebe – which is specifically built for the cloud: in a way we’ve reinvented the workflow engine so that it can run in the cloud, and it can be offered as a SaaS service – we want to make sure that Zeebe is protected from AWS offering it as a cloud service. We will offer it as a cloud service. That’s where we are, and that’s the background for this license change.
We’re doing it now, up-front. These other companies that I mentioned – Elastic, Confluent – for those it was later in the game…
Josh: They had to do it retroactively…
Daniel: They had to do it retroactively, and we want to be honest about this. We want to now, out of the door, tell the community: “Look, this is our strategy behind this product and behind this open source community.” And we hope that people are able to see that this is a necessary step, and that in the broader context, that either as an open source industry that we’re able to figure this out in the future, or I see a very complicated future for open source down the road if we’re not able to figure this out. Because AWS is not going to slow down. And we need to figure this out because otherwise, maybe the way we know open source is over. And that, of course, is something that nobody wants.
Josh: So this license is designed to stop AWS offering Zeebe as a SaaS offering.
Daniel: Yes.
Josh: And does it have impact on other use cases? Like, if I’m a business and I want to build my thing on Zeebe and expose some part of it to my clients. Maybe I’m a Real Estate business, and then there are franchisees who use my system. Does that impact me if I’m offering that to them? Say, as some kind of Real Estate SaaS that runs on Zeebe.
Daniel: Not at all. So that’s something that we particularly looked at, to make sure that we don’t have any ambiguity around that in the license.
The license works like this – it says: “This gives you all the rights that you would have under the Apache license…”
Josh: Unless you’re Amazon!
Daniel: (laughs) It’s not, of course, formulated that way.
So, there is one thing that you cannot do: you cannot offer a commercial workflow service based on it.
And then we take care to define commercial workflow service as something that allows users to develop custom workflows on top of the service. And then custom workflows is defined as BPMN workflows where a third-party can define the workflow, but also can – without restrictions – also implement the steps that are executed by the workflow.
And that then restricts it to situations where someone exposes Zeebe itself as a service; but it doesn’t limit situations where somebody builds a product on top of Zeebe, where maybe the workflow is a layer of configurability to the system. Where from a pre-defined set of services a user can select and…
Josh: Wire them together…
Daniel: Wire them together. So all of that is permitted, but the only thing that we want to prevent is the big cloud providers – of course, predominantly AWS – just offering this as a service without investing into the open source project, and without changing things that would contribute to Zeebe.
Josh: Why didn’t you make the license just straight-up that: “Anyone can do anything they want with this, but Amazon are not allowed to offer it as SaaS offering.“?
Daniel: It’s not as simple as that. You cannot just pick one and exclude that. So it has to be a description of the scenario that we want to prevent.
Josh: It’s interesting though, because at the heart of it, it is basically a competitive limitation – which is in a sense almost antithetical to the spirit of open source; which was – well, here we are talking about Free Software from the Richard Stallman perspective – that anyone can do anything they want with it, as long as they contribute it back. And the AGPL was designed for that – for SaaS offerings. But that obviously wasn’t sufficient for this use case?
Daniel: Right, so there are set of complexities around AGPL that made it not ideal. On the one hand, it prevents more than we want to prevent. You know: unless you’re offering Zeebe as a SaaS service, we want to be more liberal than the AGPL would be. So basically what we wanted to have is Apache, but just excluding this SaaS thing. So with AGPL you have a stronger burden on users of the system, because…
Josh: …the Real Estate SaaS people would have to release their source code…
Daniel: Correct. And that’s not what we want, right? We want to be more liberal than that. The AGPL has GPL’s…
Josh: Virality…
Daniel: Exactly. And that’s not what we wanted to have, so we basically wanted to have Apache like we do with Camunda BPM, but excluding this one use case that we wanted to exclude. And AGPL was both too much – in terms of the reciprocal clause in it that we didn’t want to have – and at the same time, it’s currently unclear whether it then actually prevents the SaaS thing that we wanted to prevent.
Josh: I don’t think it does – I think it just means that they have to…
Daniel: Contribute back – right.
Josh: They are not going to contribute their cloud though…
Daniel: Exactly. So (the AGPL) was both too much for regular users, and not restrictive enough for the thing we wanted to prevent. And that’s why we now stepped back from the AGPL, and go with this custom license.
Josh: Everybody seems to be going with a custom license now. You know: Mongo, Elastic, Confluent – they’ve got their own community licenses, specific to their use case. Now, is this license another license specific to this use case, or is it: “Hey, we’re going to solve this category for everyone“? Like, the next people who come along with the same problem: here, re-use this license?
Daniel: It’s currently unclear. There is no one-size solution to this at the moment. What you just said is that all these companies are…
Josh: …creating a plethora of licenses, which is a nightmare for legal departments…
Daniel: Right. Which can be a challenge – but at the moment there’s just no unification around it. Now, there are certain initiatives around coming up with a commonly accepted license that gives these properties that we’re looking for. And we’re looking into contributing to these initiatives, and once there is an industry-wide, broadly accepted solution to this, then with Zeebe we can adopt that. Because the license we put in place does not limit any other thing than the SaaS thing. It’s not like: “oh, while we’re at it, we’re putting in more restrictions” and we would like to then put those into a standardization effort for the industry. No, it’s only this one thing that we are trying to prevent.
Josh: So it sounds broadly applicable in that sense.
Daniel: In a way. So let’s see what comes out of that.
Josh: It sounds like that, then, this is an Apache license with the SaaS clause.
Daniel: Yeah, we should be very careful about saying…. It’s not the Apache license. It’s the Zeebe license; but that license gives you everything that Apache gives you…
Josh: Unless you’re Amazon…
Daniel: Exactly. Restricting on this one thing. So, of course, it’s not the Apache license. And also what that means is – you know, we want to be honest about this, so technically, according to the definition of the OSI, Zeebe is not open source.
We then prefer the term source available – so source code is available, you can do everything with the source code that you like to do; but there is one restriction in there – which is you cannot offer a commercial workflow service. And technically that means that it is not open source by the OSI’s standards…
Josh: But it is… yeah, okay, not by the OSI’s standards. It is open source, but it’s not Free Software for sure.
Daniel: Right. Yeah, it’s not unrestricted, Free software.
Josh: Yeah, it’s encumbered by this anti-compete clause.
Daniel: Yep. You cannot offer a commercial workflow service.
Josh: …if you are Amazon. But for most people that’s not going to be a big deal, because they want to build something with it. They’re free to modify the source, they’re free to use their own modified versions, can they resell a modified version?
Daniel: Yes, of course. Yeah.
Josh: So they could actually start a consulting company, and sell this thing, and offer consulting services around it.
Daniel: Yes, and that would be, maybe even to a certain degree, competing with us – but we’re fine with that, because that is the traditional way. What is new is Saas/Cloud providers…
Josh: Make no changes or modificiations….
Daniel: Leveraging
Josh: Add no value…
Daniel: Right.
Josh: Stick it in the cloud and sell millions of them…
Daniel: Right, and they’re using their market position to an advantage that should probably be regulated to a certain degree, but short of that regulation to exist, we need to see how we can prevent it with something like this…
Josh: Licensing.
Daniel: Right.
Josh: It reminds me of the whole Microsoft Windows / Internet Explorer thing, right?
Daniel: You know, in a way it is. Microsoft leveraged their advantage of having the operating system in place and then fighting back Netscape by providing it out of the box….
Josh: …for free…
Daniel: Right. And then, at least in Europe, the EU stepped in and said: “You cannot do that“. And maybe something like that will happen in the future, but until it does, we need things like this.
Josh: So, that’s good to know about the license. And what is the license called?
Daniel: The Zeebe Community License.
The episode continues with discussion about Zeebe and Microservices and Workflow in the cloud, but that’s the portion about the licensing change. For more discussion about the license, hit up the licensing post in the Zeebe Forum.
