AGPL?! about authlib

[lepture]

Authlib will be licensed under BSD from v0.11.

• Read the official announcement: https://blog.authlib.org/2019/switch-to-bsd-license
• My personal blog post: https://lepture.com/en/2019/authlib-bsd-license

I'm accepting donations and sponsors via Patreon now: https://www.patreon.com/lepture

[lepture]

v0.11 is released. Authlib is under BSD now.

[traverseda]

I think AGPL is a good choice for what you're doing. If it's an actual open-source project using your code, AGPL is fine. If it's an enterprise client, it forces them to pay. Very much in the spirit of the GPL, I think.

I think you should be as transparent and upfront as you can be about costs for licensing your code though.

[lepture]

The problem is that there isn't a good, solid and right solution of OAuth library in Python. OAuthlib is not well (or even not right) enough, and Flask-OAuthlib is depending on it, which makes it very hard to create a right OAuth provider.

In my opinion, OAuth providers are a company level things. I do want to make money with Authlib, which will certainly support my work on Authlib. In this case, I can spare more time to work on Authlib without worrying my incomes. If I'm lucky enough, I may make a living by Authlib.

cc @traverseda It is here: https://authlib.org/plans

[lepture]

@JonathanHuot There is a commercial license.

I will publish a post on the license topic. I've thought it for a while. Authlib will split into several parts in the future, some of them will be licensed under BSD.

[Lawouach]

Hello,

I had never realised authlib was AGPL. I certainly should have looked indeed.

As an OSS maintainer, all the GPL variants always make my head spin because I never know if I'm in the legal rights permitted by the license of a library I'm using. Specially in dynamic languages land.

I always use BSD or Apache licenses and now I have to wonder if I can use authlib without issue. I think likely not because that would probably mean I have to change my license. This is a shame but I may have to fallback to a different, less good, projects because I cannot afford a license (I don't quite know how that commercial license would impact my own OSS projects should the terms change).

All in all, you are obviously right to use whatever license you feel is appropriate for your own projects and philosophy. But, in my own little world, I'm afraid I will have to drop authlib altogether because I don't know its consequences.

Sorry for that but felt like you ought to know.

Cheers for all the amazing work nonetheless.

[JonathanHuot]

For what's worth, our company uses a lot of open-source projects and contribute some (see @thomsonreuters), but AGPL is a strict denied by our lawyers in almost all cases.

[androiddrew]

Just so you know in the United States the "Virality" of the AGPL has never been tested in court. Many people misunderstand this and unfortunately your company's legal team will never advise you to use a project with this license because there is no set precedent regarding its terms. For them it is all a risk aversion strategy. Many of you misinterpret your's or other companies legal team's advice as evidence of the "virality" of the license. In order for a precedent to be set in a US court there MUST be a court ruling. Usually what happens is party A sues party B and they just settle out of court. Settling out of court closes the issue therefore no ruling is made and the debate of the license remains. If you do your research, you will find that very little precedent on any of the GPL version licenses has ever been set, and when it has the question has revolved around very very specific clauses of the license, not all terms of the license.

It is very disheartening to hear that so many people misinterpret this as being a "viral" license. Simply importing a licensed work in python does not automatically invalidate your copyright claim to your code and your ability to license it under your own terms. Now if you modify the licensed work, in this case authlib then the terms of the AGPL are activated and requires you to provide those modifications to "your" users, not the general public. It's pretty clear that the AGPL means that you can not hide the interaction of your modifications behind a network layer. That is it. Granted when you provide your changes to the licensed work "your" users can then redistribute your work also under the AGPL.

The commercial license, if constructed properly, does one thing that the open source license doesn't. It lowers the risk to near zero that the owner of the copyrighted work will sue you, and that is why your company will let you use it. Welcome to the litigation nation everybody.

[lepture]

I myself don't quite understand the license issue either. My primary goal is to allow the use of Authlib in open source projects, but paid in close source projects. I'm not sure if AGPL is a good choice, or is there any other options?

[lepture]

I'm open to this issue. My primary goal is to keep Authlib as an open source project and in the meantime I can sell a commercial license. So if anyone can provide me a better choice of licenses, I'm happy to change to it.

[Lawouach]

Hey again,

Over the weekend, the project team gathered and discussed this question of a license. Since we haven't launched yet, we have the opportunity to make the decisions for the license.

Usually, projects I work on are libraries or frameworks and I tend to dislike the GPL variants for those because I hate imposing my ideas on others and, because I don't intend on commercializing them. So, in those cases, permissive licenses such as BSD or Apache fit them well. However,this particular project, where we rely on authlib, is not a library but a webapp/dashboard. We realised that, actually in that case, GPL was quite interesting because it's unlikely that someone will "import ..." this project from their code. They'll merely act against its API endpoints and UI.

We came to the same conclusion that you did @lepture, that AGPL for SaaS related products is a good balance because it protects us from straight competition (basically rebranding our stuff) while allowing us to be both OSS and commercial.

Would a permissive license prevent us from doing business? Certainly not but AGPL has some constraints that provide an interesting safety net we believe.

I wanted to be public with this because I felt it was unfair to make you question your license choice while we'd be likely choosing AGPL as well for the specific use case we have in our hand. I still favour BSD/Apache for pure libraries I usually manage. However, authlib is on the fence here as it provides more than a mere library to import from.

The good news is that we can now safely enjoy authlib awesomeness :)

• Sylvain

[bjmc]

The pricing is pretty clearly stated here.

Plus
This plan is for commercial projects.
License: Commercial License
$1000/year

It doesn't include a guarantee for N years, but it's a brand new project anyway.

[Lawouach]

As I mentioned above, we finally made the call to release our product under the AGPLv3+. Relying on authlbe felt important enough and we agreed that our web app, AGPLv3+ was correct (we wouldn't use it on a library however).

Here is the project by the way https://github.com/chaostoolkit/chaoshub

Thanks

[ThiefMaster]

Just discovered this: https://commonsclause.com/

Maybe it could be an interesting alternative to AGPL?

[arikfr]

Came back to this thread to post a link to Commons Clause too :-)

@traverseda Commons Clause defines sell broadly enough to include SaaS:

including without limitation fees for hosting or consulting/ support services related to the Software

I'm biased, but I will feel very comfortable with a Commons Clause license and will be happy to buy a commercial license if the switch is made.

[bjmc]

I believe that @lepture intends to sell commercial licenses, in addition to allowing AGPL-licensed use in free software. If you have specific needs that require a commercial license, you should inquire about purchasing one.

I am not a lawyer, but my understanding is that because MIT-style licenses are compatible with the GPL, it is possible to have a mix of MIT- and GPL-licensed code within a single project.

[ThiefMaster]

Yeah, like I said in my 2nd paragraph, I completely understand that he wants to make money with usage of the library in non-free software.

As far as I know the mix only works the other way round: you can use more permissively-licensed code in your GPL application, but not GPL code in a permissively-licensed application - which actually kind of makes sense, since otherwise you would just write a thin wrapper for the GPL lib, put it under BSD, and then use it in your closed-source application, dodging the initial point if the GPL.

[bjmc]

I meant to have a link in my comment (now edited), but it seems that because permissive licenses don't conflict with the GPL, it's acceptable to have specific files or submodules under, say, a BSD license even if the "work" as a whole is GPL-licensed.

The way I read that, if I wanted to make a BSD-licensed application that used authlib, I'd need to license the whole project as GPL (so as you say, it doesn't become a way to dodge the GPL), but then all of the individual source code files that I wrote, I could license under BSD, and anyone who wanted to could take and use/modify them under the terms of that license.

You might be right that other projects won't want to jump through all the hoops of maintaining differently-licensed code in the same repository, but it seems to be allowed legally, at least.

[bjmc]

Honestly, if you can afford it, you probably want to talk to a lawyer who specializes in this area.

[ThiefMaster]

Unfortunately I don't know a better alternative to the AGPL either... anyway, let me explain our usecase:

We have a big open source application that's currently GPL, but we are considering to move it to MIT.

Most people just use it as-is, ie they install it on their server and that's it. No code modifications, no custom plugins, etc. But once there are people who write (private, closed-source) plugins for their own instance of the application, this is problematic with the GPL: They now have GPL and proprietary code running in the same process - something that is considered a gray area (as probably best known from certain proprietary linux kernel modules). A permissive license avoids such problems.

Anyway, if we were to add authlib (to replace our current flask-oauthlib based oauth provider) and change to MIT, this would probably be in conflict with the GPL license.

[bjmc]

If the plugins are privately used in-house, I'd be very surprised to find that GPL copyleft provisions attached in any way. Most of the GPL rules only come into play when distributing software. (The AGPL is different from the GPL in what it regards as "distribution")

Maybe you just have users with skittish legal departments?

[traverseda]

Despite "more code than ever" being open-source, most users still interact almost entirely with proprietary software in the form of closed-source web apps. That is explicitly what the AGPL was created to prevent.

If a plugin author wanted to dodge the AGPL on their own deployment, they could either disable the authlib module entirely, or pay for a commercial authlib license. The project that links against authlib should be able to be under whatever (gpl-compatable) license it wants, but of course the whole project is treated as AGPL if they did include authlib support, and they didn't pay for a commercial license.

With the caveat that I am not a laywer, and that that's just my understanding of the situation.

That's why this kind of licensing scheme exists, so that you can't write proprietary software without paying money. That is the explicit goal of such a system.

[evilham]

First of all: kudos, docs are very good and the interfaces look usable, I considered starting a Twisted server implementation and then checked the license, so I ended up here :-p.

Just wanted to add three things:

1. "enterprise software" is not an antonym of Open Source Software, there are many things in between, from a pragmatic and philosophical viewpoint.
2. the nature of OAuth (and therefore Authlib) means that OSS that uses it for authentication, as could the case of Indico, can basically not work without it and therefore that the whole thing would need an AGPLv3-compatible license, which, as they mention on the blogpost linked by @ThiefMaster, means that any Plugin needs an AGPLv3-compatible license (several projects have reached the same conclusion before).
3. Solving that is not as simple as "the project/plugin developer paying for a license", since the license itself is not transferable, that means that anyone who wishes to use a non-AGPLv3-compatible plugin must get an Authlib license. However, since Indico itself would have to be AGPLv3-compatible, they'd need to provide some kind of exception as well.

As you can see, things get muddy quickly :-D.

I just point out that for any "enterprise software" the security mailing list and support are must haves.
That and probably having some kind of attribution requirement if not licensed should be enough to get companies to pay for Authlib, while actually allowing for more freedom to library users than with AGPL.

There are licenses available for this, but IANAL :-p.

On that note, I always considered GPL/AGPL to be good for full-blown software. Libraries and frameworks... Not so much.

[xen]

AGPL and whole GPL license family is a terrible choice. I'm looking for a long time to find something to replace python-social-auth in some of my projects. But restrictions and mad nature of the GPL license stop me from using authlib in my personal projects. I wish you will consider to switch to something more permissive.

[evilham]

@lepture is open to it, but, understandably, everyone has better things to do than looking for a good license :-D.

Something like a "Lesser AGPL" would be kind of perfect for something like authlib, but AFAIK it doesn't exist.

Maybe someone with better knowledge of these things will come around and suggest it.

[xen]

@ThiefMaster thank you for pointing to license issue.

I'm switched to flask-oauthlib, the transition was smooth and fast. I didn't make authlib work in my project for 2 weeks, constantly fixing bugs. This is another issue not related to the topic, but if you have any doubts about what to chose it took only 4 hours to switch to flask-oauthlib. And it works perfectly out of the box.

Besides that, I'm still grateful for @lepture for his amazing work on both projects.

[traverseda]

@xen , consider buying a commercial license then?

[orklann]

@lepture Take a look at these two articles which explain the main difference between a few general licenses.

開放源碼授權概觀（上）
開放源碼授權概觀（下）

[traverseda]

One thing I would very much recommend @lepture is having very clear licensing costs available. If I was to build a product on this, I need to know the upper bound of how much it's going to cost ahead of time, and I need a commitment that it's going to stay at that price for at least 5 years, as of when I sign the contract.

You might consider something like "$0.60 per paying user, per month. Volume discounts available" which is in-line with the pricing of many SaaS products, and puts a hard upper-bound on cost. It should be compatible with most SaaS business models, although it they're providing a small service that only costs ~$2usd per month, instead of the usual $4-$8usd, they would definitely need a cheaper rate, and you should give them one.

[Lawouach]

Those misunderstandings are usually why I prefer permissive licenses. I assume people don't steal code (it's so easy to get caught and bad press). Even if they do, I wouldn't be able to afford a layer to attack them anyway.

But to the majority of users out there, they just want to enjoy your code. Sure they may never pay in, but that might be the case even with dual licensing based on a GPL variant. Permissive licenses are simpler for all intended parties.

Then again, for a webapp, as we are creating, it may be the right choice, and if we want to stick to authlib, we wouldn't have any other choice anyway. Again, if my project was a pure library, that would suck tremendously in my book but perhaps less so with a webapp.

[traverseda]

The pricing is pretty clearly stated here.

Thanks, it's been a while since I looked at that.

[Lawouach]

Uses, contributes or distributes?

Those have distinct impacts on your own stuff for sure. You can use internally, as far as I know without obligations. If you contributes, you keep your copyright on changes and actually have more visibility on what can be done with your changes. Distributes, that's the only one where I can see how that's an issue for the viral aspect.

[JonathanHuot]

@Lawouach: for example, as a SaaS company, you can't have a custom authlib server without distributing source code to the users, even if hosted internally. Sometime the custom additions can be submitted to the authlib community, sometime it is strictly confidential and cannot be shared.

[Lawouach]

@JonathanHuot So, it's indeed the distribution issue. That I can appreciate it is a difficulty for many. We made our choice to open source our products so that's not really a pb for us as our changes will remain OSS as well 📦

@lepture wow, thank you so much for the understanding and being flexible on this!

[traverseda]

Kind of defeats the purpose, doesn't it? Since it wouldn't incentivize SaaS products to pay for a license?

[arikfr]

It's probably worth lining to the discussion about Commons Clause going on HN, to give another perspective on this: https://news.ycombinator.com/item?id=17818407.

[traverseda]

@arikfr

Thanks for pointing that definition of "sell" out to me.

will be happy to buy a commercial license if the switch is made.

Why don't you want to buy a commercial license if this is AGPL?

[arikfr]

Mainly because AGPL is viral, which means that we will need to change the license of our open source project (Redash; BSD).

[traverseda]

@arikfr , unless I'm misunderstanding, you'd need to change the license to "common clause" as it's also a viral-license.

[lepture]

This seems a quite new license. I'm not sure if I will switch to that license. My plan is going to split Authlib into 3 modules, core, client and provider. The core and client will be licensed under BSD.

@arikfr redash only needs the client part, which will be BSD, you don't have to buy a commercial license.

But for now, I will focus on developing new features. Authlib will continue as a monolithic project so that I can design a better API.

[Lawouach]

Hey @lepture, great to hear!

Out of curioisuty, would you say loginpass remains AGPL too then?

[arikfr]

@traverseda good point. I think that as long as we don't "sell" (as defined by the Common Clause license) the open source Redash, we're covered by the base license (Apache?) which is compatible with our current license (BSD). It's actually not clear what happens when someone wants to "sell" their Redash fork or just host it.

@lepture thank you for the clarification and willingness to do the license changes!

[Lawouach]

Wow, what a great way to start the year! Thank you @lepture!

[venthur]

Excellent choice, thanks!

Happy new year!

[lig]

@lepture so, is there any eta or backlog for 0.11 release?
Or it would be nice to have just a relicensing release before that. I'm sure there are a lot of folks out there who would be happy to start using authlib is it is now in 0.10 if it is released under more permissive license.