AGPL?!

[ThiefMaster]

I just realized that this library is AGPL-licensed - quite unexpected considering that its predecessors like flask-oauthlib and oauthlib are BSD-licensed, and e.g. flask-oauthlib strongly recommends people to authlib instead.

While I completely understand that you want to make money with this library when people use it in commercial/closed-source software, the fact that it's AGPL and thus very viral seems problematic:

For example, many open source projects nowadays use a more liberal license like MIT or BSD.
And while IANAL, I'm pretty sure any such projects are currently excluded from using your library, since you cannot use GPL software in MIT/BSD-licensed application...

...which this is truly unfortunate, since AFAIK there is no other decent implementation of OAuth providers for Python out there - and many webapps do include OAuth provider functionality nowadays! And we all know what happens when people start implementing their own security code... usually it won't be as secure as it should be.

[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.

[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?

[bjmc]

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

[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

[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.

[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.

[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.