Follow-up on Switching Dgraph to a Liberal License - Dgraph Blog - #29
@mrjn How do you plan to address the concerns?
1 Like
I think the existing and potential community would appreciate (actually needs) a stance on your part (that would be better than closing the previous ticket which gave a really bad impression to me).
It doesn’t have to be something we like, but at least something we can count on.
- we are not going to change so stop ranting
- we are studying our different options and will respond formally as soon as we can (diplomatic no answer)
- how about license X?
- Let’s vote
- …
5 Likes
@mrjn and dgraph staff…
Is this something you are looking into addressing? Any comment that would say “No change” or “we’re looking into it”?
4 Likes
@mrjn @gus @dmai @Graphpinto @MichelDiz @paulftw @pawan @shanea @tzdybal @wisemonk
I was looking at the text of the license again.
The Software is provided to you …
Where is “Software” defined? What does that refer to specifically? Neither the license on your GitHub page, nor the Apache 2.0 license that you reference define “Software”.
Can you please clarify?
Also … the above questions about how this will or will not be addressed have still gone unanswered.
1 Like
I guess I left out the selected option:
- just ignore these people, they’ll go away.
1 Like
We don’t plan to change the Dgraph licensing in the near future. The current license is working for most of our users, and the community has reacted positively about the move away from AGPL.
You could have dual licensed. This would have achieved the goals set out in the license blog post:
The threat of duplicate commercial services and enterprise features built by others without paying anything back towards the development of the open source version.
If this were indeed true, an AGPL and alternative commercial license would achieve the goal. Those that don’t want to share IP would pay, those that are prepared to share IP would pay by “paying … back towards the development of the open source version”.
I understand the position you feel you find yourselves in, but you are going about it the wrong way.
What I find truly funny though is that you are using, for example, code that I have written but are not paying back. The code you use that I’ve written was not covered by your CLA.
@mrjn will elaborate more on AGPL in a later post.
This doesn’t seem right, so I double-checked the contributions you’ve made to any of our Dgraph projects, which is solely on the tutorial repository for https://tour.dgraph.io. Your PRs like #24 say you’ve signed the CLA.
Tutorial has not officially been given a license. It’s now licensed under Apache 2.0.
You vendor code. Some of that is mine.
If I were talking about PRs to your projects, I would have said so.
BTW I understand the CLA changed between then and now. However, the text of the previous CLA (if it is different) is not available.
Has the text of the CLA changed? If so, where is the previous text available?
Sorry for the delay in replying here. The last many weeks have been very busy, and I wanted to find some time to clarify the one point that I feel is most crucial. Why Commons Clause, why not AGPL?
Dgraph was under AGPL before. I had moved Dgraph from Apache 2.0 to AGPL, and have experience with the repercussions of AGPL first hand. So, I can elaborate.
The toxicity of AGPL can be judged by the fact that Google has outright banned AGPL. When criticizing our move to the Commons Clause, people online didn’t see the relation between a big giant banning AGPL and how it affects a small company like ours. We didn’t see this relation ourselves earlier, when moving to AGPL. But, it was quite an eye-opener for us.
Large companies look at each other to see what they could adopt. When Google outright bans a license, other big companies do the same thing. While I can’t prove this definitively with a link like Google’s above, but I can tell you that other big companies like Facebook, Apple, etc. follow suit, and also ban this license. What that means is that, no developer at these companies, can even bring an AGPL project in their code base.
The way open source adoption works is that, developers play with the open source project. Then, they’ll do a proof of concept. If that succeeds, they’ll put it on dev cluster for a bit. Then, finally when they come close to production, they’ll reach out to the open source team developing the product to ask for help, potentially do a support contract. The sequence might change a bit, but the general idea remains, i.e. a few engineers would bring in the open source project internally and play with it, before deciding if they want to use it.
When you have an outright ban, developers can’t bring that project into their code base, period. No exploration happens, no evaluation happens. It’s rejected, solely on the basis of the license.
Ok. So, big companies can’t use it. What does that have to do with the rest of the world. A lot, actually. Decisions at large tech companies are closely followed by the entire tech world. When Google launches Go or Kubernetes; or writes a paper about Bigtable or Spanner, the rest of the world wants to use it. The need for K8s was there before too, but having a big giant put their full weight on it, has a immediate effect on the tech market. Similarly, when a big giant says “don’t use this license”, the ripple effects of that are pretty clear.
Time and again, I’ve been told by startups, small companies, medium companies and so on, that they could not play with Dgraph because of the AGPL. They saw the stance taken by big giants, and they didn’t want to touch this “toxic” license themselves.
Contrary to popular belief, the biggest reason for and benefit of running an open source project is not the code contributions. It’s the ease of adoption. And for us, AGPL had limited that severely.
It was clear to us that we needed to move away from AGPL. But at the same time, we still want to ensure that we can protect our business model to ensure that we, the company behind this project, can continue to thrive and work on the project. And when the project becomes popular, not get killed by a giant cloud provider, who sells our work without contributing anything back.
This leads me to Apache 2.0 modified by Commons Clause. For almost all the users of Dgraph, the Commons Clause has no impact – because they don’t plan to sell Dgraph. The license does not cause them to have to release their own proprietary code base. They can continue to build commercial applications on top of Dgraph – practically working with this license, like Apache 2.0. This license gives them more freedom in how they can use Dgraph than AGPL. They don’t need to worry about how they link to it, or what codebase it touches. They can use it freely, and build whatever they want to.
IMHO, Apache 2.0 modified with Commons Clause is way more liberal and friendly to open source companies than AGPL. Sure, it is not OSI approved, but it is also not outright banned by tech companies. With this license, we, the company behind Dgraph, can ensure that we can monetize, while our users, can rest easy that they won’t need to release their code just because they’re using Dgraph. And to me, those practical implications are very important.
1 Like
Thank you for the considered reply.
The issue rests with the loose framing of the Commons Clause. You say here that it is included to prevent selling Dgraph (presumably as a service in addition to as a software product). However, the text does not clearly enough restrict what the meaning of “sell” is. For example, it could prevent a consultant from installing Dgraph on a client’s infrastructure. In my situation it could prevent me installing it on my employer’s infrastructure as I would be copying the software onto their servers and be being paid for it.
You have said that you won’t do that in previous posts, but those are posts. This is a license. You may change your mind.
The reason we chose the Clause was to avoid getting ripped off by big companies. It is not in our interest to go after individuals who’re trying to use and propagate Dgraph.
Hi @mrjn, I understand your concern and decision. Thank you for taking the time to explain the thought process.
I do have one question though: if Google bans all software with Commons Clause, will that change Dgraph Labs’ decision? As an Ex-Googler, I don’t see how Commons Clause passes Google’s software license review process.
I am also concerned that savvy startups and open-source contributors will start moving away from Dgraph purely because of Commons Clause. This would be a shame because I think Dgraph has made some great decisions on the forefront (Go, GraphQL, Raft, gRPC) and has a lot of potential.
A few options to consider, for now or when Commons Clause starts to hinder the progress:
- You could specifically restrict the selling of Dgraph or derivative software as a cloud datastore/graph-database service.
- You could make the core parts of Dgraph truly open source (OSI-compliant) and make advanced features (enterprise security and auditing, performance tuning, etc.) covered by Commons Clause.
- You could revert to open source and lead the community to build the best graph database and cloud service there is. If you achieve that, I bet the worst case scenario would be a $100M+ acquisition by one of those “giant cloud provider”.
Just my two cents.
Thanks,
Zak
1 Like
Yes, I understand the rationale, but if they have a blanket ban on the AGPL, then you could (as suggested above) dual license with AGPL and some other license that they would then have to choose.
As it is, you say you won’t go after small people, but how can I know this to be true forever. I don’t. Maybe you don’t care whether I do or not. But as it stands I can’t use this.
Let’s take a reasonably realistic hypothetical. I am a bioinformatician who works at a University, I build tooling to work up an analytical pipeline dealing with generic bioinformatics problems using graph DBs (this is for example this) and that approach becomes successful. The work is published and gains some use throughout the bioinformatics world. Now the University takes on consulting using the workflow. But the workflow is built on Dgraph and that would probably constitute a substantial contribution to the value of the consulting product. This is the hazard of using the tool. If we were able to use AGPL, then (as ethical contributing members of the scientific community we would be happy to contribute everything back to the community), but under the current system, that is not possible. Our legal and risk would not accept the situation.
Another more general case is a data-analytical consultancy that makes use of Dgraph for their analysis pipelines. Again, the sale of the consultancy work depends on the use of the Apache License grants and the consultancy services are substantially valued by the use of Dgraph.
1 Like
If Google does indeed ban Commons Clause, we might also reject it. But, I don’t see that happening. The reason Google bans AGPL is because they have a lot of proprietary code base, which they can’t afford to release because it happens to touch something AGPL. In fact, I’d argue that if Linux Kernel wasn’t GPL, they’d have banned GPL for the same reason (as Chris Dibona said, “there’s no interesting software in AGPL”, which I understand as, “there’s a very interesting software in GPL, so we’ll deal with that, but no more.” Just my personal line of thinking – which hasn’t been verified by anyone at Google).
Commons Clause does not give any of those pains to any company, big or small. They can use it all they want, for any internal, or commercial products.
That’s not very different from what Commons Clause is trying to achieve.
@kortschak: I think both of your questions hinge around consultancy. If in these scenarios, the consulting is being done on the products built on top of Dgraph, that should be alright, and won’t be restricted by Commons Clause. The “substantial” clause in the license is a standard legalese representing a software which is almost equal to the licensed software (added a couple of apis on top of the DB). It does not mean a software which won’t substantially work without the licensed software (a dynamic website won’t work without a database).
However, if the consultancy comes down to consulting on the Dgraph software itself, that’s when the clause kicks in.
So this is my first of three hypotheticals. If I install software Dgraph on a clients server, that would be subject to the restriction, as would if I bring a copy of Dgraph that I had been using in private projects and installed that for work on my employer’s hardware as part of my work, having recognised that it would be helpful there.
I doubt the following:
I’d argue that if Linux Kernel wasn’t GPL, they’d have banned GPL for the same reason (as Chris Dibona said, “there’s no interesting software in AGPL”, which I understand as, “there’s a very interesting software in GPL, so we’ll deal with that, but no more.” Just my personal line of thinking – which hasn’t been verified by anyone at Google).
The GPL does not touch their service. Just as you claim regarding the Commons Clause (which I would dispute in that case), Google (and any other company) can use GPL licensed software internally as much as they want provided it does not get included in software product that they distribute. The likelihood of this happening with the kernel is infinitesimal, even without care.
If they were ever actually worried about this they would have taken Apple’s route and used a BSD for their underlying OS.