The use of AGPL license

[Lie]

Can ObjectPath be rereleased under a clearer license?

AGPL makes sense for a network application like Mongo where Mongo itself is used internally by other applications but rarely need to be distributed outside the internal network of the user-facing application. Commercial applications that simply uses Mongo as a backend database have never been required to turn GPL/AGPL-ed just because Mongo uses AGPL. Instead with AGPL, all and only changes to Mongo itself must be shared, which is a fair deal.

On the other hand, I think libraries like ObjectPath isn't suitable for AGPL. There has been various interpretation of AGPL, but under the strict interpretation of AGPL, any applications that uses a library licensed under AGPL would itself be required to turn turn GPL/AGPL, which severely restricts the use of this library in commercial projects. Even if this isn't the intended case, the mention of AGPL itself would probably scare away any potential users which understand how AGPL could be interpreted in some situations.

Can you please rethink about the license? Either that or can you please clarify what exactly AGPL as used by ObjectPath requires to commercial applications that uses it.

[Adrian Kalbarczyk]

The aim is not to contaminate anyones work with AGPL. My intention behind the AGPL is that I want to force people who make changes to ObjectPath (as a language or library) to give changes back to the community. I thought about LGPL, but this license doesn't force redistribution in cases when code don't need to be distributed (for example when the code is provided in SaaS model).

I am thinking of adding permissions for commercial usage on top of the AGPL license (something like here: https://github.com/unbit/uwsgi/blob/master/LICENSE). This is somewhat tricky because every word make difference and I'm not a lawyer. Do you happen to know other projects that change GNU licenses in any way? Maybe I'll just steal this from somewhere:).

[Lie]

For projects that have tried adding a linking exception to AGPL, I have found these:

• https://github.com/opencog/opencog/blob/master/LICENSE - opencog added a linking exception to AGPL, but seems to be poorly written, I would be wary of its validity
• https://github.com/versae/qbe/issues/7 https://github.com/versae/qbe/commit/2e0d97218083863169ad8a275484e4f90b1d2653 - django-qbe was originally AGPL, someone raised the issue with AGPL and then they added a linking exception to AGPL, however it seems they have now decided to relicense the project to MIT
• http://mo.morsi.org/blog/node/270

Unfortunately, I'm not a lawyer either, so I probably should not be making any advices.

At the very least, I believe providing examples on how programs can link with ObjectPath without getting infected with AGPL would go a long way. For example, MongoDB explicitly promises that using Mongo as a database for a commercial application would not trigger AGPL on the application. Although probably not legally binding, it provides guidance over what is considered acceptable or not in the particular context of the library.

I personally prefer permissive licenses for libraries due to their ease of use. From the point of view of a library author, especially if you are a small team and don't have the a team of dedicated lawyers, publishing a library under a strong copyleft is pointless except as an ideological stand. From the point of the library user, permissive libraries is compatible with pretty much any other libraries, so a permissive license leaves everyone with more time to focus on improving code rather than worrying over legal matters, or worrying whether what you are doing could lead you to get sued five years down the road. Maintaining a private fork is difficult and expensive, as most people who have tried to do so would attest (constantly rebasing changes means constant breakages). Since the cost and benefit already highly favours sharing changes even with permissive license, I am usually not too worried about using license to enforce sharing. Because of these reasons I personally always share any changes to original author (or maintainers). These are entirely my opinion, of course, but I believe it is a widely shared opinion.

[Adrian Kalbarczyk]

I added the following to the license:

License

AGPLv3

Using ObjectPath language in your project does not mean that your project is a derivative work, provided that you don't:

• extend the language functionality,
• make optimizations,
• sub-class any of it's modules.

AGPL v3 license has been chosen to ensure language consistency and provide a way to finance its development.

If AGPL v3 is too restrictive for you, please consider buying a commercial licenses provided by Asyncode. This is the preferred way of supporting this project financially.

Hope that helps.

Greetings,
Adrian Kalbarczyk

http://about.me/akalbarczyk

--
You received this message because you are subscribed to the Google Groups "ObjectPath" group.
To unsubscribe from this group and stop receiving emails from it, send an email to objectpath+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Lie]

Awesome, that looks perfect. Am I also correct in assuming that making the listed modifications also are possible without infecting the rest of the application's project as long as the modifications to the library are shared (under AGPL)? In other words, the scope of the AGPL as used by ObjectPath is only the library itself?

[Adrian Kalbarczyk]

Yes.

I also changed the license of Javascript implementation of ObjectPath to BSD. I'll accept any pull request of a good quality there.

Greetings,
Adrian Kalbarczyk

http://about.me/akalbarczyk

2014-10-21 2:52 GMT+02:00 Lie <lie....@gmail.com>:

Awesome, that looks perfect. Am I also correct in assuming that making the listed modifications also are possible without infecting the rest of the application's project as long as the modifications to the library are shared (under AGPL)? In other words, the scope of the AGPL as used by ObjectPath is only the library itself?

--