Consider Apache license?

[gitblit]

This is a really compelling project and one I might like to incorporate in a new undertaking but the AGPL license is a non-starter and is an odd choice when you consider that RESTHeart can be extended with custom application logic. In such a situation, the AGPL requires that my custom application code be distributed as either GPL or AGPL neither of which are very friendly to commercial use.

Would you consider distributing RESTHeart under the Apache license? Or does the AGPL truly embody your vision?

[ujibang]

Hi @gitblit

if you develop custom code that can be injected via configuration (e.g. application logic handler or access manager) you are not modifying RESTHeart code thus not creating a derivative work. So you are not forced to redistribute it under the AGPL.

If you modify the core, yes you have to redistribute the code or SoftInstigate, the company behind RESTHeart can provide you RESTHeart under a different commercial and commercial friendly license, have a look at http://restheart.org/support.html.

So either you pay back to the community with code or you buy a commercial license.

[gitblit]

I didn't drill into the support page since I assumed commercial support meant literally support and not commercial licensing. Good to know, thanks.

I'm less comfortable with this statement:

you are not modifying RESTHeart code thus not creating a derivative work. So you are not forced to redistribute it under the AGPL

Subclassing ApplicationLogicHandler creates a derivative which IMO is bound by the AGPL license since ApplicationLogicHandler and all the dependent component classes are AGPL'd.

Can you cite documentation from FSF that supports your assertion? This seems like exactly the same scenario as Linux binary kernel modules so in the worst case it's a derivative work. In the best case it is unclear which makes adoption a discussion on nuance and interpretation rather than on technical merit.

[mkjsix]

Hi @gitblit, This is a pretty interesting discussion, as the limits of "derivative work" are still highly debatable, but you raised a good point.

The original choice about adopting the AGPL v3 was influenced by two main ideas: first, RESTHeart by its nature is going to be often used to build networked services, and the AGPL eventually regulates this case. Second, RESTheart at the moment is highly coupled with MongoDB, which adopts the AGPL, so we saw as "less troublesome" to release RH with exactly the same license.

My own initial interpretation was the same of @ujibang, so if you extend a class but don't change anything of the RH source code, this shouldn't violate the AGPL, but to be honest I'm reading documents which are saying the opposite.

We are discussing internally this subject and we'll go back to you to exchange opinions and find a solution. The risk we need to avoid is to live in a grey area, where these boundaries are not clear: this would just damage RESTHeart's adoption.

[gitblit]

The fact that RESTHeart is a RESTful server for MongoDB is the reason I'm here. :)

Having said that, RESTHeart is really tied to mongo-java-driver & Undertow - both of which are Apache licensed. The license of MongoDB itself is has no technical relevance to the license of RESTHeart in this case, but of course the license choice is very relevant to SoftInstigate.

If you were to adopt the Apache license then there would probably be no purchases of the commercial license unless you offered unique features in a commercial/pro version that were unavailable in the FOSS version. Many projects take this path and also try to sell support contracts. I don't know how successful this approach is.

If you stick with AGPL or GPL then it's pretty clear: plugins or extensions must be AGPL too. This is the nature of the (A)GPL. If the interested party is commercial, the choices are purchase a commercial license thus avoiding the AGPL or acknowledge RESTHeart has great potential but you build your own RESTful API server instead. This is a danger for a successful RESTHeart project.

Database-specific RESTful servers are a great idea and they can be of real value to many, but the license choice is critical to serious adoption. You'll find that a great many Java projects choose Apache, MIT, or BSD licenses so that the project can be consumed by FOSS and commercial projects alike. I can't tell you what is right for RESTHeart and SoftInstigate, but I can tell you that AGPL is not the right choice for me and likely a great many others.

Thanks for giving this topic some consideration.

[ujibang]

given that we provide commercial license for buz needs we consider fair asking people that modify RESTHeart to contribute code back to the community.

@gitblit thanks for your thoughts, and feel free to reopen this issue if you have more to share.