3 ms·

The term is "source available," but I guess with that, companies can't use "open source" as a marketing term then pull the rug after they got enough contributio

The term is "source available," but I guess with that, companies can't use "open source" as a marketing term then pull the rug after they got enough contributions, like so many that converted to BSL and others now. By creating rights for those companies such that they cannot be competed with, you actually remove the rights of users, which is the whole reason the open source and free software movements got started in the first place. They are and always have been about the rights of users, not of corporations.

evantbyrne 2y ago
What are you talking about? I don't know where you live or what project you are referring to, but it's not possible to retroactively remove someone's rights in the American legal system by publishing a new license. If you committed code under a MIT license without signing anything else, you don't lose anything when later versions are published under BSL, AGPL, or whatever. The fact that the MIT license arguably allows willy nilly relicensing by anyone should be seen as a flaw with that license, not BSL. Also the context of this conversation is what license is appropriate for a new project. It makes less sense to apply a BSL to a MIT licensed project that has been around for a while than it does to start off with a BSL.
- satvikpendem 2y ago
  I'm not even sure how what you're saying relates to what I said; of course no license can be retroactively changed and I never said anything to the contrary. By rug pull, I mean companies like Sentry or MongoDB starting off as open source then changing their license such that they are no longer open source, making it a much more difficult legal minefield for whomever uses their product, even if they aren't competing with them, as they are now source available companies. As a copyright holder, any license can be changed for the future, whether it be MIT, AGPL, or BSL. With regards to a new project, sure, they can license it however they want but if it's not open source, they should expect to get way fewer contributions than if it were.
  - evantbyrne 2y ago
    Well that's certainly disappointing but not really a rug pull so much as just what eventually happens with every project, which is that at some point the original authors stop contributing to the original vision. Both of the mentioned projects also don't use BSL, which I feel it is worth reiterating is still a very permissive license. If you aren't planning on selling licenses to the project you are contributing to, then a BSL isn't going to meaningfully restrict you. Sure, fewer contributions is a theoretical concern, but fully permissive licenses also suffer from contributions not looping back into the original project. Or if you use something in the GPL family there are other implications. I've been reading a lot about licensing lately and there don't seem to be any obvious choices for authors who care about how their work is used. I'm gravitating towards BSL though because it is relatively simple and feels like it retains the most important aspects of open source, which are redistribution and modification.

evantbyrne 2y ago

What are you talking about? I don't know where you live or what project you are referring to, but it's not possible to retroactively remove someone's rights in the American legal system by publishing a new license. If you committed code under a MIT license without signing anything else, you don't lose anything when later versions are published under BSL, AGPL, or whatever. The fact that the MIT license arguably allows willy nilly relicensing by anyone should be seen as a flaw with that license, not BSL. Also the context of this conversation is what license is appropriate for a new project. It makes less sense to apply a BSL to a MIT licensed project that has been around for a while than it does to start off with a BSL.

satvikpendem 2y ago
I'm not even sure how what you're saying relates to what I said; of course no license can be retroactively changed and I never said anything to the contrary. By rug pull, I mean companies like Sentry or MongoDB starting off as open source then changing their license such that they are no longer open source, making it a much more difficult legal minefield for whomever uses their product, even if they aren't competing with them, as they are now source available companies. As a copyright holder, any license can be changed for the future, whether it be MIT, AGPL, or BSL. With regards to a new project, sure, they can license it however they want but if it's not open source, they should expect to get way fewer contributions than if it were.
- evantbyrne 2y ago
  Well that's certainly disappointing but not really a rug pull so much as just what eventually happens with every project, which is that at some point the original authors stop contributing to the original vision. Both of the mentioned projects also don't use BSL, which I feel it is worth reiterating is still a very permissive license. If you aren't planning on selling licenses to the project you are contributing to, then a BSL isn't going to meaningfully restrict you. Sure, fewer contributions is a theoretical concern, but fully permissive licenses also suffer from contributions not looping back into the original project. Or if you use something in the GPL family there are other implications. I've been reading a lot about licensing lately and there don't seem to be any obvious choices for authors who care about how their work is used. I'm gravitating towards BSL though because it is relatively simple and feels like it retains the most important aspects of open source, which are redistribution and modification.