Switching Dgraph to a Liberal License - Dgraph Blog


#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


#21

I think dGraph is really awesome SW, but it should stay open source. This licence, in my opinion, is not good choice.


(Adam Hopkins) #22

@mrjn Is there any chance that this will change? Perhaps releasing ratel with the clause and the main DB with something more open?


(Zak) #23

As someone who has developed a significant code-base around Dgraph that we were planning to open source, I share the sentiment of the developers. I also understand Dgraph Labs’s motivation. Like Redis Labs, they don’t want AWS/etc, with their abundant resources, to take advantage of their hard work and essentially take away their future business.

I am not a fan of Common Clause because it “pollutes” and negates well-defined and well-meaning open-source licenses. The clause has nothing to do with Open Source and therefore should not be associated with such licenses. There should be a new Non-Open-Source license that incorporates the terms of Common Clause, and Dgraph Labs (and others) should switch to it.

For now, everyone should understand that Dgraph is not Open Source. You should develop on it and/or contribute to it if you accept the risks and restrictions associated with it’s ambiguous license. If you are not comfortable with that, as is our case, you have many choices, including ArangoDB, OrientDB, JanusGraph and Neo4j.


(Cameron Batt) #24

@ahopkins

I am also concerned with complex licences, which may be problematic for my startup, even though I am not a lawyer. I was excited when they moved away from the AGPL

As a startup founder I understand DGraph’s perspective, that they wan’t to have a business built upon this technology, and don’t just want anyone to be able to sell their DB “as is” without some sort of financial benefit flowing back to them as the creators.

I am keen fo them to succeed financially so they have the capital to add new feature and keep improving the performance etc.

As a lawyer what sort of clause could you add that would allow DGraph to have ownership on selling the DB as a service but not conflict with a company building a product that uses it as it’s primary DB, if not the clause that @mjrn says does just that?


(Adam Hopkins) #25

First, let me start with the standard lawyer fare of stating that I’m not providing any legal advice. Without knowing the particulars of the business model, goals, etc, being able to provide an ample legal solution is simply not possible.

With that said, open source software does have a proven track record. Companies can be built upon the model. Yes it may be fraught with challenges, but with it come benefits as well.

It is the model that pretends to be open to the community, but is in fact a wolf in sheep’s clothing, that bother me greatly. Many developers will likely not understand the potential threat of something like the Commons Clause. If for no other reason than the name itself seems innocuous. Perhaps @mrjn does not fully understand, at least that is my read given his earlier response.

Perhaps there is a place for something like this clause. I can see it for something like ratel. A tool that is used by developers, but not made to be reused. The database itself is fundamentally different. Its purpose is to be embedded into a larger stack. That Clause has now compromised that stack. It is entirely inappropriate for any project where the developer may want to attract business from the public. Even if it were an entirely internal sysyem with no public facing UI, it’s broad nature might still be far reaching enough to taint it.

Speaking for myself, with this license, I cannot see building anything other than a proof of concept, housed in my machine, for my usage only. Even that I would be wary of. “Substantial” is a vague word that can be interpreted (and had been) differently by different courts in different jurisdictions. I would not be willing to risk myself or my business over that word.

Yes, dgraph is nice. But as long as it remains under a restrictive license, I cannot advocate its adoption, nor implement it myself. There are many other open source alternatives.

If I were to advise dgraph I would start by making sure there was a clear identity and set of company goals. And if I were asked about adopting this Clause, I would ask why? Because in the end I don’t think it does what they want. With a clear perspective, only then can the appropriate license be chosen. I won’t surmise as to my thoughts on how or why it was adopted. I choose to believe it was with an innocent heart and that @mrjn believes what he said. But again, for me, that is not enough.


(Adam Hopkins) #27

Here here!

If only the forum software allowed me to highlight this text…

I agree. I cannot imagine that Google is the intended audience that this platform was built for. As I stated earlier, knowing the identity of a piece of software and a company are crucial first steps before deciding upon an appropriate license.


(Manish R Jain) #28

Hey folks,

We’ve heard your concerns around licensing. This thread is now attracting fake accounts, who are just trying to troll this discussion. I’m closing this topic. Feel free to start a new topic in the forum if you want to discuss this further.

Cheers,
Manish


(Manish R Jain) #29

Common Clause on License => Dgraph is not Open Source