5 ms·

jjlin raised some valuable points in https://github.com/dani-garcia/vaultwarden/discussions/2450#discussioncomment-2682483 https://github.com/dani-garcia/vaultw

jjlin raised some valuable points in https://github.com/dani-garcia/vaultwarden/discussions/2450#discussioncomment-2682483 https://github.com/dani-garcia/vaultwarden/discussions/2450#..., where the initial motivation and reasoning were faulty or incomplete: > 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 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.)

josephcsible 4y ago
> I still largely prefer to work with permissive licenses. 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?
2Gkashmiri 4y ago
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?
- chrismorgan 4y ago
  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.)

josephcsible 4y ago

> I still largely prefer to work with permissive licenses. 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?

2Gkashmiri 4y ago

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?

chrismorgan 4y ago
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.)