3 ms·

The contributor side of it is important as well. If I'm using an open source product, I'm generally very happy to spend long hours debugging edge cases, writin

by paxys 2y ago

The contributor side of it is important as well. If I'm using an open source product, I'm generally very happy to spend long hours debugging edge cases, writing detailed bug reports, pushing fixes, suggesting and adding enhancements and generally being involved in the community, knowing that I'm doing my share and improving the experience for everyone. Nowadays it is increasingly likely that my effort is eventually going to be relicensed and repackaged into non-free software without my consent, and no one (not even me myself) will be allowed to continue to benefit from my work. IMO the issue really lies with the VC funding model. Every single one of these projects that has done a license bait and switch has taken outside funding, and these investors want to see an exponential return, which simply cannot be attained by keeping the software free. Stewardship by a reputed open source foundation is the only possible future for such projects if they want to actually stay open and do right by their community.

gjsman-1000 2y ago
> Nowadays it is increasingly likely that my effort is eventually going to be relicensed and repackaged into non-free software without my consent, and no one (not even me myself) will be allowed to continue to benefit from my work. The curious thing (and developers have the right) is that permissive licenses, like MIT, are growing every year while copyleft licenses like the GPL are decreasing in popularity. According to a loose Statista graph, ~41% of OSS projects used permissive licenses in 2012. By 2021, it was ~78%. The Register has also noted this phenomenon. Copyleft is completely out of fashion. https://www.theregister.com/2020/01/17/mit_apache_versus_gpl/ https://www.theregister.com/2020/01/17/mit_apache_versus_gpl... Personally, if I was making a solo OSS project, I completely get it. If Google wants to use it, even if they never gave back, I would be honored and quite possibly get a job from that. Using GPL just means my software will only be useful to GPL-loving compatriots, which is to say, almost nowhere outside the Linux communities. It's also not fair when my company (like most companies) benefitted immensely from various bits of MIT/Apache licensed software, so to give back to the community as a whole with the GPL feels unfair.
- WesolyKubeczek 2y ago
  > The curious thing (and developers have the right) is that permissive licenses, like MIT, are growing every year while copyleft licenses like the GPL are decreasing in popularity. Not very surprising given the sizeable army of all the “developer evangelists”, “developer advocates”, and “devrel people” who have been quite vocal on the gpl-bad-mit-good stance, all the while being on Big Tech’s dime, one way or another. Why would Big Tech want to promote this view so much? Commoditize your complement, that’s why.
danenania 2y ago
Open core is a tried and true business model. It’s essentially just freemium, which businesses have done forever. If a healthy proprietary product can be built on the open source base, that’s a win-win. The company gets revenue and a sustainable business; the community gets free open source software with a highly motivated steward. There’s no reason to relicense if it works. Things can go wrong in various ways of course, and drawing the line in the right place is a challenge, but that doesn’t mean that every VC-backed open core product is doomed to relicense. There are many examples of it working out well for both the company and community.
- the_mitsuhiko 2y ago
  Open core in practical terms keeps many useful parts away of a product. A good example of this is clickhouse recently which keeps some of the most interesting features locked to the cloud version exclusively.
  - ezekg 2y ago
    This is the reason why I believe Fair Core [0] is superior to open core, because the former eventually open sources everything, while the latter never open sources the useful parts. That's actually one of the main reasons I relicensed to the FCL from the ELv2 [1]. [0]: https://fcl.dev https://fcl.dev [1]: https://keygen.sh/blog/keygen-is-now-fair-source/ https://keygen.sh/blog/keygen-is-now-fair-source/
  - danenania 2y ago
    > Open core in practical terms keeps many useful parts away of a product. Well yeah of course. If nothing useful is held back, no one is likely to buy the paid version of the product. That's how freemium works. If you're relying on an open source project, you should want it to have a sustainable business backing it, and that means there needs to be a reasonable balance between free and paid features. If a project isn't helping anyone make money, no one is likely to do all the thankless tasks required to keep it healthy and growing, and there's a good chance it will end up abandoned eventually.
bigstrat2003 2y ago
> Nowadays it is increasingly likely that my effort is eventually going to be relicensed and repackaged into non-free software without my consent, and no one (not even me myself) will be allowed to continue to benefit from my work. I disagree with the conclusion you have drawn here. In the scenario you describe, you (and everyone else) can continue to benefit from your work. The original project is still there, it's still just as useful and open as the day you made your contribution. How then is anyone prevented from continuing to benefit?
- andrewstuart2 2y ago
  While true, I think the reality is that this is still being figured out in the legal system right now. Forks of redis and hashicorp products should be completely fine theoretically, but there's a lot of legal chaos right now with the owners of the BSL versions trying to figure out if/how to prosecute the open versions for adding similar features to the "source available" versions. I've heard contributors to the forks on popular podcasts having to say "I'm not sure I can comment on this right now" due to ongoing battles and legal advice. I'd love it to be cut and dry fork-wise but there are parties with vested financial interests trying to keep the OSS forks frozen in time. If anything, "source available" is almost weaponized because if you've looked at the available source, it's tenuous. And if two implementations of the same feature look similar (as they will) it might not be as easy to convince a jury that it's not a copying of copyrighted now-unlicensed code.
nindalf 2y ago
> these investors want to see an exponential return Don't think this is the reason, at least for Sentry. They've been in business for more than a decade. The bigger reason is that it would take AWS 2 weeks to offer a version of their product. It would be API compatible because it would be exactly the same code. AWS would offer an introductory price of $0 for the first year. Not all Sentry customers would switch, but many would. Sentry would continue to develop their product, while AWS maintained a skeleton crew to deploy their changes and make most of the money off it. While it may be easier to assume the worst of people, ascribing all kinds of intentions to them, just listen to them. They say "we don't want AWS to deploy our product and take all our customers". They say it because it's what they're really worried about.
- paxys 2y ago
  https://sentry.io/about/press-releases/sentry-raises-90-million-in-series-e-funding-to-expand-and-drive-adoption-of-developer-first-application-monitoring/ https://sentry.io/about/press-releases/sentry-raises-90-mill... Sentry raised $90 million in a series E round in May 2022, and their total funding is sitting at $217 million. No cloud provider even offers a hosted version of Sentry, so it's not like that's an issue for their business. Spinning up a VM and deploying your own version is incredibly straightforward. Which is exactly why they now need to switch licenses and put newer features behind more restrictive terms so users are forced to pay.
  - ezekg 2y ago
    > No cloud provider even offers a hosted version of Sentry, so it's not like that's an issue for their business. https://cra.mr/the-busl-factor https://cra.mr/the-busl-factor
  - bentlegen 2y ago
    > Which is exactly why they now need to switch licenses and put newer features behind more restrictive terms so users are forced to pay Sentry switched to BUSL in 2019, almost 5 years ago.[1] Most of the aforementioned fundraising occurred after the license change (e.g. the $90MM round you mention from 2022, and another $60MM round in 2021). The "restrictive terms" - which again, were introduced in 2019 - are that you can use the software but not use the code to compete against the software's authors. For 99.99% of users, this has been a non-issue, because most people have no interest in doing so. [1] https://blog.sentry.io/relicensing-sentry/ https://blog.sentry.io/relicensing-sentry/

by paxys 2y ago

gjsman-1000 2y ago

> Nowadays it is increasingly likely that my effort is eventually going to be relicensed and repackaged into non-free software without my consent, and no one (not even me myself) will be allowed to continue to benefit from my work. The curious thing (and developers have the right) is that permissive licenses, like MIT, are growing every year while copyleft licenses like the GPL are decreasing in popularity. According to a loose Statista graph, ~41% of OSS projects used permissive licenses in 2012. By 2021, it was ~78%. The Register has also noted this phenomenon. Copyleft is completely out of fashion. https://www.theregister.com/2020/01/17/mit_apache_versus_gpl/ https://www.theregister.com/2020/01/17/mit_apache_versus_gpl... Personally, if I was making a solo OSS project, I completely get it. If Google wants to use it, even if they never gave back, I would be honored and quite possibly get a job from that. Using GPL just means my software will only be useful to GPL-loving compatriots, which is to say, almost nowhere outside the Linux communities. It's also not fair when my company (like most companies) benefitted immensely from various bits of MIT/Apache licensed software, so to give back to the community as a whole with the GPL feels unfair.

WesolyKubeczek 2y ago
> The curious thing (and developers have the right) is that permissive licenses, like MIT, are growing every year while copyleft licenses like the GPL are decreasing in popularity. Not very surprising given the sizeable army of all the “developer evangelists”, “developer advocates”, and “devrel people” who have been quite vocal on the gpl-bad-mit-good stance, all the while being on Big Tech’s dime, one way or another. Why would Big Tech want to promote this view so much? Commoditize your complement, that’s why.

danenania 2y ago

Open core is a tried and true business model. It’s essentially just freemium, which businesses have done forever. If a healthy proprietary product can be built on the open source base, that’s a win-win. The company gets revenue and a sustainable business; the community gets free open source software with a highly motivated steward. There’s no reason to relicense if it works. Things can go wrong in various ways of course, and drawing the line in the right place is a challenge, but that doesn’t mean that every VC-backed open core product is doomed to relicense. There are many examples of it working out well for both the company and community.

the_mitsuhiko 2y ago
Open core in practical terms keeps many useful parts away of a product. A good example of this is clickhouse recently which keeps some of the most interesting features locked to the cloud version exclusively.
- ezekg 2y ago
  This is the reason why I believe Fair Core [0] is superior to open core, because the former eventually open sources everything, while the latter never open sources the useful parts. That's actually one of the main reasons I relicensed to the FCL from the ELv2 [1]. [0]: https://fcl.dev https://fcl.dev [1]: https://keygen.sh/blog/keygen-is-now-fair-source/ https://keygen.sh/blog/keygen-is-now-fair-source/
- danenania 2y ago
  > Open core in practical terms keeps many useful parts away of a product. Well yeah of course. If nothing useful is held back, no one is likely to buy the paid version of the product. That's how freemium works. If you're relying on an open source project, you should want it to have a sustainable business backing it, and that means there needs to be a reasonable balance between free and paid features. If a project isn't helping anyone make money, no one is likely to do all the thankless tasks required to keep it healthy and growing, and there's a good chance it will end up abandoned eventually.

bigstrat2003 2y ago

> Nowadays it is increasingly likely that my effort is eventually going to be relicensed and repackaged into non-free software without my consent, and no one (not even me myself) will be allowed to continue to benefit from my work. I disagree with the conclusion you have drawn here. In the scenario you describe, you (and everyone else) can continue to benefit from your work. The original project is still there, it's still just as useful and open as the day you made your contribution. How then is anyone prevented from continuing to benefit?

andrewstuart2 2y ago
While true, I think the reality is that this is still being figured out in the legal system right now. Forks of redis and hashicorp products should be completely fine theoretically, but there's a lot of legal chaos right now with the owners of the BSL versions trying to figure out if/how to prosecute the open versions for adding similar features to the "source available" versions. I've heard contributors to the forks on popular podcasts having to say "I'm not sure I can comment on this right now" due to ongoing battles and legal advice. I'd love it to be cut and dry fork-wise but there are parties with vested financial interests trying to keep the OSS forks frozen in time. If anything, "source available" is almost weaponized because if you've looked at the available source, it's tenuous. And if two implementations of the same feature look similar (as they will) it might not be as easy to convince a jury that it's not a copying of copyrighted now-unlicensed code.

nindalf 2y ago

> these investors want to see an exponential return Don't think this is the reason, at least for Sentry. They've been in business for more than a decade. The bigger reason is that it would take AWS 2 weeks to offer a version of their product. It would be API compatible because it would be exactly the same code. AWS would offer an introductory price of $0 for the first year. Not all Sentry customers would switch, but many would. Sentry would continue to develop their product, while AWS maintained a skeleton crew to deploy their changes and make most of the money off it. While it may be easier to assume the worst of people, ascribing all kinds of intentions to them, just listen to them. They say "we don't want AWS to deploy our product and take all our customers". They say it because it's what they're really worried about.

paxys 2y ago
https://sentry.io/about/press-releases/sentry-raises-90-million-in-series-e-funding-to-expand-and-drive-adoption-of-developer-first-application-monitoring/ https://sentry.io/about/press-releases/sentry-raises-90-mill... Sentry raised $90 million in a series E round in May 2022, and their total funding is sitting at $217 million. No cloud provider even offers a hosted version of Sentry, so it's not like that's an issue for their business. Spinning up a VM and deploying your own version is incredibly straightforward. Which is exactly why they now need to switch licenses and put newer features behind more restrictive terms so users are forced to pay.
- ezekg 2y ago
  > No cloud provider even offers a hosted version of Sentry, so it's not like that's an issue for their business. https://cra.mr/the-busl-factor https://cra.mr/the-busl-factor
- bentlegen 2y ago
  > Which is exactly why they now need to switch licenses and put newer features behind more restrictive terms so users are forced to pay Sentry switched to BUSL in 2019, almost 5 years ago.[1] Most of the aforementioned fundraising occurred after the license change (e.g. the $90MM round you mention from 2022, and another $60MM round in 2021). The "restrictive terms" - which again, were introduced in 2019 - are that you can use the software but not use the code to compete against the software's authors. For 99.99% of users, this has been a non-issue, because most people have no interest in doing so. [1] https://blog.sentry.io/relicensing-sentry/ https://blog.sentry.io/relicensing-sentry/