AGPL?! #59
Comments
|
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. |
|
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. |
|
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 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. |
|
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? |
|
Honestly, if you can afford it, you probably want to talk to a lawyer who specializes in this area. |
|
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. |
|
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 |
|
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. |
|
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? |
|
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. |
|
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:
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. 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. |
|
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. |
|
AGPL and whole GPL license family is a terrible choice. I'm looking for a long time to find something to replace |
|
@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. |
|
@ThiefMaster thank you for pointing to license issue. I'm switched to Besides that, I'm still grateful for @lepture for his amazing work on both projects. |
|
@xen , consider buying a commercial license then? |
|
@lepture Take a look at these two articles which explain the main difference between a few general licenses. |
|
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. |
|
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 :)
|
|
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. |
|
The pricing is pretty clearly stated here.
It doesn't include a guarantee for N years, but it's a brand new project anyway. |
|
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. |
Thanks, it's been a while since I looked at that. |
|
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 |
|
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. |
|
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. |
|
@Lawouach: for example, as a SaaS company, you can't have a custom |
|
@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. |
|
@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! |
|
Just discovered this: https://commonsclause.com/ Maybe it could be an interesting alternative to AGPL? |
|
Kind of defeats the purpose, doesn't it? Since it wouldn't incentivize SaaS products to pay for a license? |
|
Came back to this thread to post a link to Commons Clause too :-) @traverseda Commons Clause defines sell broadly enough to include SaaS:
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. |
|
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. |
|
Thanks for pointing that definition of "sell" out to me.
Why don't you want to buy a commercial license if this is AGPL? |
|
Mainly because AGPL is viral, which means that we will need to change the license of our open source project (Redash; BSD). |
|
@arikfr , unless I'm misunderstanding, you'd need to change the license to "common clause" as it's also a viral-license. |
|
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. |
|
@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! |
|
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 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. |
Issue: #59 Official Blog: https://blog.authlib.org/2019/switch-to-bsd-license Personal Blog: https://lepture.com/en/2019/authlib-bsd-license
|
Authlib will be licensed under BSD from v0.11.
I'm accepting donations and sponsors via Patreon now: https://www.patreon.com/lepture |
|
Wow, what a great way to start the year! Thank you @lepture! |
|
Excellent choice, thanks! Happy new year! |
|
@lepture so, is there any eta or backlog for 0.11 release? |
|
v0.11 is released. Authlib is under BSD now. |
Issue: lepture/authlib#59 Official Blog: https://blog.authlib.org/2019/switch-to-bsd-license Personal Blog: https://lepture.com/en/2019/authlib-bsd-license
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.
The text was updated successfully, but these errors were encountered: