| It's definitely not entirely true, the license grants that "the current version" under "the current license" will be under the Apache license in 5 years that translates to in 5 years dragonflydb 0.6.0 / 0.7.0 will be under the apache license.
That's the only guarantee. The change date can be changed at any time, the license allows it, almost all the projects I saw using the BSL actually use a sentence like "X years from the release", on top of this it can be even removed and if that would be the case than the paragraph below would apply, which clearly refers to 5 years from the released versions. > Effective on the Change Date, or the fifth anniversary of the first publicly available distribution of a specific version of the Licensed Work under this License, whichever comes first, the Licensor hereby grants you rights under the terms of the Change License, and the rights granted in the paragraph above terminate. 5 years old software is a dead software :) The only reason for adopting the BSL is to prevent companies like Amazon to take ownership and don't give back to the project (e.g. elastic), which is totally understandable. Do you think that future releases, much more feature-complete and flexible, will be given under the apache license as they are meanwhile less feature complete versions aren't? Looking at the facts, I would say the answer is very likely no. Would you build something in 5 years based on dragonflydb 0.7.0 when most likely there will be a v2.0 or even a v3.0 out there? When it comes to non open source licenses and companies it should be clear that the companies want (and need) to take care of their own interests: the BSL "change date" is a way to be able to say "yes but it will become OSS" so you can keep using and contributing, like the sop you give to a kid to stop him from crying. |
I do agree that 5 year old software is dead software, which is a pretty aggressive number for Dragonfly to take here, but at least it's not 10+ years.
> The only reason for adopting the BSL is to prevent companies like Amazon to take ownership and don't give back to the project (e.g. elastic), which is totally understandable.
I also agree with this. It's a dog-eats-dog-world and businesses have to figure out how to compete.
> The change date can be changed at any time, the license allows it, almost all the projects I saw using the BSL actually use a sentence like "X years from the release", on top of this it can be even removed and if that would be the case than the paragraph below would apply, which clearly refers to 5 years from the released versions.
There is still Git involved here. The authors can't re-write history. A commit from today will convert at the same date regardless of future commits, even if the BSL clause is updated in future commits. Dragonfly pushing a commit publicly seems like it should constitute a "release date" to me!
> When it comes to non open source licenses and companies it should be clear that the companies want (and need) to take care of their own interests: the BSL "change date" is a way to be able to say "yes but it will become OSS" so you can keep using and contributing, like the sop you give to a kid to stop him from crying.
That's the glass-half-empty perspective of this. The glass-half-full perspective is: At least it is going to be _eventually_ Open Source! (which is better than yet-another-proprietary-vendor popping up.)
> Would you build something in 5 years based on dragonflydb 0.7.0 when most likely there will be a v2.0 or even a v3.0 out there?
Almost certainly not. I would be worried about the security vulnerabilities and not having patches to fix them.
But, given that their BSL clause does allow commercial use for a private company or an Open Source project, I would think about if using the latest version was the right tool for the job. I just won't expect to go to AWS and get a managed version of the service -- I'd have to go to Dragonfly (which is their goal).
I am empathetic to both sides of this and I'm happy to see licenses like BSL becoming a thing because I think it will continue to accelerate the rate of innovation. (I've had to debug too many vendor binaries in my life. Even just "source available" is valuable when you have production infrastructure heavily reliant on a piece of software because you can still debug it + fix it without requiring the vendor!)