The AGPL is an underrated licence. It solves the problem of $bigCorp taking free software, making significant improvements and then renting network access to that improved version without providing their changes to anyone. That's unfair.
This has generally turned out to be a problem very few people have.
In practice, $bigCorp is happy to publicize all of the changes they make to this software.
They can then focus on out-competing anyone by offering a cheaper and/or better integrated managed version then the original creators can. This is explicitly why Mongo moved from the AGPL to a custom non-FOSS license; Elastic followed suite and skipped the AGPL altogether for a similar license.
Overall, $bigCorp love having any changes they make in upstream: less maintenance burden on them for the parts that are not in their direct business, more time spent on working on their value-adds.
I'd argue that the GPLv3 is even obsolete. If you don't care about third parties using it in proprietary software, use LGPLv3 or Apache 2.0. If you do care, then a license that fails to apply that restriction to the dominant form of software today seems pretty underwhelming and you should go straight to AGPLv3 instead.
GPL is perfectly useful. It's just less useful for projects operating over the network.
Are you writing a library that you want to be kept open when used in a project? GPL will do what you need.
Are you writing an application where communicating over the network isn't a meaningful part of its operation? GPL will work fine.
Are you writing a library or application where communicating over the network is a significant part of its operation? Yeah you probably want to use the AGPL instead. Even then, depending on where it is running, GPL might still be fine. JS on a client? GPL will be fine. JS on a server? You need AGPL.
Really it comes down to:
Does the user interact with this software with a network between them (i.e. user <--> ??? <--internet--> software)? If yes AGPL, if no GPL.
Sure but for a lot of libraries that just doesn't make sense. Like I get that you can give any library an RPC and call it a day but with 90% of the libraries I work with on a daily basis, requiring that you call it over the network just adds unnecessary complexity, kills ergonomics of use, and adds latency.
As an engineer I'm not going to use an RPC to do an FFT, populate a native UI, access some device, or manipulate a datastructure. Instead I'll just use a tool/library that does what I need while staying in the application's address space.
The disconnect I think is that I work on a lot of embedded software and native applications. In the world I am in, the hoops needed to allow a library to bypass the GPL just mean that I'm not going to use that library and that I'll do everything in my power to keep leadership from using projects with that kind of pointless failure mode.
The same goes for web apps though. If it's delivered to the client and executed by the client, it can just be GPL. They have a copy of the code and are running it. They already have to have access to a copy of the source. AGPL provides no additional protections here.
AGPL has it's place and that place is server side software. If you are writing software that the user directly interacts with and that is running on hardware the user can physically touch, the AGPL provides you no added benefit. If that's not the case, you should certainly feel free to step the license up to AGPL but there's no reason to artificially complicate license compatibility when you already know that it wouldn't be feasible for a user/developer to use your software without complying with the GPL.
> Are you writing a library that you want to be kept open when used in a project? GPL will do what you need.
I'd argue it doesn't, really. GPL means it can only be used in software released under the GPL, or any network software (ie: web application) including proprietary.
Specifically, a proprietary vendor can use and/or modify your GPL-licensed library on their server-side application and is not obligated under the terms of GPL to release any changes, so long as they never distribute the app.
I'd argue using GPL for libraries is a good way to not get much usage. Every place I've ever worked has avoided GPL like the plague -- for startups it's a barrier to pivoting (eg: selling an on-prem version) and more importantly to being acquired, and any bigger companies have policy around it.
On a personal level I also tend to avoid it unless it's either the only choice, or I want or already have released under the GPL.
In general, given two library choices where one GPL and the other is MIT, I'm an order-of-magnitude more likely to pick the MIT one, even if it's lacking features compared to the GPL one, and even contribute the missing features. I suspect I'm not alone in this.
> Specifically, a proprietary vendor can use and/or modify your GPL-licensed library on their server-side application and is not obligated under the terms of GPL to release any changes, so long as they never distribute the app.
Sure but if it doesn't make sense to use that service remotely, then just use the FOSS one instead. If the expected behavior is that the software you are writing will be running on a computer the user directly interacts with and can physically touch, it's probably fine to use the GPL.
Web services and web libraries are a whole different ball game but I'm not going to use a GUI, signals analysis/transform, data structures, CUDA, hardware interface, or other common local library if I have to call it over a network. Doubly so if I now have to fight with an RPC endpoint instead of a DSL or library in my native language.
And when I say GPL, there are a handful of different flavors. I generally think GPL+linker/classpath is a fine choice for most projects that are geared towards commercial use. I'd say LGPL is fine too and it is but there are some small differences between GPL+LE/CPE and LGPL. So for the sake of simplicity, "just default to GPL unless you have a good reason to increase or decrease the copyleft-ness".
> Are you writing a library that you want to be kept open when used in a project? GPL will do what you need.
> Are you writing an application where communicating over the network isn't a meaningful part of its operation? GPL will work fine.
This might be the case - although I agree with the sibling comment that a lot of libraries can be "artificially" turned into network services.
But regardless, what's the downside of using the AGPL? It's GPL + some additional restrictions, and while those restrictions can sometimes be irrelevant, I can't think of how they could be harmful to a GPL project.
AGPL feels like overreach: the software runs on someone else's machine. AIU AGPL was problematic for proprietary versions of Mongo and Elastic, does it have proper free software purpose? SaaSS is inherently nonfree: you're not going to self-host AWS, google, dropbox or github.
counterpoint: At the end of the day, I just want people to use my stuff. Right now, 99% of what I write ends up MIT because I just want the shortest and most permissive license for others to use what I create without bothering me.
Not to discount the feelings of others, but in a sense I only wish I could have these problems.
counterpoint: At the end of the day, I want people to use my stuff, but not grab and run with it, claiming ownership of it, depriving future users of the freedoms in exchange for improvements.
I don't care about monetization or $BIG_CORP's fascination with it. I developed this thing to stay open. It's not up for grabs.
> counterpoint: At the end of the day, I want people to use my stuff, but not grab and run with it, claiming ownership of it, depriving future users of the freedoms in exchange for improvements.
If your stuff is complex enough, then it should be easy to outcompete any improvements made by organizations. SQLite, for example, has multiple proprietary tests [1]. Corporations can try to improve on SQLite, but without these tests and the knowledge of Richard Hipp on their side, it will most likely fail.
“SQLite is a successful open source project thanks to the fact that a significant chunk of development infrastructure isn’t open source” isn’t a great argument regarding the sustainability of open source… If Richard gets hit by a bus, and the community tries to keep the project alive according to free and open-source principles, then they’re going to face all the same barriers that a corporation would :/
> “SQLite is a successful open source project thanks to the fact that a significant chunk of development infrastructure isn’t open source” isn’t a great argument regarding the sustainability of open source…
To maintain open source over a long period of time, some durable competitive advantage is probably required yes. With such a moat, competitors can be beaten. Luckily, being open source is also a small moat since it avoids vendor lock-in and some businesses need vendor lock-in to survive (I'm looking at your SAP).
> If Richard gets hit by a bus, and the community tries to keep the project alive according to free and open-source principles, then they’re going to face all the same barriers that a corporation would :/
The project sits inside Richard's company and the company has some other engineers working there.
> MIT doesn't allow no corporate to claim ownership on your software,
Nor requires them to give anything back.
Putting your code in MIT license is basically slogan "take all of it and give nothing back". Which is why so many corporate developers push for it, no lawyer to talk to when you take MIT-licensed code to use in your project.
> much unlike open-core GNU licenses that promote CLA-s and thwart any competition.
There are no "open core GNU licenses". It is just perversion of the idea and abusing the fact some of them are not restrictive enough that you can still have paid parts that are closed source
The copyleft licenses don't require to give anything back either, they only require to give source code forward to downstream users, who may or may not contribute back upstream to the original project.
Most commercial products just write some useless statement like "this software may use open source components" or include a generic MIT license without the original copyright holder statement inside.
Who is telling these companies they are doing it wrong?
Yes, reviewed it professionally. Despite their effort, can tell you that it is still incomplete and innacurate.
These kind of things take several months of efforts by deep expert, when it is done by normal open source developers who think they know about licenses and compliance, it tends to result in poor results even if the output looks "big" from a surface view.
The copyleft licenses don't require to give anything back, they only require to give source code forward to downstream users, who may or may not contribute back upstream to the original project.
At least, you keep the source code in the open, and the changes stay in the open. It's giving enough, when compared to BSD/MIT and similar "permissive" licenses to fork away without making anything available.
No, the changes don't have to stay in the open, they only have to get given to your downstream users, not publicly in the open and not back to the upstream project. You can definitely fork a GPL project without making anything public, although your users can choose to make the modified code that you send to them public, but they might not ask for it or might not publish it if they do get it.
It possibly depends on your project. If you're running a password manager business, it makes little sense to provide all your source code to a competitor to enable them to build upon your project, make money, and not provide any of the code changes in return.
You will feel different when some giant enterprise takes your shit, locks it up and never contributes any improvements back. Or maybe you would not. I definitely would :)
And then use your lack of not wanting to prioritize free work for corporate daddy as evidence that the project has stalled and a "community" fork is necessary.
I use MIT for "whatever random crap I wrote that someone else might find useful" and GPL/AGPL for "actual software I'm developing for longer time and maybe want contributors to"
I actually find I feel differently for different projects. For smallish things that I made for myself, are useful but not particularly complicated -- things that someone else could easily replicate in less than a day -- I often license them MIT. Partly this has come from using so many other people's permissively-licensed packages in golang.
But for larger, more complex projects that have significant skill -- projects that might take man-months to man-years for someone else to replicate -- I tend to want to use copyleft licenses.
> counterpoint: At the end of the day, I just want people to use my stuff.
And its unsustainable model of development. You need contributions and developers willing to help with maintenance and development otherwise your project will stagnate and no one will use it(xfree86).
I see only one case for permissive licence use, a reference implementation of something. Where it's purpose is for people to take it and incorporate it into their codebase without any changes(or minimal). It have problems with vendors taking source and extending it with their secret sauce(Unix wars, Kerberos(?)) but advantages are greater than potential abuse.
Maybe also a case when you drop code and run in other direction(with no or minimal maintenance). It's not great development process either.
>Right now, 99% of what I write ends up MIT because I just want the shortest and most permissive license for others to use what I create without bothering me.
You still need a lawyer evaluate any licence even short ones. Short ones have problem that they leave more to interpretation/relie more heavily on copyright law/patent law/their interpretation can widely differ based on jurisdiction etc.. So while they can be shorter, interpretation can be as hard as long ones. Especially if copyright owner is hostile.
> Not to discount the feelings of others, but in a sense I only wish I could have these problems.
You started comment with desire for others to use your software. But people won't use it if it's stagnating, lacks features or is unreliable. Especially if proprietary fork covers this problems. To stay relevant you need contributions and development time. And getting contributions can be hard if licence doesn't enforces giving back.
The issue is that people won't use my stuff because the licence is viral and requires them to relicense just to use my code, even if my code is 1% of their codebase and they spent years of tedious effort making their IP. To me this is an onerous requirement.
On the other hand, if they take my code and make some changes to it, and then sell access over a network, I want those changes to be brought back upstream.
So to me, something like ALGPL (does that exist?) or A-MPLv2 would be ideal. Then again, I mostly write computer vision pipelines, which are very much on the library side.
Have you considered using zlib license instead of MIT? Because if people "just use" MIT licensed stuff, they must include the license code. With the zlib license they only need to do that if they fork the source code.
There may be some confusion about which MIT license we are talking about as there is more than one that originates from MIT or has MIT in the name.
When people refer to "MIT License" they usually mean the Expat License:
> Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
> The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
People should be able to do whatever they want with the fruit of their labour, even publish software as public domain and not care if corporations want to make money off it.
Who are you to tell them they are acting like a scab? Live and let live.
You argued for your rights, and I reminded you others have rights as well (because it seemed you had forgotten).
You're a scab if you work for free, replacing a worker that would have been paid otherwise. If you get paid for your MIT licensed code, you're not a scab :)
Because copyleft code benefits society as a whole, and the benefits remain around. Non-copyleft mostly benefits companies that are free to use instead of hiring someone to do it, or pay the authors of the GPL code for a proprietary license.
If we are going to throw words at each other, I could equally throw zealot at you. That sort of attitude tars the rest of us, so you are damaging the reports of the things you seek to protect.
I'm a fan of AGPLv3, for the reasons you state, but throwing insults at others for having a different preference just makes you look dickish and by the indirect inference of outsiders makes other AGPL proponents look dickish.
Please stop posting flamewar comments, especially of the ideological sort. You've done it repeatedly in this thread, and in other places recently. We have to ban such accounts, regardless of which ideology they favor. It's not what this site is for, and destroys what it is for.
Yeah, most companies won't touch copyleft licenses at all due to the impact it has on their own licensing, regardless of the issue of contributing back. I guess LGPL is an exception, but most legal teams I've seen ban that too.
In practice, I'm not sure it has much effect on how many developers are hired though. If they could have used it, they would just use their existing developers to build something else. If they can't, they will use them to build that functionality, sure, but I don't think headcount would increase. They would just build slightly less capable products. Their competitors are in the same position after all.
> I'm not sure it has much effect on how many developers are hired though. If they could have used it, they would just use their existing developers to build something else.
Yes. But while the developer build the something else, they can't build the original thing. So the company either hires more people or keeps the current people on the payroll for longer.
It's a simplification, but I guess we can agree that if a person is reimplementing GPL licensed code, they won't be implementing something else in that same time?
> They would just build slightly less capable products. Their competitors are in the same position after all.
Unless the competition starts to say that they will release their products under GPL license. Then they have a gigantic upper hand, and society gets that free software as well.
So in the end releasing MIT licensed software as an individual has only downsides for the person doing it (unless they have the fetish of the download counter spinning faster).
It's certainly one perspective. For some types of software it may make sense.
I generally release software under the BSD license. My goal is to allow the widest possible use with as few legal restrictions as possible. I have no moral objection to companies using my code, building on it and not contributing back, if that is what they want to do. I like seeing my stuff used and benefiting the maximum number of people.
So far, everyone who had used my code has contributed back. Most people don't want to maintain forks and their own patches.
My stuff isn't that strategic I guess. Just useful.
I like the AGPL in theory, but the confusion about how immediately you have to convey a copy of the source is not great. I find the requirement some people read from it that any running piece of code must be able to spit out its source code from the same network service very annoying (as I find the people opening issues for your supposed noncompliance with this asinine requirement - even if you are the sole copyright holder - are very annoying)
Making software available over a network for interaction does not seem to constitute distributing the software. So, no, it does not cover this situation.
There could be an argument that the JS frontend that gets sent to the client over the network is part of the software, depending on the project's structure
If I give you a webpage like this comment box in which you give a command line to run a GPL tool (e.g. ffmpeg built with --enable-gpl) I do not need to give you any source code because I am not distributing that tool. That applies to more complicated interfaces and even if I were to link libavcodec into the web server because I am not distributing the tool.
No it doesn't, at least not for e.g. a database which the big corp provides a vanilla version of. Say elastic search was AGPL. Any fixes to the engine would need to be made available to the users. But management console and most of the infrastructure wouldn't. AGPL is not viral across network.
The AGPL is a stupid licence. If you use anything over a network you are using someone else's computer. Of course the code that runs on your end should be open source, but having the server's source code is useless since you cannot verify they are truly running what they claim they do.
Do you have a right over someone else's computer? Maybe we are talking about government servers and you could argue they are public property so AGPL could be needed, but private companies?
The AGPLv3 network clause is triggered on modification, so if you don't modify the code, you don't have to redistribute the source code.
The copyleft licenses don't require to share the source code publicly, they only require to give source code forward to downstream users, who may or may not contribute back upstream to the original project. In the AGPL case, that would be only users that you let have network access to the modified AGPL software.
> The AGPLv3 network clause is triggered on modification, so if you don't modify the code, you don't have to redistribute the source code.
Well, you're running the upstream software in that case, so you don't have to share anything, which is logical.
> The copyleft licenses don't require to share the source code publicly, they only require to give source code forward to downstream users...
Well, if you're distributing the software to downstream users via network, you need to share the source code via network. It's also logical and straightforward.
You can't tell that it's GPLv3 and binaries are here, but I won't give you the source. You have to.
If we were in 80s, I'd happily mail you a check and envelope to mail my floppies. One optional set for binaries, and one set for the source.
Sure, you have to share the source code via network, but you don't have to share it publicly, only to people who are using the software over the network, which might be just your customers not everyone on the planet.
The GPL tells me I have the freedom to run your code however I please, and I should release my modifications only if they run on someone else's computer and they request the source code.
Since the code only runs on my server then no user has the right to request the source code. This is why AGPL is a dangerous extension to the GPL
How is that dangerous? You have the freedom to run or change the code however you like, but if you use the software to provide service to users over a network, then you must share any modifications you make to that software.
In other words, whether you let me download and run the software locally, or you let me run the software remotely on your server, you always need to provide the source code.
Don’t like these conditions? Then don’t run the software. No one is forcing you to run it.
"Remote running" is not a thing. It's my server, you are not running anything except the client application. Every single bit of code is running on my computer and you are not entitled to know more other than the API you are using to talk to it.
The AGPL is dangerous because it redefines the meaning of "running" a program by extending it beyond your own devices. Of course the AGPL can have its uses as I already explained, but it should not be considered a free license
Well, don't license the code you write with AGPL, then, or don't use code licensed by AGPL. Clearly there are people who don't share the same viewpoint with you, and use AGPL license.
Yes, the GPL and the AGPL are two different licenses, that’s… the point.
“The AGPL includes additional [requirements for businesses / freedoms for end-users] which are not included in the GPL” is a feature, not a bug.
If as a software author you want companies to sell access to your software, but without sharing the source code, use GPL. If as a software author you want companies to sell access to your software with sharing the source code, use the AGPL.
If you’re running a company whose business model is “sell access to open-source software”, then it’s up to you if you want to build your business on top of GPL or AGPL software, and if you don’t like that license, you don’t use that software.
The AGPLv3 network clause is triggered on modification, so if you don't modify the code, you don't have to redistribute the source code.
The copyleft licenses don't require to share the source code publicly, they only require to give source code forward to downstream users, who may or may not contribute back upstream to the original project. In the AGPL case, that would be only users that you let have network access to the modified AGPL software.
This seems like a reasonable set of requirements to me.
It's not an "extension". It's a different license that doesn't give you the right to run the code on your server, unless you share the sources with the users.
You are free to implement it yourself instead of using someone else's AGPL code.
It's Daniel's code (well, I guess and all those contributors, too) and thus can license as they see fit, but the whole idea was to have an alternative implementation. If Bitwarden had heartburn about a lighter-weight GPLv3 implementation existing, they're in for some bad news because there are currently 1200 forks still on the GPLv3 license
I doubt very very seriously that there is overlap between the audience who runs Vaultwarden and those who want to start up a company that sells Vaultwarden as its backend to compete with Bitwarden
Now that they are venture funded, Bitwarden will try to restrict competition as much as they can. It's a familiar playbook. I wouldn't be surprised if Bitwarden has applied pressure behind the scenes on Vaultwarden to move in this direction, since the AGPLv3 license will make competition less likely (and VW shortsightedly even says as much). They're learning from Chrome/Chromium and others.
> I doubt very very seriously that there is overlap between the audience who runs Vaultwarden and those who want to start up a company that sells Vaultwarden as its backend to compete with Bitwarden
Company selling password managment as a service might use the code to give their customers migration path to their service
The AGPL doesn't necessarily mean folks who create forks of Vaultwarden have to contribute back. They just have to make the source available to users of the service, it doesn't require them to PR their changes to the Vaultwarden repo or make the source available for non-customers (if the service isn't publicly accessible).
This may seem like splitting hairs but it's an important distinction.
If we're close to splitting hairs though, users includes everyone who ever hits any of its endpoints. It doesn't matter who has credentials - the license does not discuss "customers" and "non-customers". It says:
The GNU Affero General Public License is designed specifically to
ensure that, in such cases, the modified source code becomes available
to the community. It requires the operator of a network server to
provide the source code of the modified version running there to the
users of that server. Therefore, public use of a modified version, on
a publicly accessible server, gives the public access to the source
code of the modified version.
If someone can reach the server, you agree to give them source for everything involved in that servers operation that is covered under "corresponding source". That includes linked, executed and networked programs that integrate with any custom patches to provide features:
For example, Corresponding Source
includes interface definition files associated with source files for
the work, and the source code for shared libraries and dynamically
linked subprograms that the work is specifically designed to require,
such as by intimate data communication or control flow between those
subprograms and other parts of the work.
Apologies if my comment came across as passing judgement, since I now have a policy of trying very hard to stay out of discussions about the merits of AGPL. I merely meant that the linked PR says it "solves" an issue, but when I went to the issue the "discussion" was only a "GitHub discussion" and not a discussion
Although it is fascinating to see the discussion was opened "May 3, 2022" and this is the first I've heard of the relicense effort
Don't worry about it, my comment was about the GH discussion. They listed "providing back to the community" as one of the reasons for the switch. Sorry!
I'm a big supporter of permissive licenses, but I have to admit this seems like a very responsible and well-thought-out approach to relicensing the project to me.
I think AGPL is quite poor license choice, it does not really offer protection (ask them why they went from AGPL to SSPL) but introduces friction with compatibility and legal folks in many organizations.
Does SSPL work in practice with anything? Last I heard you can't run SSPL-licensed software with Linux (you can't re-license Linux as required by SSPL).
is there an AGPL-like license built on top of GPLv2 and not GPLv3?
I really like the philosophy behind GPLv2 and the AGPL - both focused on making sure code changes get redistributed. But im not keen on the anti-Tivoization requirments .. i feel its an overstep and i find the linux kernel arguments for v2 convincing
There was AGPLv1 by Affero in the pre-GNU days but it is incompatible with GPLv2 software. So it has the similar lack of anti-tivo clause but you can't use GPLv2 dependencies.
AGPLv3 software is only able to use GPLv3 dependencies because GPLv3 explicitly says so, otherwise it would be incompatible from the terms of the GPLv3 preventing further restrictions.
And for completeness AGPLv2 was basically just a modified version of AGPLv1 that let you upgrade from AGPL licenses published by Affero Inc to those published by the FSF
Oh okay, I think I see the problem. GPLv2 wouldn't allow for something like that b/c it'd be introducing an extra "restriction" (forcing more people to disclose code than plain GPLv2) - while GPLv3 was designed with such an extension in mind.
Thanks for taking the time to spell it out :) I somehow always missed this subtlety.
So hmm. If I'm running an AGPLv3 Vaultwarden and then somebody connects to that using the official Bitwarden client, am I responsible of providing the Bitwarden client source code -- or if I cannot do that, I'm technically violating the license?
How did you arrive to that conclusion? If you are running AGPL3 Vaultwarden then you are only responsible to give source code for Vaultwarden (or just point to the upstream sources, if you did not modify it). Why would you be responsible for code you did not distribute running on a computer of someone else?
It comes down to how much you trust the FSF. If Stallman was finally booted and the new leadership decided to make AGPLv4 which was basically LGPL, you'd have a much more complicated legal battle if you wanted to stop someone using your software under those terms, as you're not arguing intent and reliance and other subjective areas instead of relatively simple copyright infringement.
At the same time if you go AGPLv3 only, accept external AGPLv3 only contributions and then FSF releases a AGPLv4 that you feel matches your intent better, then you'd have to do a complicated relicensing process requiring you to get consent from all contributors or rewrite/remove their contributions.
The third option is AGPL + CLA but plenty of people are rightfully suspicious of this now many companies have used this to close software moving to source available licenses like SSPL or just flat out proprietary like Emby.
There is also an issue of hostile-ish fork. If you release something as (A)GPLv3-or-later, anyone can take it, and extend/change it. However, those changes can be done under (A)GPLv3-only. That would prevent you from incorporating them into your version (unless you also re-license to (A)GPLv3-only), while they still could merge anything you add.
In general (A)GPLs care about user freedom, not a developer freedom. So this is not seen as a flaw. I personally prefer using -only variants, since it seems to strike reasonable balance in this regard.
> While I don't object to changing the license, I think a few things mentioned in the intro are not quite true and should be clarified.
> > To be clear, this will not effect any (end)user or any self-hosted environment which you share with your family and friends.
> If you make your Vaultwarden instance publicly accessible, then there is a reasonable expectation that anyone could interact with it (if only to load the login page), so if you've modified any of the Vaultwarden backend (e.g., custom templates or graphics that get built into the binary), I believe you would technically be obligated to "prominently offer" the source. In practice, that would probably mean modifying the web vault login page with a link to your source.
> > This will only have an effect on companies that build proprietary tools using Vaultwarden code.
> As mentioned above, this also affects non-commercial users who have modified the Vaultwarden code.
> > This is also more fair towards Bitwarden, since currently the GPLv3 license of Vaultwarden could allow other companies to compete with Bitwarden, which is not something we want.
> While this may prevent deep integration of Vaultwarden with a company's other products, they are still perfectly able to provide standalone instances, even with some customizations (as long as they make the modified source available), so I don't think this change would have much effect on most MSPs who offer managed Vaultwarden services.
> Overall, AGPL has a limited ability to prevent third-party competition with the original product, as can be seen with Bitwarden's shift towards a non-open-source ("source-available") license for key portions of their software.
—⁂—
Me, I’m not convinced this change is (a) desirable or (b) worthwhile, for the same reasons as jjlin, but I don’t oppose it either. As a teenager I was generally quite unimpressed by the GPL and deliberately avoided building with some copyleft things where possible, strongly favouring permissive licenses, but now I’m 30 and I’ve definitely come to appreciate the purposes of copyleft licenses a bit more, though I still largely prefer to work with permissive licenses.
(I prefer the Blue Oak Model License <https://blueoakcouncil.org/license/1.0.0>; on the licenses’ own merits, BlueOak-1.0.0 is roundly better than the likes of Apache-2.0 and MIT; the only practical imperfection of BlueOak-1.0.0 is that it’s not OSI-approved, largely because—simplifying perhaps past the point of strict accuracy—its authors used to work with OSI and are fed up with broken processes.)
What is wrong with people who spead fear about "non-osi" license as if that is equal to a proprietary one?
Suppose we talk about "sspl" which a lot of people hate for no reason. Many say "but it is not OSI approved" but I want to ask, does it violate any of the 4 freedoms? If yes then its not a free license, if it does not, then it is not a free license.
Same for your blueoak one, does it violate any of the 4 freedoms?
The line must be drawn, or else open source freedoms will be whittled away by a thousand cuts. The OSI takes the position that the SSPL is a de facto violation of the freedom to run the program as you wish, because it puts complex and far-reaching restrictions on what other software you can use with the covered software, and I'm not aware of any significant entity claiming otherwise.
>The OSI takes the position that the SSPL is a de facto violation of the freedom to run the program as you wish, because it puts complex and far-reaching restrictions on what other software you can use with the covered software,
4 freedoms is about freedoms of users. End users. you are talking about freedom of intermediaries that SSPL aims to restrict. As an end user, if you are using SSPL licensed software for your own use, will there be any restriction on you? if you integrate SSPL software into your product, will it be restricted? i dont think so. If you want to SAAS-ify this SSPL software, then only the restrictions of SSPL are triggered. Not in any other case.
if i use an MIT code as a "user" when i am an "intermediary" and repackage the same as a proprietary one, my "users" will be end users. they will get only proprietary code, rendering incapable of enjoying 4 freedoms.
This is the same thing. if your or your downstream end users' freedom gets restricted, that is a problem
Every single freedom ever has restricted the 'counterfreedom'. Freedom from slavery restricts your 'freedom' to keep slaves, freedom to live restricts your 'freedom' to kill, and so forth.
Perhaps I should have worded my reply differently. SSPL restricts your freedom to run the code as you wish. The AGPL does restrict your 'freedom to not share the code', but that is not one of the four software freedoms as defined by the FSF.
>The copyleft condition of Section 13 of the SSPL applies only when you are offering the functionality of MongoDB, or modified versions of MongoDB, to third parties as a service. There is no copyleft condition for other SaaS applications that use MongoDB as a database.
no question about it. You use it as a DB, you are clear. it only triggers when you want to serve as a SAAS
That's what they claim, they're not a neutral party and other people who've looked at it say it's not so clear. The FAQ is non-binding, the license text itself is what matters.
If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License
where does it say otherwise? it starts with "if" meaning only this condition has to be applied and for nothing else
> make the functionality [...] available [...] as a service
This isn't well defined is the problem. What they obviously mean is 'don't offer MongoDB as a service', but this could easily be interpreted far more broadly.
If you consider offering a complex, customizable piece of software (like Jira), where your customers can add custom fields and write custom queries, one could reasonably argue you're offering access to MongoDB under a different interface.
Imagine I'm running an MMO game where users can store arbitrary items in a stash, and then search for them based on various criteria. I would like to implement this stash as a Mongo DB instance for each user, and translate the user searches into MongoDB queries. Am I offering MongoDB as a service to my users, or using it as a DB?
Legal departments are generally conservative in what they will accept and allow. OSI approval of a license is a good indication that it’s sound. This fairly naturally morphed into OSI becoming considered guardians of the definition of “open source”. Legal departments will then, unsurprisingly, look askance at a license that claims to be open source but is not OSI-approved, being leery of the potential implications.
Yes, BlueOak-1.0.0 is clearly and unambiguously an open-source and Open Source license. Its absence of OSI approval is for administrative rather than content reasons. And yes, this does show part of the problem of what OSI has become. But it does mean that choosing BlueOak-1.0.0 adds more friction for some users than using the likes of MIT or Apache-2.0 (and that you may hear about it).
For me, I have a couple of projects I’m working on that will be exclusively BlueOak-1.0.0 (partly because they’ll be applicationy in shape rather than libraryy, and partly because I just want to promote use of BlueOak-1.0.0), but when working in existing ecosystems I currently tend to go for “BlueOak-1.0.0 plus whatever is customary in that ecosystem”, e.g. `BlueOak-1.0.0 OR MIT OR Apache-2.0` on Rust crates, or `BlueOak-1.0.0 OR ISC` on npm packages (JavaScript), simply because this will make my and others’ lives easiest. In my license information, I recommend using BlueOak-1.0.0 unless you have reason to choose another of the options.
(Fun consideration: single-licensing, dual-licensing, trial-licensing… uh oh, the word “trial” has way too many possible meanings.)
IANAL but has this been submitted to the OSI? I read the license and don't even see anything they'd even question. They list many licenses (https://opensource.org/licenses/) that they don't recommend. Is it just not used broadly enough to warrant their time yet? It seems fit for inclusion.
Definitely seems to fill the middle ground between "open source" meaning "sanctioned by the OSI" and "meet the open source definition OSD".
It has not—or else it would easily be approved. What the Blue Oak Council said in 2019 was roughly that they weren’t interested in submitting to the OSI because its procedures and policies were broken (based on having been involved with OSI in the past; and I gather there’s wide agreement to this sentiment to at least some degree), though they wouldn’t object if someone else did; and they did offer to submit it as a test case under some proposed new procedures, but nothing happened with that reform. Around the time of the publication of BlueOak-1.0.0, one of its authors wrote “Don’t Rely on OSI Approval (activist approval does not track practical needs)”: https://writing.kemitchell.com/2019/05/05/Rely-on-OSI.html (pity about the awful slug in the URL), which explains some of the problems with OSI.
“Trial” certainly has the “three of” meaning; it is merely very uncommon in most fields, probably because of the other, different-etymology meanings of the word trial and the potential for confusion. https://en.wiktionary.org/wiki/trial#Adjective_2
I used “single-licensing” because it felt best; I know of no customary term for it, because it doesn’t tend to need a term. I did also contemplate the alternative “sole-licensing”, sole perhaps matching dual.
I’d say “double-licensing” isn’t quite identical in usage to “dual-licensing”: “dual-licensing” is well-established as meaning an OR conjunction, whereas “double-licensing” has been used in some fields as an AND conjunction (that is, for regulation purposes, you must be licensed under two sets of laws in order to practice). I won’t speculate on how much this (important) subtlety is a matter of fundamental meaning of the words and how much it’s customary interpretation of an inherent ambiguity.
Isn't the main issue with the sspl that it requires the entire software stack, including operating system, to be licensed under the same license? Which makes it incompatible with running a service on most operating systems.
What specific problems do you have with it? Is it just that it closes a loophole that would let you avoid giving away the source code of your modifications?
I agree. People should do what they want with their own projects.
Real question: Has AGPL ever been tested in court? We know GPL has been effectively legally tested via the BusyBox and OpenWRT cases. Armies of lawyers from both sides went into negotiations "guns a blazin'" and GPL came out victorious. I wonder when and how the "A" part will be legally tested.
EDIT
Woah. Double hat tip for teaching me about "SaaS vs SaaSS" in that gnu.org link!
Note; I don't work for some big tech company and SaaS companies selling FOSS stuff is a big deal which I don't want to downplay. I'll also point out that when it comes to the GPL, you should view the FSF FAQs with some scepticism, they're dubious at best and wrong at worst.
IMO it's bad because the AGPL is more akin to a poison pill license. The few changes it makes to the terms of the GPL change it from affecting copyright permission assignment (you can redistribute & modify, but only on these terms) to becoming an EULA instead (you can use it, but only on these terms). On a pure ideological level, that violates freedom 0 (the freedom to use software however you wish).
Further complicating things is that the added clause is a royal mess description-wise. Like... do config files count? Am I supposed to now share my database logins to comply? The AGPL is poorly worded and doesn't address these things and it's an issue because it's a EULA and therefore dictates usage of the software.
Adding onto the pile, another issue is just... enforcement? We're talking here about software that is a remote black box; I could easily write a replacement for an AGPL program that spits out the exact same thing and deploy it without needing to pay a damn lick of care to the AGPL. Yet worse, I could also just deploy an AGPL thing and claim I did that. You can't prove it without investigating my servers directly. See the issue?
Finally, and this is just in general - it's not a tested license. The GPL is a decently tested legal license and it works. The AGPL has never seen the inside of a courtroom, which means it's very dubious which of the rights it purports to grant will actually hold up when put to the test (and which granted rights turn out to be unenforceable).
PS: Also one thing I forgot to mention is that the AGPL demands that network software source code is distributed immediately; ie. Your entire codebase needs to be a quine that can fit in a single HTTP request, which is quite the burden. Most people (including those who release AGPL software) don't do that and don't bother. There's a reason most AGPL "enforcement" is just "be nice" stuff.
This strikes me as no different from the GPL or any other license (api compatibility, how do you detect infringement, etc.) along with a tasty smattering of misrepresentation ("poison pill", "Your entire codebase needs to be a quine that can fit in a single HTTP request")
The difference is that the GPL is a copyright license. Basically, the four "software freedoms" as defined by the GPL are concerned with how copyright can be used by proprietary actors to artificially limit what users and other interested developers can do with software.
This is a noble goal and in spite of my personal misgivings wrt the FSF (and the GNU Foundation) being ineffective advocates for that goal, the GPL itself (as well as the LGPL, which is the same in spirit but does more or less away with the entire dynamic linking debate by just saying it's allowed) is a very good license.
The AGPL on the other hand mostly exists to combat the "SaaS problem", where the FSF was unprepared for the sheer amount of usage the internet would have. The... issue is that you can't combat the "SaaS problem" under copyright law without violating freedom 0; right to use it however I want includes running it on a server with no conditions outside of meeting the other three freedoms (none of which close the SaaS loophole).
The result is this rather confusing license that is a mix between a EULA and a copyright license, where the best interpretation of it is that it's an EULA and the worst is that with a fairly simple construct, a SaaS company can work it's way around obeying the AGPL.
I call it a "poison pill" because every lawyer worth their salt that I've seen talk about the AGPL has basically told people that it's probably safer and more obvious to mark your code ARR due to how poorly worded it is. There's also the fact that I know that some actual SaaS companies (those who develop their own tech, not the rentseekers) use the AGPL as a SaaS competition deterrent; they know that only they can reliably contribute to it and nobody else outside of hobbyists dare to deploy it due to how messy the license is.
As for the Quine thing; yeah this is basically the only method in which you can practically comply with modifying an AGPL project, when it comes to tiny modifications (which includes the external PR flow of most FOSS projects).
If I run say, nextcloud and modify a single source file because it does something I don't want to (lets say that super aggravating social media advertisement box in the settings that I have to get rid of every single update), I now have to find a way to make sure all my users know that this patch has been applied. Either that means hard-forking the project, changing all the upstream URLs to point to a new upstream, which would be quite silly (not to mention probably not intended by the nextcloud developers). Alternately, I could make nextcloud a quine (a modification for nextcloud specifically would be complex enough to warrant being its own beast, not to mention traffic inefficient)... or I could just accept that I'm in violation of the license and that the tweak is so tiny it bothers nobody. The latter is what practically always happens since so few AGPL products are designed to be a quine.
Vaultwarden is a Rust implementation of the server for Bitwarden, a password manager. It was initially licensed with the GPLv3, and now switched to the AGPLv3. This was done after getting approval from contributors (see linked discussion).
As far as I understand it, this new license increases protections for network based services. I think that it means that if your client depends on unique features of the Vaultwarden server, the client also has to use the AGPLv3 license (it's "viral" even through the network). EDIT: I may be wrong about this according to the replies.
From the discussion:
> To be clear, this will not effect any (end)user or any self-hosted environment which you share with your family and friends.
This will only have an effect on companies or self-hosted environments that build proprietary tools using Vaultwarden code or modify the Vaultwarden code.
> This is also more fair towards Bitwarden, since currently the GPLv3 license of Vaultwarden could allow other companies to compete with Bitwarden by modifying the Vaultwarden code and not providing these changes back to the community, which is not something we want.
> I think that it means that if your client depends on unique features of the Vaultwarden server, the client also has to use the AGPLv3 license (it's "viral" even through the network).
I'm not aware of any term in the AGPL that requires that. The AGPL says it applies only to modified versions or derivative works of the original codebase, and in general, just using an API -- even if it's unique to that product -- is not enough to make something a derivative work of that product.
(Otherwise, for instance, all software written in Java would be subject to Java's license agreement.)
The AGPL says that all clients interacting with the server through the network must be offered the source code of the server, not that they have to be AGPL themselves.
Of course, if you build your own client that uses code taken from the server, your client must be distributed under AGPL, just as if you did that with the old version, you would have had to use the GPL.
Yes, this seems like a common misconception with the AGPL. You can embed AGPL things within your stack and not have to open source the things that interact with it (or the software/scripts that is used to deploy it, another common misconception).
If you're trying to use the AGPL to prevent folks from monetizing your shit or to get them to pay you for using it, you're using the wrong license.
The "Corresponding Source" for a work in object code form means all
the source code needed to generate, install, and (for an executable
work) run the object code and to modify the work, including scripts to
control those activities. However, it does not include the work's
System Libraries, or general-purpose tools or generally available free
programs which are used unmodified in performing those activities but
which are not part of the work. For example, Corresponding Source
includes interface definition files associated with source files for
the work, and the source code for shared libraries and dynamically
linked subprograms that the work is specifically designed to require,
such as by intimate data communication or control flow between those
subprograms and other parts of the work.
What is it about the word "deploy" that you used that is materially different from "install" as described in the license text above?
> Simply put, the AGPLv3 is effectively the GPLv3, but with an additional licensing term that ensures that users who interact over a network with modified versions of the program can receive the source code for that program
The text you are referencing is present in the GPL too, and it doesn't make GPL code infect adjacent apps.
> It's not like the AGPL infects everything on your network, it's limited to the original source.
Indeed. By the way, the difference between the AGPL and the SSPL is that the SSPL does infect your entire stack and isn't limited to just the original source, which is exactly why the AGPL is free and open-source but the SSPL is neither.
Now consider the "Tivo" target, which is that the scripts and tools required to deploy the code are things they absolutely want to cover.
You didn't answer my question directly though (and nor does the linked article), what is it about deploy in your usage that is materially different from "install" in the text?
Do you disagree that the device case is covered? How do you consider a cloudy type environment different, and by what definition and justification? What if I sell the deployment in a box for on-prem, as well as in hosted VMs? Does that change users rights under the license?
Arguably it discourages anyone who wants to use the back-end code to build something proprietary with your own distinct changes. But you're not wrong, say a cloud hosting provider out of China, they wont care about AGPL they'll do what they have to.
I am not a lawyer. Anyone interested in what they can or cannot do with AGPL licensed software should probably consult a lawyer.
It may depend on what you mean by use an API. Compiling a program that links AGPL licensed code may incur obligations under the AGPL. Here is a quote from the AGPL FAQ.
> If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.
https://www.gnu.org/licenses/gpl-faq.html#MereAggregation
The point I'm trying to make with that sentence doesn't depend on the exact license. I apologize if I didn't word it clearly enough.
Java is licensed under the GPL, which says any derivative works of a GPL'd work must also be GPL-licensed. But merely using the Java APIs doesn't make your program a derivative work of Java, which is why it's possible to write and distribute non-GPL software in Java.
By the same reasoning, a client library that merely uses Vaultwarden's APIs does not automatically become bound to the terms of Vaultwarden's copyright license. The AGPL states quite clearly, for the avoidance of doubt, that the only acts it restricts are things that would otherwise require the copyright holder's permission.
I think the history of this exception comes from the Apache Harmony project which was an early, incomplete fully open source implementation of Java core libraries. As I recall, IBM was heavily involved in this project. (Or was it GNU Classpath? I forget.)
And, please remember that Sun Microsystems open-sourced JDK with great difficulty! (There was a mess of proprietary licenses deep within the core library for years that needed to be dug out one by one.) Some very smart lawyers probably thought long and hard about that linking exception. I doubt Oracle likes it, but it is probably impossible to change now.
No problem. It's not necessarily your fault -- you have to be careful what you read, because a lot of people seem to have very strongly held opinions about the AGPL that are based on hearsay, not on what the license actually says.
In general, it cannot, because the choice of license rests with the owner of the copyright.
You may be mixing up the fact that the GPLv3 has an explicit clause saying this:
> Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU Affero General Public License into a single combined work, and to convey the resulting work.
But that doesn't give the right for a non-owner to relicense the code.
But it does explicitly allow a part-owner to relicense their code to AGPL, and bundle it with all the other authors' GPL code without asking them for permission since that explicit clause already grants that permission.
And from a practical standpoint the new combined thing (where part of the code is AGPL and part is GPL) has to be treated as AGPL, because if you don't follow the AGPL restrictions, then you're breaching copyright of that part-owner who did distribute "their part" only under AGPL; the GPL clause 13 allowing the combination is explicit about that "[...] the special requirements of the GNU Affero General Public License, section 13, concerning interaction through a network will apply to the combination as such."
No. They are just compatible, in that you can incorporate GPL code in AGPL project and vice versa, with both parts remaining under their respective license.
There's really no vice versa - you can combine GPL code with AGPL code, but while both parts remain under their respective license, the resulting combination as a whole then has to follow the AGPL rules ("The terms of this License will continue to apply to the part which is the covered work, but the special requirements of the GNU Affero General Public License, section 13, concerning interaction through a network will apply to the combination as such."), so as soon as you incorporate even a tiny bit of AGPL code in your mostly-GPL project, users have to treat it as an AGPL project.
No, there is no such thing as software under a license "becoming" something else. When distributing the whole combined work e.g. a compiled file you have to follow the AGPL, naturally.
The part under GPL/MIT/BSD is still there. If you were to extract only those source files and distributed them they would be still under GPL/MIT/BSD.
> 13. Use with the GNU Affero General Public License.
>
> Notwithstanding any other provision of this License, you have
permission to link or combine any covered work with a work licensed
under version 3 of the GNU Affero General Public License into a single
combined work, and to convey the resulting work. The terms of this
License will continue to apply to the part which is the covered work,
but the special requirements of the GNU Affero General Public License,
section 13, concerning interaction through a network will apply to the
combination as such.
There is a similar clause in the AGPLv3 as well.
The combined work must comply simultaneously with both GPLv3 and AGPLv3. Since AGPLv3 is a superset of restrictions, that means in all practical senses the combined work is AGPLv3.
Read my reply again. I very clearly spelled out: there is no such thing as software under a license "becoming" something else. When distributing the whole combined work e.g. a compiled file you have to follow the AGPL, naturally.
> The combined work must comply simultaneously with both GPLv3 and AGPLv3
Correct.
> Since AGPLv3 is a superset of restrictions, that means in all practical senses the combined work is AGPLv3.
No. You just contradicted yourself. Yet again there is no such thing as "everything being AGPLv3".
