Re-License Vaultwarden to AGPLv3
github.com
github.com
I don't have strong opinions for or against AGPL, I'm just not really too sure why the GPL doesn't solve this as well.
https://en.m.wikipedia.org/wiki/Affero_General_Public_Licens...
It solves the "Amazon issue" where company can take open source software, change it, then offer as a service without giving sources.
Under GPL you don't get binary if you access a service provided by open source software so you are not entitled to source code of the application
Under AGPL just interacting with the software is enough for company to have to provide the source code.
Not to discount the feelings of others, but in a sense I only wish I could have these problems.
Also bugs due to "I didn't bother to read the documentation".
Also legitimate bugs with the attitude of "my production env is down because of this, so fix it at once".
The entitlement is strong.
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.
So ... I must include the license code when I redistribute the binary of the software?
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.
xGPL family of licenses force contribution back of improvements, and rightfully, it's not about developer freedom, but user freedom.
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?
Very rare when someone ever does.
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.
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.
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.
Deploy if you dare: https://github.com/readthedocs/readthedocs.org
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.
Personally I go the (A)GPL way all the time.
Yes.
> There is nothing inherently wrong in both positions.
Also, yes.
Hope more people understand this clearly.
> Personally I go the (A)GPL way all the time.
Me, too.
As a developer and end user I cannot use a lot of software because it's compiled into closed source stuff or in locked down devices, thanks to MIT.
On top of that such software and devices are even spying on me. While I'm busy contributing to FOSS for free.
Making the code anything but MIT just means it’s not used at all, not that companies will suddenly start publishing their source code.
The "commercial entities" built 99% on stuff that they got for free ?
How about they keep their 1% of the stuff that was made wholly by them, but give back the 1% of the code they changed in 99% they took ?
No. But GPL at least gives me the ability not the be a cow to be milked and then butchered.
> Making the code anything but MIT just means it’s not used at all, not that companies will suddenly start publishing their source code.
If freeloaders don't use my software it's still better than nothing.
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.
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.
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.
Yes. That part is covered by GPL. So, you have to share these changes anyway.
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
You are free to implement it yourself instead of using someone else's AGPL code.
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.
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
Like Nextcloud, for example.
Would I like a world where people are always entitled to know what code runs on devices they don't own? Absolutely not.
There's nothing inherently wrong about telling people "Hey, this is the code handling your data, come see for yourself".
And, this is a huge win, and show of confidence, if you ask me.
AGPL is meant to apply the 4 freedoms to anything that is _used_.
By default you are entitled to run only code that you wrote yourself.
You need the copyright holders of anything else to grant you the right to run their code.
Microsoft usually grants the right behind payment.
AGPL authors grant you the right on the condition that you share your changes (if you do any changes) with your users.
If you choose to disobey the terms, two things can happen:
1. Nobody notices and nothing happens.
2. You can be taken to court.
> but it should not be considered a free license
Why not? Which of the 4 freedoms is it taking away?
“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 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.
As with the GPL it should be noted that by default linking to [A]GPL code (e.g. by installing it with a package manager) constitute a modification.
So unless the [A]GPL code includes a linking exception your code must be [A]GPL if there is anything [A]GPL in you node_modules folder.
And you are obliged to share the changes you made to the source code publicly. You can share the way you choose, but you have to do it.
Otherwise you’d be fine not distributing it at all (besides some occasional internet outrage).
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.
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.
In both cases the practicality is the same.
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.
Anytime a vendor sees a GPL3 library, all they have to do is make a network service out of it and the GPL3 license is powerless.
So AGPL3 as the default for strong copyleft software seems reasonable.
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 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.
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.
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".
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 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
Can't be worse than LastPass tho.
This may seem like splitting hairs but it's an important distinction.
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
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.
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.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
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
Thanks for taking the time to spell it out :) I somehow always missed this subtlety.
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.
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.)
Is this because of rare edge cases like ZFS on Linux, because you like it being easy to write proprietary software, or because of something else?
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?
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.)
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.
Definitely seems to fill the middle ground between "open source" meaning "sanctioned by the OSI" and "meet the open source definition OSD".
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
doesn't AGPL force you to share you the code to customers? isn't that restricting your freedom of not sharing code?
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.
That's extremely unclear. Even if it ends up being ok, there's a chilling effect.
>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
please read section 13.
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
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.
if you use SSPL product as a DB, it is same as AGPL
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 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.
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!
Then don't.
If you are only interested in using the software and not contributing back or supporting the community, then that software is not for you.
There may be other software under more permissive license from devs who don't care so much. Or you can also develop what you need yourself.
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'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.
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.
> 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.
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.
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?
Java is licensed under GPL.
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.
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.
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
… or else disentangle the parts, selecting only GPL parts. But yeah, if treating it as a project, AGPL covers it.
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.
> 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".
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.
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."