Switch back to a less restrictive license than AGPL

[techdragon]

The use of the AGPL will significantly hamper use of this software at corporations, since the AGPL is in many jurisdictions, both legally ambiguous and without case law for corporations' lawyers to base their advice on, which leads to the decision of "not worth the risk". I personally avoid reading, using and contributing to AGPL software in order to avoid personal legal liability in the event of any future legal action.

In addition, I don't see any contact with past contributors to the project, which is typically required as you have to consider their contributions and copyrights when relicensing, some information about this is here https://opensource.stackexchange.com/a/46

Also, personally, I have regularly evaluated djongo over the last 12 months, for use at the company where I work, every time it has come out favourably, and have just been waiting for an opportunity to start using it, however this switch to the AGPL means I will not be able to use this library at all. Unless you are doing this as part of your plans to make DjongoNXT and you are intending this to have a business friendly license, I wont be able to use this amazing library you have built, personally or professionally. Having just discovered that you set up a Patreon, this is an especially disappointing change for me as I have been excited by the progress this library has been making for some time now and were it not for the change to AGPL, I would already have supported it from my personal Patreon account instead of posting this github issue.

If you are unwilling to change the license, can you please explain/elaborate on the reasons behind your decision to change to using the AGPL?

[nesdis]

Sustainable Development

Djongo as a project is at a stage where its development must be transformed into a sustained effort. I am exploring ways to make this happen, and would love to hear your thoughts. Djongo is an open source project. Should it also be a free source project? (Free as in "free beer"). When you decide to adopt Djongo for your critical work, should it be backed up by a support mechanism? If not, would you still consider adopting it for your work?

I can release a version of the project for you under different licensing terms.

[techdragon]

I’m thrilled to see your goal here is to make sure your work on Djongo is sustainable! Getting paid to maintain an open source project can be a huge challenge.

While Patreon has opened up a vibrant and promising avenue for many of today’s developers to get paid for their work on open source, it has its drawbacks. It is a great tool for simplifying the collective funding of work, making it easy for patrons to give their money and easy for people to accept this money, but its not a subscription service built for managing an ongoing legal agreement between two parties.

I’ve personally become a patron because I think that proving to the world that that NoSQL can actually work with Django, and that NoSQL + Django is in fact awesome. However for businesses, commercial developers, I would recommend you consider using License Zero in addition to your Patreon page. I implore you to look carefully at License Zero, and In particular, pay attention to the section about subscriptions since it might not look like it suits your purposes, unless you get all the way to the end of the section. I’ll just quote it here to help emphasise why I think License Zero fit your goals.

That doesn’t mean developers can’t use License Zero to get paid for work over time. As mentioned above, developers have complete control over whether to make new contributions under an existing licensing identifier, or create a new one. Developers can create new identifiers for each new major release of a project, or even for each new month. It’s up to developers to communicate those choices to users, if they like, so users know what to expect. As a baseline, License Zero’s licenses and terms only grant licenses for the software developers have already made, in the past. But licenses for past work don’t expire in the future.

License Zero wont get in the way of you using Patreon, you could adopt calendar based version numbers dedicated customers/patrons would then be buying or subscribing to get a new license to the new version released each month. It will also provide both you and ‘commercial customers’ legal clarity that helps everyone sleep at night (and spend less on lawyers haha).

[nesdis]

License Zero is great. Although I was aiming for more of a 'subscription based licensing' model, it has its disadvantages to the license purchaser, as the website explains.

I would be happy to release a 'one-time private license' which is a 'perpetual license', as espoused in the website, to you, or your organization.

[tony]

I would be happy to release a 'one-time private license' which is a 'perpetual license', as espoused in the website, to you, or your organization.

That may be enticing.

AGPL, it's enough in my situation to throw me off a bit - why would it be there if it wasn't the intention to enforce it fully? If it's true the end goal is making the project financially sustainable, I think the best place would be for the license to be plain as possible to get things across?

I think there could be a better way of achieving the goal would be the LICENSE stating that the package / any code copied from it can only be used if the terms are met (maybe?)

A custom license requiring payment for commercial use may help with funding the project. Even more liberal than that would be a sliding scale system. An example of a complex one would be https://www.unrealengine.com/en-US/eula.

I'm not against GPL per se. But the reason I have these feelings is, in practice, I think it paradoxically can have the opposite effect (in the end). The reason why is the creation of a derivative can be perceived as punitive and effects unrelated code. It's also a license that's very legally complex. There's also logistical issues of keep GPL as a license in the source tree in general - commits made afterward look like derivatives of the license. So some projects, e.g. SDL2, have to move from LGPL to a fresh codebase.

I guess the other reason is derivative licenses don't really fit in the Python or Django ecosystem.

Another note: If there is a custom license adopted, having contributors sign a CLA to assign copyright is helpful. https://cla-assistant.io/ That assures that any contributions will still work if the terms change in the future.

[nesdis]

The reason why AGPL was adopted was because of its popularity (positive or negative). People who want to use this project immediately know what they are getting into. They understand the terms of the license, as they have encountered it several times in the past.

Switch to a custom license: I am not a lawyer, I cannot draft a custom license and make sure all loop holes are covered. AGPL was drafted by some really really smart people. (Is that why everybody hates it so much??) I feel replicating their effort is a waste of time.

AGPL is a put off: It is a put off only if you want to use somebody else's work in your commercial application, without giving back! If your project is not commercial, no one is asking you to pay.

[techdragon]

With some time taken to think about what you said, I think I need to clarify my arguments.

Switch to a custom license: I totally agree this is a bad idea. I would never suggest anyone draft their own license. I suggested LicenseZero, exactly because of this face. You seemed to want a license that enabled you to let everyone look at the code, use it for free, but require people making money from the software you were writing, to pay you. Which is what License Zero is for. and since it already had a lawyer do the legal work and ensure everything is ok, it seemed infinitely better than writing your own license that tried to achieve the same goals.

AGPL is a put off: You switched licenses, with the intent of making this project economically sustainable. While the AGPL is frequently used by businesses, who want companies to pay for licenses to their open source software, you haven't setup a business, you are doing this as an individual developer. I don't see contributor agreements, copyright assignment statements, a legal billing entity, or any of the things that are needed to avoid the many problems the AGPL brings for projects that want to use the AGPL this way.

To illustrate. Lets say I take you up on obtaining a different license as a private arrangement between yourself and me... now lets take this pull request https://github.com/nesdis/djongo/pull/230, they are agreeing to give you that code under the AGPL... not the AGPL and whatever custom license you also decide to give other people...

• If you want to use the AGPL and be able to sell commercial licenses in order to make money, you will have to set up a bunch of legal things that you have not yet done.
• If you do take any of these legal steps, and still want to sell alternative licenses for commercial customers, you must do all of the work, you cannot accept any external contributions, because you are not able to re-licenses the contributions provided to other people if you do not set your project up so that this is possible.

You said...

It is a put off only if you want to use somebody else's work in your commercial application, without giving back!

Which isn't entirely true, it is not a put off only if you want to use somebody else's work in your commercial application, without giving back. It can be a put off for other reasons, such as the issues regarding case law and legal ambiguity regarding the definition of terms such as "derivative work" that i mentioned in the original post.

At the end of the day. I'm just trying to make it clear. I want to give you money in exchange for your software helping me make money, (in addition to the money I'm still personally giving you via Patreon as an individual that loves Django and NoSQL) but you are actively making it more difficult for businesses (such as the company I work at) to give you the money that you want us to give you. If this was MIT/BSD/Apache2, etc... a business could just subscribe to a custom pledge or some other higher tier in Patreon, with License Zero a business could just buy a license to each release, but with the AGPL, you need to do a bunch of work in order for it to be safe for a business to give you money. I support your desire to make this work economically sustainable, it just seems like you are sabotaging this goal by not making it easy/possible/safe for people to pay you for it.

[gggfreak2003]

I fully agree with @techdragon. For me it is imposssible to use a version after the license change and I have to look for alternatives or use the old stuff. I would pay for a license but now it is impossible for me.

Another question is: Do you have the agreement of all contributers to change the license? Otherwise you are eventually in conflict with their rights because their source code is still under the old license. See

[nesdis]

@techdragon What I understood from Licence Zero, is that it is a 'dual licencing' model correct? It comes with 2 variants, the opensource or 'public' license, and the commercial or 'private' license. How exactly is the open source version so, different from AGPL? In fact I thought it was much more restrictive.

they are agreeing to give you that code under the AGPL... not the AGPL and whatever custom license you also decide to give other people...

The copyrights to the code in the repository are being held by the author of the repo. That is the first line in the AGPL license text. Are you saying people who submit bugfixes and pull requests to MongoDB (which uses AGPL) can prevent MongoDB from releasing commercial versions of its license?

[techdragon]

@nesdis There are two "public license" options provided by License Zero. I would agree, the "Parity Public License is quite like the AGPL. But there is also the "Prosperity Public License" which is much simpler and geared towards free non-commercial use in a sort of "MIT but you have to pay me if you want to make money with this" kind of way.

And also... "The copyrights to the code in the repository are being held by the author of the repo." may not legally mean what you or I think it means, as its never been tested in court. I am saying that were MongoDB not taking steps to avoid being bound by the AGPL, the contributors to their open source repo would in fact be able to prevent them from releasing commercial versions of the software by way of the standard claim of copyright ownership requiring MongoDB to have their permission before any other uses of their code is made.

You can look at what MongoDB are doing as a good example of what is needed to be able to license a project as AGPL and also sell software licenses. In these scenarios the AGPL is used as a weapon to prevent potential competitors using their software by forcing them to open source any of their work, while the company that is selling the AGPL software will also setup legal mechanisms to ensure they have the rights to sell commercial versions. You can see how MongoDB does that here. These are the steps you have to take in order to contribute to the AGPL MongoDB "open source" project https://github.com/mongodb/mongo/wiki#contributing-to-mongodb by completing these steps, you are granting legal rights to their company that the company then uses in order to legally be able to sell commercial licenses under the terms they see fit.

This is from the contributor agreement:

By submitting a Contribution, you assign to MongoDB all right, title and interest in any copyright you have in the Contribution, and you waive any rights, including moral rights, database rights, etc, that may affect our ownership of the copyright in the Contribution.

And the agreement even has a fallback:

If your assignment in Section (2)a is ineffective for any reason, you grant to us and to any recipient of any Work distributed by us, a perpetual worldwide, transferable, non-exclusive, no-charge, royalty-free irrevocable, and sublicensable license to use, reproduce, prepare derivative works of, publicly display, publicly perform, sublicense and distribute Contributions and any derivative work created based on a Contribution...

And there is a lot more in the agreement, all designed by lawyers to ensure that MongoDB the company retains all the rights it requires by law to have in order to commercially license the otherwise AGPL code. Which is why you having already merged changes under the AGPL licensed version of this repo has made addressing this matter even more urgent.

[foodaemon]

Personally, i think this library is great and provides lots of value to anyone using django with mongodb. I even mentioned about this library to pythonbytes and they referenced it in one of their episodes (https://pythonbytes.fm/episodes/show/85/visually-debugging-your-jupyter-notebook). However, the AGPL license prevents me from using it in any of my projects (and also provides less motivation contributing back to the djongo project) because of the ambiguity of the license and risk and lawyers providing different interpretations of this license (and i am not sure if this is tested in court). One of the interesting one i found online is: “Under the AGPL, if you use code in a web service, you required to open source it”.

Below are some of the references:

https://opensource.google.com/docs/using/agpl-policy/

https://www.theregister.co.uk/2011/03/31/google_on_open_source_licenses/

[jammyweb-james]

Sustainable Development

Djongo as a project is at a stage where its development must be transformed into a sustained effort. I am exploring ways to make this happen, and would love to hear your thoughts. Djongo is an open source project. Should it also be a free source project? (Free as in "free beer"). When you decide to adopt Djongo for your critical work, should it be backed up by a support mechanism? If not, would you still consider adopting it for your work?

I can release a version of the project for you under different licensing terms.

Hi - I need to contact you to arrange a suitable commercial license. Please msg me on james.hammond@mediakind.com.

[morbitech1]

I would also be interested in using this library under a less restricted license. Please message me on mathiasboetcheriversen@gmail.com.

I would both be interested in donating and contributing to the project, as frankly it is very far out of date.

Also note that the license on pypi is still unchanged

https://pypi.org/project/djongo/