4 ms·

The main issue of such a license is that you can't fork the project when they go in a direction that you don't like. Also, we can now say that Sentry is a prop

The main issue of such a license is that you can't fork the project when they go in a direction that you don't like. Also, we can now say that Sentry is a proprietary software with open Sources but clearly not a free software anymore. They are free to do whatever they want, but in my opinion it is an "asshole" move to say that you do a license to fight "free-riding" when you are standing on the shoulders of free software components like Python or somehow python frameworks like Django. Sentry wouldn't even exist without free-riding.

the_mitsuhiko 3y ago
> The main issue of such a license is that you can't fork the project when they go in a direction that you don't like. You absolutely can. You can even start a competing company after two years.
greatgib 3y ago
Btw, something strange with their license is that it means that no one else can contribute to the project except if there is a kind of cla. Let's suppose that I fork the FSL version and add some patches. They are interesting. Now Sentry would not be able to integrate these changes into their version because the "with us" regarding the competition would not be the same person. Same thing with contributions to the the apache 2 license code that can't make it inside the code of a later version that would be released as FSL. Also, I don't want that to happen, but a bad faith actor could probably also poison their code: - you look what would probably be needed for next development, a bug fix, a bug issue or change requested. You implement that in the best, obvious or multiple ways in your own fork. Then, they would not be able to use that in their code without infringement on your copyright and ie having not to compete with you.
- the_mitsuhiko 3y ago
  That is more a question about CLAs but licenses. The Python project for instance requires a CLA that gives the PSF the freedom to relicense more liberally than the current license. They would not accept or upstream code from a fork without that paperwork. The implications of not having a CLA for a spring license like the FSL are a bit unexplored. I have an idea in my head how that would play out but who knows.
- mdaniel 3y ago
  > Also, I don't want that to happen, but a bad faith actor could probably also poison their code I recognize this is a thought experiment, but my mental model of the legal system is that it's not "code is law," it's "the golden rule: he who has the gold, makes the rules." So, how I expect this would actually play out is that any such bad actor would do bad actor things, and then the changes would be implemented by someone with a sentry.io email in some nuanced way, we'd see a news article about some lawyering, and the bad actor would be impoverished by lawyer bills
bentlegen 3y ago
> Also, we can now say that Sentry is a proprietary software The article explains that Sentry was licensed under a non-OSI license (the BUSL) for the last 4+ years. That license had more onerous terms than what it uses today. So if you believe this news means it has become proprietary today, you're ~4 years behind. > when you are standing on the shoulders of free software components like Python or somehow python frameworks like Django. Sentry wouldn't even exist without free-riding. Sentry has donated tens of thousands of dollars - probably over $100k over the years - to the PSF and Django. It is currently an acknowledged active sponsor of both [1,2]. This year alone Sentry gave $500,000 to open source foundations and maintainers [3]. Sentry itself was built as a Django ecosystem project, and anyone can use it according to the license terms (e.g. stand up a server and collect errors for their non-competing projects). And many organizations do that today. Sentry (the company) additionally contributes many permissive OSS projects, like popular utility libraries and key parts of the Sentry project itself (e.g. getsentry/responses or the SDKs). The issue is when competing entities take the source, produce purely commercial offerings with no upstream contributions / the source they produce is 100% closed. That’s free-riding. [1] https://www.python.org/psf/sponsors/ https://www.python.org/psf/sponsors/ [2] https://www.djangoproject.com/foundation/corporate-members/ https://www.djangoproject.com/foundation/corporate-members/ [3] https://blog.sentry.io/we-just-gave-500-000-dollars-to-open-source-maintainers/ https://blog.sentry.io/we-just-gave-500-000-dollars-to-open-...
ezekg 3y ago
> The main issue of such a license is that you can't fork the project when they go in a direction that you don't like. As long as it's not a Competing Use, yes, you can [0]. I don't get why so many people think you can't fork a project that uses BUSL, SSPL, ELv2, and now FSL. Just like any other OSS licenses, you can fork. And you just like any other OSS fork, you can't relicense. It's obvious people don't actually read the license. [0]: https://github.com/getsentry/fsl.software/blob/main/FSL-1.0-Apache-2.0.template.md#redistribution https://github.com/getsentry/fsl.software/blob/main/FSL-1.0-...
zeeg 3y ago
Did you actually look at the license, or any of the history of Sentry? It’s still just as “free” as it has been for years. If anything this makes our commitment to open source _more_ explicit than it was under the BUSL. On your free-riding point, just because we leverage open source doesn’t mean our software must be as free and open as possible. We use Linux - should it mean everything we build must be Foss? It’s ok if you have a religion about this but thats simply not practical in all software. Additionally many of us have and continue to give ample time and money to the ecosystem we rely on. I doubt anyone in the Python or Django communities would claim we’re free riders. When we say free riding we mean other companies. We mean folks who don’t participate in the community and simply want to take work for their own gain while giving nothing back. The industry is not sustainable if that becomes the norm.

the_mitsuhiko 3y ago

> The main issue of such a license is that you can't fork the project when they go in a direction that you don't like. You absolutely can. You can even start a competing company after two years.

greatgib 3y ago

Btw, something strange with their license is that it means that no one else can contribute to the project except if there is a kind of cla. Let's suppose that I fork the FSL version and add some patches. They are interesting. Now Sentry would not be able to integrate these changes into their version because the "with us" regarding the competition would not be the same person. Same thing with contributions to the the apache 2 license code that can't make it inside the code of a later version that would be released as FSL. Also, I don't want that to happen, but a bad faith actor could probably also poison their code: - you look what would probably be needed for next development, a bug fix, a bug issue or change requested. You implement that in the best, obvious or multiple ways in your own fork. Then, they would not be able to use that in their code without infringement on your copyright and ie having not to compete with you.

the_mitsuhiko 3y ago
That is more a question about CLAs but licenses. The Python project for instance requires a CLA that gives the PSF the freedom to relicense more liberally than the current license. They would not accept or upstream code from a fork without that paperwork. The implications of not having a CLA for a spring license like the FSL are a bit unexplored. I have an idea in my head how that would play out but who knows.
mdaniel 3y ago
> Also, I don't want that to happen, but a bad faith actor could probably also poison their code I recognize this is a thought experiment, but my mental model of the legal system is that it's not "code is law," it's "the golden rule: he who has the gold, makes the rules." So, how I expect this would actually play out is that any such bad actor would do bad actor things, and then the changes would be implemented by someone with a sentry.io email in some nuanced way, we'd see a news article about some lawyering, and the bad actor would be impoverished by lawyer bills

bentlegen 3y ago

> Also, we can now say that Sentry is a proprietary software The article explains that Sentry was licensed under a non-OSI license (the BUSL) for the last 4+ years. That license had more onerous terms than what it uses today. So if you believe this news means it has become proprietary today, you're ~4 years behind. > when you are standing on the shoulders of free software components like Python or somehow python frameworks like Django. Sentry wouldn't even exist without free-riding. Sentry has donated tens of thousands of dollars - probably over $100k over the years - to the PSF and Django. It is currently an acknowledged active sponsor of both [1,2]. This year alone Sentry gave $500,000 to open source foundations and maintainers [3]. Sentry itself was built as a Django ecosystem project, and anyone can use it according to the license terms (e.g. stand up a server and collect errors for their non-competing projects). And many organizations do that today. Sentry (the company) additionally contributes many permissive OSS projects, like popular utility libraries and key parts of the Sentry project itself (e.g. getsentry/responses or the SDKs). The issue is when competing entities take the source, produce purely commercial offerings with no upstream contributions / the source they produce is 100% closed. That’s free-riding. [1] https://www.python.org/psf/sponsors/ https://www.python.org/psf/sponsors/ [2] https://www.djangoproject.com/foundation/corporate-members/ https://www.djangoproject.com/foundation/corporate-members/ [3] https://blog.sentry.io/we-just-gave-500-000-dollars-to-open-source-maintainers/ https://blog.sentry.io/we-just-gave-500-000-dollars-to-open-...

ezekg 3y ago

> The main issue of such a license is that you can't fork the project when they go in a direction that you don't like. As long as it's not a Competing Use, yes, you can [0]. I don't get why so many people think you can't fork a project that uses BUSL, SSPL, ELv2, and now FSL. Just like any other OSS licenses, you can fork. And you just like any other OSS fork, you can't relicense. It's obvious people don't actually read the license. [0]: https://github.com/getsentry/fsl.software/blob/main/FSL-1.0-Apache-2.0.template.md#redistribution https://github.com/getsentry/fsl.software/blob/main/FSL-1.0-...

zeeg 3y ago

Did you actually look at the license, or any of the history of Sentry? It’s still just as “free” as it has been for years. If anything this makes our commitment to open source _more_ explicit than it was under the BUSL. On your free-riding point, just because we leverage open source doesn’t mean our software must be as free and open as possible. We use Linux - should it mean everything we build must be Foss? It’s ok if you have a religion about this but thats simply not practical in all software. Additionally many of us have and continue to give ample time and money to the ecosystem we rely on. I doubt anyone in the Python or Django communities would claim we’re free riders. When we say free riding we mean other companies. We mean folks who don’t participate in the community and simply want to take work for their own gain while giving nothing back. The industry is not sustainable if that becomes the norm.