Switching Dgraph to a Liberal License - Dgraph Blog


(Manish R Jain) #1

Last year, we had switched Dgraph license to AGPLv3.0, considering reasons like the ability to monetize in a competitive environment. In particular,

The threat of duplicate commercial services and enterprise features built by others without paying anything back towards the development of the open source version.

This remains a credible threat; nothing has changed in that regard. What has changed is that we realized that due to our switch to AGPL, developers who were part of big companies became unable to use Dgraph, solely due to a licensing ban within their organizations. Big companies like Google have openly banned AGPL usage within the organization, and many other big companies do the same without necessarily advertising it. Dgraph was built for horizontal scalability, low latency, and high throughput to serve terabytes of data. This license disallowed those exact companies who could benefit the most from these features.

Graph DB field has become hot lately, with the emergence of Tiger Graph, Amazon Neptune and other new graph databases. Almost all of them are proprietary closed-source databases, which require companies to pay up for usage, with little ability to customize them to their needs. This direction is prohibitive to graph database adoption. We want to take a strong stand towards openness in the graph db world. So, we’re relicensing Dgraph under Apache v2.0 with a Commons Clause restriction.

This license allows full use of Dgraph under the liberal and popular Apache v2.0 terms, but restricts selling Dgraph itself. That means, you can build internal, external and commercial products on top of Dgraph and sell those, but just not directly sell Dgraph itself. We think this licensing supports open and free use of Dgraph, while still allowing us to maintin our rights over commercializing Dgraph. The full text of the clause can be seen here, and the frequently asked questions are addressed here.

We’re committed to keeping Dgraph open, so companies big and small can use this incredible technology that we’ve built, freely integrating it with their proprietary solutions as needed. Providing Dgraph with a liberal license allows for open innovation, which strongly benefits both the community and the core of Dgraph.

Nothing is set in stone, though. We’re very perceptive of the feedback from our growing community. We’re putting this license in place with the hope that this works for users and companies of all sizes. If, however, we fail in achieving that goal, we’ll consider alternatives. So, if this license does not work for you, please do talk to us.

Within the Dgraph team, we casually refer to Dgraph as the “Spanner of graph databases.” We’re building it to be a reliable, crash resistant, geographically distributed database, with no compromises when compared to leading NoSQL and NewSQL databases. Dgraph has become one of the most advanced graph databases in the world, and we’re hopeful that our licensing allows everyone to use the power of graphs to solve the incredible problems of the world.

Top image: Hubble Sees the Force Awakening in a Newborn Star


This is a companion discussion topic for the original entry at https://blog.dgraph.io/post/relicensing-dgraph/

(Cameron Batt) #2

Hey that’s great news!

Even though I am not using DGraph in a big organisation (I am a bootstrapped startup) the AGPL was still a little off putting, so for me this change is very welcomed.

I hope this licence works for you on the business side. As long as you have reasonable pricing I feel most people will choose to buy from you. I personally will anyway.

Speaking of pricing I cant wait for you to have a paid service as I really don’t like managing the DB myself. Do you have any ballparks for pricing currently? Or a timeline for this? Just FYI, I am kinda hoping your first pricing tier would be similar to Compose’s ScyllaDB or JanusGraph. They start at $100 -> $120 / Month for 5GB. I figure DGraph is similar to these two (graph and distributed), so that’s vaguely what I have in my head as a budget.


(Manish R Jain) #3

Glad to know you like this change. :heart:

We’re a bit overstretched building Dgraph’s core product and handling Dgraph’s growing community. So, we decided not to build Dgraph as a service ourselves for now. We’re going to collaborate with an external vendor to build and run that, on our behalf. There’s no ETA for that yet.


Timeline for hosted service
(Jim) #4

This is awesome! Much needed as AGPL was a non-starter for even looking at dgraph.


(Georg Greve) #5

Speaking as a person who was very excited to discover Dgraph half a year ago and is a huge fan of your work: Please revert this change and return to an Open Source license.

The Commons Clause is a horrible misnomer for a proprietary license that is more restrictive than even Microsoft licensing in some ways - and adds severe legal concerns for any user or contributor to Dgraph. I’ve outlined some of them in this thread: https://twitter.com/ggreve/status/1032520322170462208

The result of this change is that Dgraph is now proprietary, just like Tiger Graph or Amazon Neptune.

But the legal risk of adopting Dgraph >=1.0.5 is larger than that for Tiger Graph or Amazon Neptune.

Whatever problems you were experiencing with the AGPL, they are nothing in comparison to the damage the Commons Clause can do to Dgraph. Which would be a shame, because I am truly a great fan of your work, and Dgraph is an exciting piece of technology. You have done so many things right already. It would be a shame to see the choice of license force a fork of your project.

So if the AGPL was not right for you, which is possible, there are still a huge number of better options available. Even dual licensing - while the poor man’s choice of unimaginative business model - would be a better choice than this.

You are citing the difficulty of adoption by Google under AGPL as one of the reasons for changing the license above. I can pretty much guarantee you Google would not touch Dgraph under the Commons Clause and might even forbid its engineers to study it for concerns of Copyright tainting. If they were to look at Dgraph for themselves, they would likely ask you to rather provide them with a regular proprietary license.

Which is exactly the same they would have asked of you if you had kept Dgraph under AGPL.

I’d be happy to have a chat with you about the various options I have seen work over the years as I really want to see Dgraph succeed.


(armijn) #6

hello,

speaking as someone who actually has done open source license enforcement and is quite familiar with licensing (but I am not a lawyer, I just talk to many of them almost every day): this is not a good move and I would strongly recommend to revisit this relicensing decision. If you don’t want to, please don’t call it open source, or liberal, as it is the exact opposite.

I see that there is a CLA for Dgraph: https://cla-assistant.io/dgraph-io/pydgraph

but there are quite a few contributors outside of Dgraph according to:

and for some commits I can see “CLA signed” (or whatever), but definitely not for all commits (from non-Dgraph committers).

Did all contributors whose code still survived collectively agree to this license change? Because if there are copyright holders who did not agree, then you have a problem.


(Manish R Jain) #7

We have a policy that all contributors must sign our CLA before their PRs are accepted. So, everyone has signed them. The reason you don’t see them all, is because we made slight changes to the CLA, and they signed the older version of the CLA. And by default, the site only shows you the latest version, and not all the previous versions.


(Georg Greve) #8

We have a policy that all contributors must sign our CLA before their PRs are accepted. So, everyone has signed them. The reason you don’t see them all, is because we made slight changes to the CLA, and they signed the older version of the CLA. And by default, the site only shows you the latest version, and not all the previous versions.

Did the contributors realise that you would use their CLA to make Dgraph proprietary?

The Commons Clause is particularly insidious as by switching to it you are explicitly reserving the right to sue your contributors for using Dgraph professionally, or for using Dgraph knowledge they have gained while giving you their contributions:

The definition of “Sale” includes “consulting/ support services related to the Software”.

Can Copyright really forbid people to use their knowledge? Could this potentially mean your staff is no longer allowed to maintain your own systems running this solution?

And while its inventor calls it “an experiment that is significantly less organised than it seems” I don’t understand why you would voluntarily turn your community and business into the guineapig for his experiments, which mostly seem designed to create demand for his license compliance business. Because the most likely outcome of the Commons Clause is an increase in compliance violations and lawsuits.

Everything about the Commons Clause is as Orwellian, starting from its name, as it ends the Commons for projects that adopt it. It pretends to be a reaction to predatory behaviour, but its primary effect of applying it to Dgraph is one of turning Dgraph into a predator upon its community.

I’m seriously concerned for you Dgraph, because adopting the Commons Clause is begging to be forked and is likely the decision you may look back on in a year from now as the move that killed your business.


#9

From source: "For purposes of the foregoing, “Sell” means practicing any or all of the rights granted to you under the License to provide to third parties, for a fee or other consideration (including without limitation fees for hosting or consulting/ support services related to the Software), a product or service whose value derives, entirely or substantially, from the functionality of the Software. "

Based on this definition of the Common Clause, it seems that a SAAS using Dgraph would entitle Dgraph to remuneration. A SAAS using Dgraph as a database could be argued as using the product “substantially.”

Which means that this statement (source) would not hold true. “That means, you can build internal, external and commercial products on top of Dgraph and sell those, but just not directly sell Dgraph itself.”

You would have access to the code, be able to build on top, but not sell without Dgraph’s permission and compensation. In effect making the software proprietary.

Isn’t that correct? @mrjn
Clarifications would be nice here.


(Manish R Jain) #10

If your SaaS is selling Dgraph as a service, that would not be allowed as per the clause. But, if you’re using Dgraph to build your SaaS product (say Dgraph is being used for tracking and querying machine resources as an underlying storage layer), which is not selling Dgraph directly, that would be alright.


(Georg Greve) #11

If your SaaS is selling Dgraph as a service, that would not be allowed as per the clause. But, if you’re using Dgraph to build your SaaS product (say Dgraph is being used for tracking and querying machine resources as an underlying storage layer), which is not selling Dgraph directly, that would be alright.

So, in other words:

  1. Yes, Dgraph is now proprietary.

  2. If we consider your usage of Dgraph to be “alright” we will probably not enforce the license, though.

Given that the license is exceedingly vague on what is “alright” there is no legal certainty there will be no prosecution from Dgraph if you’re using the software for anything, really. It’s a case by case decision where Dgraph decides ad-hoc whether they feel they should get some of your revenue.


(armijn) #12

Thanks for clarifying.


(armijn) #13

What Georg said. Dgraph has become a very risky choice to build a product on.


#14

@mrjn I understand your intentions. However the language of the Common Clause has vague elements and casts a wider net than your intentions. The language makes me uncomfortable and unwilling to use Dgraph, even if Dgraph were the perfect solution for my needs. And I think it will drive developers away and you will get fewer contributors. Maybe you need to write your own clause, addressing exactly what you wish to save for yourself, as in Dgraph as a service, software in its entirety, database as a service, etc. and present permissible use cases, as in the example you mentioned, “Dgraph is being used for tracking and querying machine resources as an underlying storage layer” and others.

@georg.greve What do you think about Dgraph writing their own clause to exclude certain applications? And could Dgraph be forked now even under Common Clause to escape it?


(armijn) #15

Only code before the license change can be forked.


(Georg Greve) #16

Maybe you need to write your own clause, addressing exactly what you wish to save for yourself, as in Dgraph as a service, software in its entirety, database as a service, etc. and present permissible use cases, as in the example you mentioned, “Dgraph is being used for tracking and querying machine resources as an underlying storage layer” and others.

Open Source has become so successful because it allows universal usage and follow-on innovation without having to ask for permission. That creates a level playing field in which all participants can cooperate on equal footing and create commercial value.

In a way it is competition and cooperation in its purest form.

Adding any kind of usage restriction to an Open Source License is always a lot like asking for intervention from the state for your ailing economic cause. And once you’re hooked on the monopoly game, enough is never enough. The past 25 years have demonstrated time and again that companies going down this path almost never come back.

The background for this kind of “help me, big state, and protect my monopoly” is often a lack of understanding of Open Source business models, and failing to understand that choosing a license is not the same as developing a business model. Software license choice and business model are orthogonal questions, but laypeople often conflate and confuse them.

In this particular case it seems that the root of the Commons Clause is at Bain Capital Ventures, which has loudly complained about their own inability to build sustainable business models for Open Source.

Bain Capital Ventures has been lead investor at Fossa, as well as DGraph.

So the picture that emerges is unfortunately not pretty. It seems like FOSSA, which has a vested interest in more compliance violations and legal issues to create need for its services, has drafted the license that Bain Capital Ventures was trying to foist onto the Open Source Community in a hope to monopolise as much of the commons as possible.

From the looks of it, the founders of Dgraph have unfortunately not followed the “know your business model before you talk to VCs” mantra. So effectively we have to assume Bain Capital Ventures has taken over this show, and is pushing the Commons Clause on the Dgraph community via the management at Dgraph.

Because Dgraph has been using a CLA, that also means all contributions anyone ever made to Dgraph have now been monopolized by Bain Capital Ventures for Dgraph.

Using Dgraph under this license has become a bet on the question “How greedy do I think Bain Capital Ventures is going to be if my company or product starts making money?” Because depending on how central a role Dgraph plays in your product, they may decide to take none, some, or all of your revenue.


(Georg Greve) #17

@georg.greve What do you think about Dgraph writing their own clause to exclude certain applications?

It does not seem that Dgraph is actually behind this move. Also, this is a near impossibly slippery slope to manage. Everyone contributing to, or building on top of Dgraph would effectively put their own future and livelihood into the hands of Bain Capital Ventures.

Keep in mind the CLA gives them the power to change the license out from under you at any time if they decide your business has now become a problem for them. The true goal of Bain Capital Ventures appears to be to get people to generally accept “it is okay to put just a little restriction”. Then they can keep pushing the boundary on what is “just a little” - effectively applying a “salami tactics” with your business as their salami.

Only a real, officially approved Open Source license provides the community and businesses with sufficient legal security for building things on top of Dgraph. Which is what Dgraph should apply, and legally guarantee to its contributors as part of the CLA - similar to what the “Fiduciary License Agreement” of FSFE has been doing for a long time now.

Which is why I was asking @mrjn to switch back to an actual liberal license that is approved by FSF & OSI and simultaneously offered my input and help in the conversation about business models. Because I know how hard that can be and what pressure this can put on management. I am in fact very sympathetic to their cause and the problem they are trying to solve.

Unfortunately, the “Commons Close” is the the opposite of a solution.

And could Dgraph be forked now even under Common Clause to escape it?

The last Open Source Version of Dgraph was 1.0.4: https://github.com/dgraph-io/dgraph/blob/v1.0.4/LICENSE.md - so the anyone could fork from that and build up an Open Source community around that.

For Vereign, we have been working on a Proof of Concept including Dgraph. So for now we have put a hard freeze on the version we use to be 1.0.4 and pulled a copy of the repository, just in case. We’ll finish our PoC to see where we land, and then we will revisit the decision for Dgraph.

My hope is still that Dgraph will reconsider and switch back to an Open Source license.

If they don’t, our choices will be:

  • Migrate to another Open Source graph based database
  • Fork Dgraph at version 1.0.4 and build up our own team to keep developing and maintaining it

And if someone / the community were to fork before us we’d likely join that fork instead and contribute resources to it. If we are doing the fork, we’d invite anyone interested to join us in developing that further.

But again - I truly hope it won’t come down to that.


(Adam Hopkins) #18

As someone who is a developer and also a lawyer, I find this very troubling. I’m not sure I can use dgraph for anything other than personal experiments. This language is not clear and could lead to an unstable future. I echo the concerns that have been well stated by @georg.greve. This is very troubling and may lead me to halting development for a usage I had in mind for dgraph. I would highly implore the reconsideration of this towards a more community friendly license if you actually want to drive adoption.


(Adam Hopkins) #19

Oof… I just read the actual text of the clause. It makes my stomach turn. @mrjn I’m glad you think that’s what it says… but I would not be willing build a commercial product unless you are willing to sign that in writing for me that it would be “alright.”

The language seems quite clear:

I cannot make money from “a product or service whose value derives, entirely or substantially, from the functionality of the Software”. What web based app does not derive substantial value from its data layer? Indeed … that is the whole point. We build backend and frontend applications precisely so that we (and our clients and customers) can derive value from our data store.


I know that dgraph draws a lot of comparisons to neo4j: “in neo4j, …”

I hate to be the one proliferating neo4j v dgraph, but:


(Joe Bordes) #20

We will follow/support this fork if the license doesn’t change