@bahmanm @[email protected] #AGPL is often used together with CLA:s to ensure the owner of the code does not have to comply with the #AGPL terms, only everyone else in the community.

This means that players in the community are not on equal terms.

I think #BSLLicense is more honest in this regard. It doesn’t hide the motives by pointing to an OSI approved license and as such leaves a more level playing field after the change date.

@[email protected] Let’s not conflate the #SSPL license that Elastic switched to with the #BSLLicense.

The SSPL is an #AGPL license modified to prohibit competition for eternity.

The BSL is a license that turns into a #GPL2 compatible license within at most 4 years and which the creators, @mariadb, created to ensure their proprietary extensions would be as close to OSS as possible and guaranteed to eventually become full OSS.

Likewise, @getsentry defaults to non-BSL: https://open.sentry.io/licensing/

Licensing

We pride ourselves on delivering the same functionality in our self-hosted offering as in our cloud product.

Sentry

Another day, another project that uses the #BSLLicense, but which hasn’t understood the requirements it’s setting (change date being too far away in the future and change license being #AGPL, which is not #GPL2 compatible)

Apart from that, #SpacetimeDB looks like a cool project 👏

https://github.com/clockworklabs/SpacetimeDB/issues/215

Invalid BSL 1.1 Change Date and Change License · Issue #215 · clockworklabs/SpacetimeDB

To ensure consistent expectations BSL 1.1 enforced limitations on eg Change Date and Change License. First, we set a cap of four years for the duration of the time window prior to code becoming FOS...

GitHub

@brianleroux @isaacs Exclusivity to use for production outside of the additional use grants for at max four years from the release date #BSLLicense

I think it’s not the license that is much wrong, it’s the use of a too long change date

I would eg be fine with HashiCorp having eg a 6 month exclusivity on using new features in a SaaS offering

@msw Would be interesting to see if one could push the #BSLLicense concept further in this regards, to enable mixing as long as the additional use grants are not conflicting

@linux_mclinuxface Yikes! I really liked what you / AWS did there!

Part of the appeal of #BSLLicense to me (when it has a short change date) is that it can cater to whatever needs the Elastic side saw (I guess people with investor hats and economy degrees) while still enabling upstreaming into the open distro eventually

@kmohrf The main criticism I have of #BSLLicense is that it’s default change date is the same as it’s max change date and it’s max change date is too far into the future.

So my main criticism of #BSLLicense users is then sticking with that change date rather than adopting one that integrates better with OSS at large

@jzb @richardfontana I think this is the lesser of the evils though, they are not doing an Elastic where they go an SSPL or similar: https://www.elastic.co/blog/licensing-change

#BSLLicense is probably the most open license that a SaaS startup that wants to build a business on selling a hosted version can use on parts of their systems without exposing themselves to leeches, and it’s been actively developed with feedback from the OSS community and endorced by influential ones there: https://mariadb.com/bsl-faq-adopting/

Doubling down on open, Part II

Elastic Blog

Interesting that they pair their #BSLLicense with MPL 2.0, mostly seen it combined with Apache 2.0 before

A bit disappointed that they seems to go for the longest change date

Nice to see more companies go down the BSL / BUSL license path rather than the AGPL / SSPL / custom restrictive license part: https://www.hashicorp.com/license-faq #BSLLicense
HashiCorp | The Infrastructure Cloud Company

HashiCorp