Interesting detail from the FAQ forum thread: the Director of Product Management at GitLab asks if they can continue integrating with Sentry and is told that it's a violation and they won't be...
I personally believe licenses like the BSL are a necessary step for any open source software, and I do consider it open source, in the AWS / GCP world order. Open source software made the modern...
I personally believe licenses like the BSL are a necessary step for any open source software, and I do consider it open source, in the AWS / GCP world order. Open source software made the modern cloud possible, but now those same cloud providers have the clout to just steal your work. AWS just hosting a black-box version of your project will demolish your business; they can drastically outprice you. I do think open source licensing could use more attention, but the BSL is a step in the right direction for many projects.
I don't know if the BSL is what's necessary for open source to counter the new cloud world order. For instance, I feel like Gitlab taking Sentry's open source code and running it on their servers...
I don't know if the BSL is what's necessary for open source to counter the new cloud world order. For instance, I feel like Gitlab taking Sentry's open source code and running it on their servers under their brand is analogous to Juniper Networks taking FreeBSD and rebranding it as JunOS and selling it. In fact, this is not uncommon with BSD distributions. Their permissive license structure allows companies to come in and profit off their work.
Don't get me wrong, I think the BSDs have a lot going for them, but I think the GPL, and explicitly its "viral" nature, allowed Linux to take off so intensely. Changes had to be made available to consumers who had the right to merge them back upstream. This meant that Linux gained features and grew into a broader platform faster. However, it also meant that it was harder for someone to make money on Linux! Companies contribute because having the changes to Linux are valuable, and you might as well get them upstream if they're going to be public anyway (Android OEMs excluded).
So, instead, Sentry could consider something like the AGPL, but since that is frowned upon by a lot of corporations, they won't. But, critically, it's hard to make money on open source at all!
Linus Torvalds is nowhere close to being the richest man in the world; Bill Gates and Steve Jobs came much closer. Open source hasn't been very profitable as a product. It's been incredibly valuable as a process, but it has always been hard to capitalize on it in more conventional economic terms.
Red Hat and Sun Microsystems came close to having a model, but neither became a top ten company. Open source seems to more successfully be driven by collaborative development. Groups of people with common needs coming together to make something to fulfill those needs and forking when they can't agree. This is why some of the most successful names in open source are GNU, the Linux Foundation, the Debian Project, and the Mozilla Foundation; all collaborative efforts that are not really trying to sell anything. Sure, Red Hat and Canonical do alright (especially the former), but there doesn't seem to be a lot of room in their part of the market.
This is not to say that highly profitable companies don't produce open source software, in fact much of it is written by them, but instead to say that most of them don't try to monetize said software. Google can release all the open source code it wants, but it won't release GSuite or search or God forbid ads, and they've even backtracked some on Android with their focus on Play Services.
I like the AGPL (and I'm using it for Tildes), but it can't help with the cases that Sentry is worried about. The only real end result of it is that it makes sure that if anyone else builds on top...
I like the AGPL (and I'm using it for Tildes), but it can't help with the cases that Sentry is worried about. The only real end result of it is that it makes sure that if anyone else builds on top of your code, they have to also open-source their modifications.
That's not what they're worried about though—Sentry is scared of someone like Amazon simply taking Sentry as-is and offering it as a hosted service, which is exactly what Sentry does to make money. If Amazon does it cheaper and integrates it with all their other hosted offerings (and they would), that would be more attractive and convenient for a lot of people than Sentry's standalone offering. If a lot of people use Amazon's Sentry service, Sentry becomes a company that is building software for Amazon to sell, while Sentry sees none of the money from those sales at all.
You're right that Sentry's already been quite successful for an open-source company—employing over 100 people is great, and far better than most open-source projects will ever do. But that's not much comfort if you know that you might have to fire most of those people if one of the major players ever starts hosting your product, and you're not doing anything to prevent it. I can certainly understand them not being comfortable with leaving that risk hanging over the company's head forever.
I also generally prefer the AGPL, but it it doesn't block a significant risk for open source companies that offer hosted versions of their software. Yes, the APGL blocks third parties from...
I also generally prefer the AGPL, but it it doesn't block a significant risk for open source companies that offer hosted versions of their software. Yes, the APGL blocks third parties from modifying the code and running it without providing the code to the public. It does not prevent a company from just running the code unmodified and selling that as a service. AWS is notoroius for doing this, see elasticsearch for one example. The economies of scale that AWS already has means they can offer the identical service at a lower price and likely higher reliability. The smaller companies cannot compete with the big cloud providers in that arena. The BSL prevents any of the cloud providers from offering a comparable service. For many open source companies, they need this protection if their software gets remotely popular.
No it's not. Have you ever heard of RedHat? Beyond that, a lot of my employers have made money from open source code. This either comes from support contracts or custom development. It's quite...
So, instead, Sentry could consider something like the AGPL, but since that is frowned upon by a lot of corporations, they won't. But, critically, it's hard to make money on open source at all!
No it's not. Have you ever heard of RedHat? Beyond that, a lot of my employers have made money from open source code. This either comes from support contracts or custom development. It's quite easy to do, you just have to have business sense and a marketing department.
Yes, this is true. I mentioned Red Hat twice in my post. But, many businesses have tried that route, and very few have been stable for as long as Red Hat. Also, Red Hat has not felt the need to...
Yes, this is true. I mentioned Red Hat twice in my post. But, many businesses have tried that route, and very few have been stable for as long as Red Hat. Also, Red Hat has not felt the need to relicense their code because like you say, they are not selling their code, just support. And finally, Sentry isn't primarily selling either support or custom contracts, they are primarily selling use of their platform. That is why they need the BSL, because it prevents alternative hosts from appearing.
Red Hat doesn't really care about CentOS, because it would be very difficult for a community who didn't write the code to provide as quality documentation and support as they can. Sentry cannot afford this because a single competitor can competently host their software, again because it's hard to sell open source software as the product.
But isn't the whole point that they want to avoid other corporations selling their code? AGPL would effectively prevent it, but the community could still make use of it.
So, instead, Sentry could consider something like the AGPL, but since that is frowned upon by a lot of corporations, they won't.
But isn't the whole point that they want to avoid other corporations selling their code? AGPL would effectively prevent it, but the community could still make use of it.
Yeah, I'm not entirely sure why they didn't go that route. They could easily offer a separate proprietary license for those who required it, and could strictly control what could be done in that...
Yeah, I'm not entirely sure why they didn't go that route. They could easily offer a separate proprietary license for those who required it, and could strictly control what could be done in that license. (They could still accept community contributions with a Contributor License Agreement.)
My understanding is that a lot of businesses are very afraid of viral licenses like the AGPL for fear of accidentally infecting their proprietary code, so it may have reduced their free/libre consumer base. But, I'm not Sentry, so I don't actually know what their decision-making process was.
This is a really exciting concept to me, and I hope that more software licenses with this type of conversion get put into use. There's a lot of software out there, notably old games, that it is...
The BSL is a standardized license with two distinct components: a license grant restriction and a conversion date whereby the license “converts” to a more permissive license (without a license grant restriction).
This is a really exciting concept to me, and I hope that more software licenses with this type of conversion get put into use. There's a lot of software out there, notably old games, that it is illegal to pirate but also cannot be purchased at any cost. This isn't as big of a problem anymore since GoG came around and it's easier to keep an old title listed online than it is to keep distributing physical copies, but having a license that could work to prevent old software from being unavailable at any price would be great!
Armin Ronacher, who works at Sentry as well as being an extremely well-known Python developer who started projects like Flask and Click, has published his own blog post about this as well: Open...
Armin Ronacher, who works at Sentry as well as being an extremely well-known Python developer who started projects like Flask and Click, has published his own blog post about this as well: Open Source, SaaS and Monetization
The first paragraph is interesting to me I think this happens more often than people care to admit. You want to share some code online, and you need to include a license to protect yourself from...
The first paragraph is interesting to me
More than a decade ago, a small piece of code that would eventually be called Sentry was born. When I wrote this code, I didn’t know much about open-source, so when it came down to licensing, I just grabbed the first reasonable suggestion thrown my way. That suggestion happened to be the BSD 3-Clause License.
I think this happens more often than people care to admit. You want to share some code online, and you need to include a license to protect yourself from liability. It just happens to be that most of the well understood and recommended licenses (MIT, BSD, Apache) fall into the category of being OSI and FSF compatible.
That doesn't mean that being open source (in regards to OSI freedoms) is necessarily the goal of the project or part of their business model. Sentry was never designed to be an "open source" business. This is evident by the fact that most of their contributions come from inside the company itself. If the company was truly modeled around open source, the downside of losing outside contributions would outweigh the risk of competing cloud services.
I hope that the BSL and similar licenses are adopted by more large companies and start to trickle down and become more standardized. I like permissive licenses, but code authors shouldn't have compromise on their terms because there are only a handful of licenses out there to choose from.
There are reasons other than code contributions that being open source can be valuable to a company, especially one with a product aimed at developers. Some of those OSI freedoms do a lot to...
This is evident by the fact that most of their contributions come from inside the company itself. If the company was truly modeled around open source, the downside of losing outside contributions would outweigh the risk of competing cloud services.
There are reasons other than code contributions that being open source can be valuable to a company, especially one with a product aimed at developers. Some of those OSI freedoms do a lot to de-risk the decision to use a particular piece of software.
If I'm choosing a package or service (such as Sentry) that'll be integrated with my own product, I have a strong preference for open source even if I initially choose to pay for the first-party hosted version and their own devs are the only people who've ever contributed.
The core of the issue is that closed source generally presents too high a risk. As long as the code is open:
We can host our own internal version if the pricing model of the service spikes or otherwise becomes untenable.
We always have the option to keep any data generated by the system in-house, and write our own converters for the format it's stored in if we need to port it to other systems.
If we need a key feature in the future and the manufacturer has no interest in building it, we can do so ourselves.
If there's some low priority edge-case bug that only affects us and three other people, we can fix it ourselves rather than waiting for it to come off the manufacturer's backlog.
Oh, I agree that these are real benefits and no doubt the reason why Sentry was published as open source in the first place. That's why their new BSL license was carefully crafted to preserve...
There are reasons other than code contributions that being open source can be valuable to a company, especially one with a product aimed at developers. Some of those OSI freedoms do a lot to de-risk the decision to use a particular piece of software.
If I'm choosing a package or service (such as Sentry) that'll be integrated with my own product, I have a strong preference for open source even if I initially choose to pay for the first-party hosted version and their own devs are the only people who've ever contributed.
Oh, I agree that these are real benefits and no doubt the reason why Sentry was published as open source in the first place. That's why their new BSL license was carefully crafted to preserve these benefits for their customers. They're picking and choosing the freedoms of open source that their company and customers benefit from, and discarding the freedoms that their competitors benefit from. I don't see anything fundamentally wrong with this.
This license is a lot more appealing to me than an "open core" model for the reasons that you listed. As long as I'm only hosting Sentry for my own company, I get access to all of the cutting edge and security features for free.
Interesting detail from the FAQ forum thread: the Director of Product Management at GitLab asks if they can continue integrating with Sentry and is told that it's a violation and they won't be able to.
I personally believe licenses like the BSL are a necessary step for any open source software, and I do consider it open source, in the AWS / GCP world order. Open source software made the modern cloud possible, but now those same cloud providers have the clout to just steal your work. AWS just hosting a black-box version of your project will demolish your business; they can drastically outprice you. I do think open source licensing could use more attention, but the BSL is a step in the right direction for many projects.
I don't know if the BSL is what's necessary for open source to counter the new cloud world order. For instance, I feel like Gitlab taking Sentry's open source code and running it on their servers under their brand is analogous to Juniper Networks taking FreeBSD and rebranding it as JunOS and selling it. In fact, this is not uncommon with BSD distributions. Their permissive license structure allows companies to come in and profit off their work.
Don't get me wrong, I think the BSDs have a lot going for them, but I think the GPL, and explicitly its "viral" nature, allowed Linux to take off so intensely. Changes had to be made available to consumers who had the right to merge them back upstream. This meant that Linux gained features and grew into a broader platform faster. However, it also meant that it was harder for someone to make money on Linux! Companies contribute because having the changes to Linux are valuable, and you might as well get them upstream if they're going to be public anyway (Android OEMs excluded).
So, instead, Sentry could consider something like the AGPL, but since that is frowned upon by a lot of corporations, they won't. But, critically, it's hard to make money on open source at all!
Linus Torvalds is nowhere close to being the richest man in the world; Bill Gates and Steve Jobs came much closer. Open source hasn't been very profitable as a product. It's been incredibly valuable as a process, but it has always been hard to capitalize on it in more conventional economic terms.
Red Hat and Sun Microsystems came close to having a model, but neither became a top ten company. Open source seems to more successfully be driven by collaborative development. Groups of people with common needs coming together to make something to fulfill those needs and forking when they can't agree. This is why some of the most successful names in open source are GNU, the Linux Foundation, the Debian Project, and the Mozilla Foundation; all collaborative efforts that are not really trying to sell anything. Sure, Red Hat and Canonical do alright (especially the former), but there doesn't seem to be a lot of room in their part of the market.
This is not to say that highly profitable companies don't produce open source software, in fact much of it is written by them, but instead to say that most of them don't try to monetize said software. Google can release all the open source code it wants, but it won't release GSuite or search or God forbid ads, and they've even backtracked some on Android with their focus on Play Services.
I like the AGPL (and I'm using it for Tildes), but it can't help with the cases that Sentry is worried about. The only real end result of it is that it makes sure that if anyone else builds on top of your code, they have to also open-source their modifications.
That's not what they're worried about though—Sentry is scared of someone like Amazon simply taking Sentry as-is and offering it as a hosted service, which is exactly what Sentry does to make money. If Amazon does it cheaper and integrates it with all their other hosted offerings (and they would), that would be more attractive and convenient for a lot of people than Sentry's standalone offering. If a lot of people use Amazon's Sentry service, Sentry becomes a company that is building software for Amazon to sell, while Sentry sees none of the money from those sales at all.
You're right that Sentry's already been quite successful for an open-source company—employing over 100 people is great, and far better than most open-source projects will ever do. But that's not much comfort if you know that you might have to fire most of those people if one of the major players ever starts hosting your product, and you're not doing anything to prevent it. I can certainly understand them not being comfortable with leaving that risk hanging over the company's head forever.
I also generally prefer the AGPL, but it it doesn't block a significant risk for open source companies that offer hosted versions of their software. Yes, the APGL blocks third parties from modifying the code and running it without providing the code to the public. It does not prevent a company from just running the code unmodified and selling that as a service. AWS is notoroius for doing this, see elasticsearch for one example. The economies of scale that AWS already has means they can offer the identical service at a lower price and likely higher reliability. The smaller companies cannot compete with the big cloud providers in that arena. The BSL prevents any of the cloud providers from offering a comparable service. For many open source companies, they need this protection if their software gets remotely popular.
No it's not. Have you ever heard of RedHat? Beyond that, a lot of my employers have made money from open source code. This either comes from support contracts or custom development. It's quite easy to do, you just have to have business sense and a marketing department.
Yes, this is true. I mentioned Red Hat twice in my post. But, many businesses have tried that route, and very few have been stable for as long as Red Hat. Also, Red Hat has not felt the need to relicense their code because like you say, they are not selling their code, just support. And finally, Sentry isn't primarily selling either support or custom contracts, they are primarily selling use of their platform. That is why they need the BSL, because it prevents alternative hosts from appearing.
Red Hat doesn't really care about CentOS, because it would be very difficult for a community who didn't write the code to provide as quality documentation and support as they can. Sentry cannot afford this because a single competitor can competently host their software, again because it's hard to sell open source software as the product.
EDIT: typos
But isn't the whole point that they want to avoid other corporations selling their code? AGPL would effectively prevent it, but the community could still make use of it.
Yeah, I'm not entirely sure why they didn't go that route. They could easily offer a separate proprietary license for those who required it, and could strictly control what could be done in that license. (They could still accept community contributions with a Contributor License Agreement.)
My understanding is that a lot of businesses are very afraid of viral licenses like the AGPL for fear of accidentally infecting their proprietary code, so it may have reduced their free/libre consumer base. But, I'm not Sentry, so I don't actually know what their decision-making process was.
This is a really exciting concept to me, and I hope that more software licenses with this type of conversion get put into use. There's a lot of software out there, notably old games, that it is illegal to pirate but also cannot be purchased at any cost. This isn't as big of a problem anymore since GoG came around and it's easier to keep an old title listed online than it is to keep distributing physical copies, but having a license that could work to prevent old software from being unavailable at any price would be great!
Armin Ronacher, who works at Sentry as well as being an extremely well-known Python developer who started projects like Flask and Click, has published his own blog post about this as well: Open Source, SaaS and Monetization
The first paragraph is interesting to me
I think this happens more often than people care to admit. You want to share some code online, and you need to include a license to protect yourself from liability. It just happens to be that most of the well understood and recommended licenses (MIT, BSD, Apache) fall into the category of being OSI and FSF compatible.
That doesn't mean that being open source (in regards to OSI freedoms) is necessarily the goal of the project or part of their business model. Sentry was never designed to be an "open source" business. This is evident by the fact that most of their contributions come from inside the company itself. If the company was truly modeled around open source, the downside of losing outside contributions would outweigh the risk of competing cloud services.
I hope that the BSL and similar licenses are adopted by more large companies and start to trickle down and become more standardized. I like permissive licenses, but code authors shouldn't have compromise on their terms because there are only a handful of licenses out there to choose from.
There are reasons other than code contributions that being open source can be valuable to a company, especially one with a product aimed at developers. Some of those OSI freedoms do a lot to de-risk the decision to use a particular piece of software.
If I'm choosing a package or service (such as Sentry) that'll be integrated with my own product, I have a strong preference for open source even if I initially choose to pay for the first-party hosted version and their own devs are the only people who've ever contributed.
The core of the issue is that closed source generally presents too high a risk. As long as the code is open:
Oh, I agree that these are real benefits and no doubt the reason why Sentry was published as open source in the first place. That's why their new BSL license was carefully crafted to preserve these benefits for their customers. They're picking and choosing the freedoms of open source that their company and customers benefit from, and discarding the freedoms that their competitors benefit from. I don't see anything fundamentally wrong with this.
This license is a lot more appealing to me than an "open core" model for the reasons that you listed. As long as I'm only hosting Sentry for my own company, I get access to all of the cutting edge and security features for free.