Hacker News new | comments | show | ask | jobs | submit login

off topic: flipping through the dgraph code, I noticed their licensing switch from Apache 2 to AGPLv3, anyone involved around to comment? Adding a draconic open source license is an unwise decision for an early stage database product imo

(https://open.dgraph.io/licensing is a dead link)




> Adding a draconic open source license is an unwise decision

AGPLv3 is just a license, it is not "draconic", nor "cancer", (despite what Ballmer wants you to believe), it simply represents an ethical/moral agreement with the ideology of software freedom and since it is their code, they are free to express what they believe via the appropriate license. Nobody is making them do it, nobody is forcing you to use it and nobody is demanding you agree with it, it was a free choice and is therefore as far from "draconic" as one can possibly be, unless you believe that everybody who doesn't subscribe to your worldview is "draconic" by definition.


I think what fortytw2 was trying to say is that the AGPL is not a wise choice for software that wants to gain the most popularity and usage as possible since usage of AGPL licensed software is categorically banned (even more so than GPLV3) by a some of companies.

As an aside, one can certainly describe something as draconic(or whatever else) if one views it as such; it's just an opinion.


Having just gone through a lengthy review process identifying a suitable license for our soon to be open-source software which has a commercial aspect, and selected AGPLv3, I'm very curious to know what companies have it "categorically banned". We did some research and didn't find that anyone had an issue with it. Whilst AGPL does open up come grey-areas which aren't as well understood as GPL the general reason to use it seems to be as part of a dual licensing scheme where companies with AGPL issues can simply purchase a non-transferrable limited MIT license or similar.

Can you give me any more info on your sources?


Google bans it for example: https://opensource.google.com/docs/using/agpl-policy/.

I would also be surprised if Apple (being so allergic to the GPLv3) used AGPLv3 software, though that's just speculation.


There's a perennial discussion of AGPLv3 here on hacker news. A surprising number of projects select it, then revert to something less toxic to corporations.


> I think what fortytw2 was trying to say is that the AGPL is not a wise choice for software that wants to gain the most popularity and usage as possible

Why should that be a laudable goal? Not all projects are megalomaniac.


Three separate points here:

1) copyleft versus non-copyleft

2) which copyleft license to choose

3) the strategy of the dgraph

Regarding 1), non-copyleft leads to higher short-term adoption, but copyleft is often the better choice long-term. Moreover, history has shown that if you switch from a non-copyleft to a copyleft license, people will feel tricked. So the "early stage" argument doesn't hold. If you want to use copyleft long-term, better be honest and do so upfront.

Regarding 2), whenever you ask a lawyer in that field, they usually tell you that AGPLv3 is almost always what you want, preferable to GPLv3 and most other alternatives. So the "draconic open source license" argument doesn't hold. AGPLv3 just closes large holes which GPLv3 left open, to ensure that people actually stick to the copyleft principle. So if you want copyleft, choose AGPLv3 unless you have a very compelling reason not to.

Regarding 3), the dgraph people seem to see it a similar way:

https://open.dgraph.io/post/licensing/


The AGPL for database products isn't unheard of. See also Neo4J.

It makes sense from the host business's point of view. If you are the sole contributor, then you're entitled to do what you like. Moreover, you're also free to charge for commercial licences.

This licencing model wouldn't be appropriate for a community-centric database, such as PostgreSQL. With many contributors to core, no one would be able to arbitrage the situation.


> The AGPL for database products isn't unheard of. See also Neo4J.

And Mongo. Also RethinkDB until the parent company folded.

> This licencing model wouldn't be appropriate for a community-centric database, such as PostgreSQL.

I don't disagree.

It's interesting, though, how counterintuitive this is. I would think that GPL wouldn't be a problem for individual contributors (the types of participants I imagine when I think of a "community"), but for business contributors who don't want competitors to take advantage of their modifications. And yet, anything a business contributes back to an MIT/Apache project is actually less protected than a contribution to a GPL project.


> > This licencing model wouldn't be appropriate for a community-centric database, such as PostgreSQL.

> I don't disagree.

> It's interesting, though, how counterintuitive this is. I would think that GPL wouldn't be a problem for individual contributors (the types of participants I imagine when I think of a "community"), but for business contributors who don't want competitors to take advantage of their modifications. And yet, anything a business contributes back to an MIT/Apache project is actually less protected than a contribution to a GPL project.

Well, a lot of them want to, at least temporarily, distribute some features without releasing them. And that simply doesn't work for GPL projects, unless there's a sole owner and all external contributions are made under some form of CLA. There's a lot of open-core type projects, but in my experience they're on average less healthy than projects with multiple contributing entities.

For PostgreSQL there've been a lot of closed source forks, but a lot of them folded and/or couldn't keep up with the amount of changes and thus are based on some super old version (hello Redshift, hello Greenplum). The only ones that appear to be able to keep up are ones 1) that move more invasive changes upstream after a while and religiously rebase after every release, never delaying, or 2) move their modifications into extensions, possibly adding the necessary extension APIs to core PostgreSQL.


I think the problem is they never will contribute back any modifications upstream. Pick the right license for the project. Apache is for marketshare, gpl is perfect framework for community involvement, agpl is best for control


> agpl is best for control

In my personal opinion, AGPL is largely chosen to avoid various cloud providers from profiting significantly from $product, without ever giving back. That's control, but a very specific form of it. I don't personally like AGPLs legalese, it's very very imprecise.


From what I've heard of lawyers in the Free Software world, they most applauf AGPLv3 for its clarity and precision.

Maybe it just seems imprecise to a layperson because they don't know the well-defined meaning of various legal terms? (... and confuse these with their fuzzy meaning in ordinary language)


> From what I've heard of lawyers in the Free Software world, they most applauf AGPLv3 for its clarity and precision.

You're sure they were talking AGPLv3 and not [L]GPLv3?

The definitions of what constitutes an interactive program is quite vague (sect 0 and 13). Let's say you have a database server under AGPL (mongo, or say citus). Clearly they support interactive access in some form, but from the perspective of user of an application using said database access is not interactive, nor is it clear how the database could provide such an interactive notice. Various vendors addressed that issue with clarifying notes about their understanding, but that definitely increases doubts of possible users, including their lawyers.


Amazon is a huge threat for any infrastructure company using Apache 2.0. If you gain popularity, then Amazon will be a direct competitor once they host your project. Given that Amazon's services benefit from the IE effect, it's not irrational for an open source infrastructure company to eliminate such a threat via licensing.


Just to be clear, badger's license is still Apache 2.





Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: