Why should we trust you not to change that in the future?
If you really don't like what they are doing, you could fork them right now. But my guess is that you won't because then you'd have to do the work you're getting for free now.
Right now there's this trend where companies take the benefits of open source for themselves, then toss aside the open source community when it looks like it might make them a buck. Ultimately I think that is bad for the community, and that the corporations that do this are putting their profit above the community that helped them grow. I don't think it's unreasonable to point this out.
The BSD license is very clear that you can not assume that. A developer who contribute patches under BSD license should have no expectation for what other developers will license code in the future. Licenses is all about defining expectations.
Well, there's their problem. They shouldn't assume anything they want a 3rd party to do that's not in the license. Instead, they could offer contributions with a contract that forced the next version to also be open source.
The people buying software should assume companies might do anything the license allows. Those supplying software should assume those using it might do anything the license allows. They should change the license and contract to forbid what they don't like or ensure certain protections they do want.
This company fixed its license to reduce a risk in the old one.
The narrative you're trying to paint is misleading at best:
> It’s important to remember that Sentry “the project” has been developed almost exclusively by employees of Sentry “the company”; millions of dollars have paid the salaries of engineers, designers, and product people to produce the software we know and love today.
They are the primary contributors to their own product and the existing "community" that use in-house versions remains unaffected, they can continue to use modified versions and contribute back features everyone else can benefit from, which I see no reason why they wont continue to do as they can continue enjoying all the benefits of being able to freely use their own hosted versions. But those outside contributions are going to still pale in comparison to the vast majority of contributions that Sentry makes in improving their own product, the most valued contributions Customers are going to make are in the form of feedback, feature requests and detailing how they're using the product.
They're definitely not "toss aside the open source community", their BSL is specifically targeted so that "it won’t change anyone’s ability to run Sentry at their company". You're insinuating the opposite that they're discarding their existing community, when their license is specifically targeted to allow continued free usage by their customers and is only designed to prohibit their competitors from taking of Sentry's investments and using it to compete against them.
This change gives them a more sustainable business model that better protects their investments against competitors reselling their efforts and undermining their business model that's directly used to fund the investments in making a better Sentry product. It's a win for Sentry the product and company and their customers, the only losers from this change are cloud monopolies and Sentry's competitors who are more than welcome to use their own efforts and investments in creating their own competing product.
Who is sentry hurting by making this change?
Lets be clear here too- I'm using your product right now, and I feel that this is a huge betrayal of trust.
There is no good answer to a loaded question like this. If you suspect malice I have nothing I can say to counter this.
- Borrowing bits of code from Sentry for use in an unrelated, non-competing commercial product will no longer be possible for many people -- I suspect many companies' legal teams will bar use of BSL-licensed code out of caution, at least until the 3-year conversion point.
- Using bits of Sentry for internal, non-distributed projects may not be allowed if there's any chance the project will convert to a commercial product (competing or not) within 3 years.
- I suspect there are other scenarios that are technically and legally possible (at least by Sentry's interpretation) but that many corporate lawyers will nix based on an abundance of caution.
- And of course, starting a new open-source project with open governance based on current Sentry code will no longer be an option.
The thing is, BSL's permissions may seem clear to developers, but lawyers will likely get hung up on how to define "competing", and whether a judge would allow a suit to proceed against a (intuitively speaking) clearly non-competing product based on real or perceived ambiguity in the license or in the case itself. Too often, legal teams "just say no" to anything that falls outside their clearly defined (and legally tested) comfort zones. I don't blame corporate lawyers entirely for that, though - it's really a consequence of the legal climate arising from prior case law (which I believe often proceeded on dubious grounds).
The license is clear that there is a specific application of the software that is protected; you are not prevented from using the software in a way that prohibits all commercial use.