Our great sponsors
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
jjlin raised some valuable points in 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>; 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 well past the point of strict accuracy—its authors used to work with OSI and are fed up with broken processes.)
GPLv2 specifically https://github.com/openjdk/jdk/blob/jdk-21%2B9/LICENSE#L3 although Java is the most famous software I know of with the "CLASSPATH exception" https://github.com/openjdk/jdk/blob/jdk-21%2B9/LICENSE#L326 to avoid "linking" the user's compiled artifacts with Oracle's compiled artifacts. I believe there are other projects that make use of that exception, but I couldn't readily find them
They are using this infrastructure as the moat. ReadTheDocs is also doing the same thing.
Deploy if you dare: https://github.com/readthedocs/readthedocs.org