Re-Licensing Sentry
blog.sentry.io
blog.sentry.io
I don't think this is accurate. It will ensure that Sentry is protected from its work being used in a competitive fashion. While the issues pointed out in the blog post are real, competing isn't "anti-competitive." The intent and the effect here is to reduce competition, not increase it.
If that's Sentry's opinion (and it seems like it is), that's fine, but that's not what "anti-competitive" means. The word for that is "competitive."
(The specifics depend on the jurisdiction, but the behavior described by the FTC is what's widely considered "anti-competitive": https://www.ftc.gov/enforcement/anticompetitive-practices)
Time for the rubber to meet the road. Pragmatism and revenue > philosophy. Can't pay the rent and groceries with platitudes about "open source" from a vocal minority while cloud providers reap what you've sown.
I don't really get what these growth startups are supposed to be and for people who contribute nothing back maybe buyer beware is fair.. But it is dishonest to create these company sponsored communities that convert after taking input from individual contributors. Plenty of people try to help a community with out considering that this kind of thing happens and these products compete directly with real open communities through this temporary branding.
Open source was never about "free as in beer", it was about "free as in speech", which even in the civil rights sense is not absolute. Communities and ideas evolve, and it does a disservice to those who have contributed in a material way to the non-commercial software space to color them as heretics for trying to protect themselves from competitors with effectively unlimited resources.
I stay away from anything hosted by a startup for exactly that reason, and just yesterday someone looked at me funny for saying so since the last example was being forgotten.
(AFA any commercial product, that is the whole point of looking for a REAL open source community where other individuals might drop out but Apache, Debian, etc isn't going to tell you that they don't like their 501c status anymore.)
No true scotsman. If it works for the stakeholders, it works, regardless of what you want to call the model, whether that's GNU/Linux, Redis, Elastic, or Sentry.
GPL exists partly to prevent this kind of conversion once the community is diverse and non-profit project hosting is a good place to look for a community. It would be nice if everyone knew that and kept it in mind, but clearly they do not.
Imperfect analogy: If Uber gave away every ride for free, that would be more "competitive" for some definition (lower fares = more competitive rate), but, Uber would go out of business within months.
That example isn't as strong as in this case though, but the general idea holds (price isn't as clear as business model). In this case Sentry is saying in order to survive as a company they can't sacrifice their only source of revenue completely, or they'd have no advantage. In doing so, they are keeping their own company alive, which increases competition against other companies in their area.
So it reduces competition of their own product against themselves, while it increases competition (by keeping them afloat) by making them stronger against their competitors. There's no real better way to phrase this, and I think the shorthand here works just fine. I don't see this as doublespeak or even lax phrasing, just choosing a frame that makes sense given Sentry is the one speaking.
On the flip side...now if Uber were to provide rides below cost with the intention of putting the competition out of business then that would be the textbook definition of "anti-competitive" behavior.
Sentry is actually exercising their government granted monopoly (aka copyright) to ensure that no competitor is able to use their codebase to directly compete against them which is the exact opposite of increasing competition.
I have no dog in this fight and am not judging what they're doing so...
A better analogy: T-Mobile will go out of business because they set poor terms on franchisees that let them exploit and take business from T-Mobile. Now T-Mobile is days away from folding. Here’s two scenarios:
1. They fail, both T-Mobile and franchisees go under.
2. They change the terms, killing the franchise model. Only T-Mobile survives.
In this case I see number 2 as better for the market. Better to have one bigger competitor in a nearly monopolized market than have none - it’s more competitive and you’d see lower prices for end users than if they failed. Same goes for Segment.
There is also an argument to be made that such an action by Amazon fits squarely into the "single firm conduct" category of your linked FTC resource.
The opposite of being anti-competitive is not simply competing, it's competing fairly.
It is pretty clearly free riding to take the creative output of another company, repackage it for money and contribute little or nothing in return.
The world is poorer when this happens because free-riders can freely have business models that "kill the host", that is, don't capture enough value to keep people working on the underlying product.
Perhaps the answer is "well it shouldn't have been an open source product then?" and then we all miss out.
Meanwhile Amazon celebrates turning off all their Oracle databases. Great! And they make a lot of money off the back of Postgres too. But try asking them for the code that bundles Postgres into a reliable managed database offering. Of course they won't share it. That's their IP.
I completely agree and I think you found the perfect word for it: free-riding. As you note, anti-competitive has a specialized meaning. My comment was simply that free-riding is not, on its own, considered an anti-competitive business practice.
In the end, this is precisely what the license change is trying to prevent. It's happened to several database companies at this point, and they're simply trying to hedge things off on competing SaaS providers (their commercial model).
I know some may not like less than "Open Source" licenses, but the reality and practicality of the real world does at time necessitate it.
I think more people are put off by perceived bait-and-switch or claims that a given piece of tech is open (with all the benefits that come from that) while making it not actually open.
If it’s a duck, call it a duck. If it’s a hunting decoy, don’t call it a duck.
I think for customers having different companies have their own approaches to solving this problem is vastly preferable to having different companies solve the same problem in exactly the same way.
Example: Our company self-hosts sentry, this license won't effect us at all, we're still free to use and modify the source. We only use it internally - we don't sell "access" to it.
---
This is cropping up more and more with various software companies. They _want_ to keep their source open. But people take the source, and just start selling it (Looking at you amazon) without actually contributing. It's one of those, "This is why we can't have nice things"
Words have meaning, and trying to change the meaning of open source to benefit corporations is not something I'm willing to get behind.
They are still open source because the source is open.
Not every open source lic is like MIT where you can do whatever you want.
if it is not, then Sentry needs to consider whether it is important for them to stay Open Source or not.
and, if we see many more cases like this, then maybe it's time that we rethink what the Open Source definition should be.
it looks like neither Open Source, nor Free Software haver put much consideration to this problem yet, and it's time that we look at the implications.
my expectation is that any change in the definition of either will not meet much positive reaction, but i think the discussion is worth having.
That is not the definition of 'Open Source'. Using it interchangeably with 'open source' just adds confusion. And from the other uses of 'open source' in your comment, it seems you're using it in the same sense as 'Open Source'
> Not every open source lic is like MIT where you can do whatever you want.
No Open Source license allows you to "do whatever you want". Even the WTFPL, which comes close to that goal, is not an Open Source license. Being Open Source comes with a few requirements, which every Open Source license, licensor, and licensee must fulfill.
You can provide Sentry-as-a-service but you can't do so commercially.
You can use the Sentry code commercially but you can't use it to provide Sentry-as-a-service commercially.
If MongoDB were AGPL, both a company providing MongoDB-as-a-Service and a non-profit web app using MongoDB in the backend would equally need to publish their source code.
The BSL just says "you can't do this one specific thing for 36 months".
The AGPL is a more viral version of the GPL, which basically says "if your code uses this code, your code is now GPL licensed" and also "for all GPL licensed software you distribute, you must also make its source code available" (with the AGPL just redefining that "distribute" as "distribute or make accessible as a service").
Nor do I, but for slightly different reasons.
> it won’t change anyone’s ability to run Sentry at their company
I can't go up to a lawyer with years of experience trying and defending against BSL lawsuits and say "Is my usecase one Sentry can sue me for and win," because such a lawyer doesn't exist.
At least with other licenses, their actual legal limitations are well known, through case law and court rulings. The BSL in contrast is a legal liability that is probably not worth betting a small company on.
Sure, the Sentry of now might never do that - but if/when they're acquired for their patents and licenses that acquiring company may.
And the three year conversion window gives you cover there. It's a question of will the Sentry of the next three years do that.
Two people can compete. Tomatoes and people are complementary - it's nice to have both. Tapeworms and people are playing a game in which, if the people win, the tapeworms lose, and if the people lose, the tapeworms lose to.
At the same time, I remember seeing a new startup that had completely ripped off Sentry + docs and had just done a find and replace for the company name. I thought I had read about it on HN but I can't find the link. It's clear we need a license that allows software to be developed in the open but prevents this type abuse.
I don't know if this license is the solution. It clearly isn't open source and should not be construed as such (they are very clear about this in the post), but I haven't seen other better proposals either. Armchair criticism is easy, and this seems like a reasonable middle-ground. We'll keep using Sentry and continue to be customers. Outside of their Sentry.io product, they have released and contributed to a ton of other Open Source libraries. As I understand it, that will continue. For me, this passes the sniff test.
The ability to fork is the point of open source, because it assures continuity. The price of this is the non-zero probability of hostile forks (which I would not classify as 'abuse'). I think there's a section of technologist who license their software for pragmatic (traction, fixing bugs) and not ideological reasons and get surprised when someone forks the project in a way they don't like.
But why not? That seems like such an arbitrary distinction if it weren't for the fact that the company is trying to profit on being the exclusive hosted provider of the software. Why wouldn't I want to pay a company that's better at ops to host sentry for me?
The options are: Use Sentry.io, host it yourself, or use something else.
If they can do a better job of marketing with that new name, they deserve the success.
Who will win? Who should win?
It would please my personal sense of justice if the big R&D company also won, but I am satisfied with the simpler requirement of end users not getting shafted and the product thriving.
It's no guarantee that a company with 10/2 of marketing/R&D split would be any better than the other company with 2/10 of marketing/R&D.
Anyway, "morals" aren't the standard by which these things are judged in practice, ethics via laws are, and I'm fairly certain most legal systems don't see the practice of IP theft as fine.
There are a lot of different reasons [1] why someone might want to maintain an open source business and the threat of someone forking your business might not outweigh other positive effects.
--
[1] Transparency for privacy/security reasons, political leaning towards free software, hope of third parties tracking down bugs, PR boost within the open source community, etc.
Did you mean Opbeat? They did use Sentry client code in their service implementation (https://news.ycombinator.com/item?id=12800833) but their focus was on APM not exception management.
That's disappointing. Unfortunately, the more companies use such licenses, the more others see it as "safety in numbers" for them to do the same.
Using a standard license is great. Using a custom license that is extremely similar to an existing license is not as good, but is usually workable...
Showing legal how to use Github so they can confirm the age of the software you're using, then convincing them Github is a reputable party will likely result in an unpleasant conversation at best.
A conversation made far less pleasant by the ability to feed arbitrary dates into a Git repo's commit history: https://github.com/gelstudios/gitfiti
I'm sure there's a way to find the actual time a push happened; hopefully it doesn't involve subpoenaing GitHub (or Microsoft, I guess) for logs.
Also, print all of that, get the legal to seal the pages, and put them into a safe.
Wouldn't that be:
> Showing legal how to use [Microsoft] Github so they can confirm the age of the software you're using, then convincing them [Microsoft] Github is a reputable party will likely result in an unpleasant conversation at best.
Seems that 'Microsoft' prefix might get a bit more clout.
You only have to do that if you're setting up a commercial service that competes with sentry. If you're merely setting it up for your own company's self-hosted use, you don't need that.
This might be one actual positive of GitHub getting bought by Microsoft: convincing people who don't know anything about software that it's a reputable party.
Pick one which was cut at a particular point in time and you're done. Doesn't seem that complicated.
I just want to clarify that in addition to BSL converting into an Open Source license after the conversion date, we also did not BSL license everything. Client libraries are completely unaffected and so is a lot that is going on behind the scenes. We're firmly committed to being good Open Source citizens. For instance a lot of the work that is going on behind the scenes is separated into independent reusable libraries that retain their original licenses.
Lets be clear here too- I'm using your product right now, and I feel that this is a huge betrayal of trust.
There is no good answer to a loaded question like this. If you suspect malice I have nothing I can say to counter this.
- Borrowing bits of code from Sentry for use in an unrelated, non-competing commercial product will no longer be possible for many people -- I suspect many companies' legal teams will bar use of BSL-licensed code out of caution, at least until the 3-year conversion point.
- Using bits of Sentry for internal, non-distributed projects may not be allowed if there's any chance the project will convert to a commercial product (competing or not) within 3 years.
- I suspect there are other scenarios that are technically and legally possible (at least by Sentry's interpretation) but that many corporate lawyers will nix based on an abundance of caution.
- And of course, starting a new open-source project with open governance based on current Sentry code will no longer be an option.
The thing is, BSL's permissions may seem clear to developers, but lawyers will likely get hung up on how to define "competing", and whether a judge would allow a suit to proceed against a (intuitively speaking) clearly non-competing product based on real or perceived ambiguity in the license or in the case itself. Too often, legal teams "just say no" to anything that falls outside their clearly defined (and legally tested) comfort zones. I don't blame corporate lawyers entirely for that, though - it's really a consequence of the legal climate arising from prior case law (which I believe often proceeded on dubious grounds).
The license is clear that there is a specific application of the software that is protected; you are not prevented from using the software in a way that prohibits all commercial use.
If you really don't like what they are doing, you could fork them right now. But my guess is that you won't because then you'd have to do the work you're getting for free now.
Right now there's this trend where companies take the benefits of open source for themselves, then toss aside the open source community when it looks like it might make them a buck. Ultimately I think that is bad for the community, and that the corporations that do this are putting their profit above the community that helped them grow. I don't think it's unreasonable to point this out.
The BSD license is very clear that you can not assume that. A developer who contribute patches under BSD license should have no expectation for what other developers will license code in the future. Licenses is all about defining expectations.
Well, there's their problem. They shouldn't assume anything they want a 3rd party to do that's not in the license. Instead, they could offer contributions with a contract that forced the next version to also be open source.
The people buying software should assume companies might do anything the license allows. Those supplying software should assume those using it might do anything the license allows. They should change the license and contract to forbid what they don't like or ensure certain protections they do want.
This company fixed its license to reduce a risk in the old one.
The narrative you're trying to paint is misleading at best:
> It’s important to remember that Sentry “the project” has been developed almost exclusively by employees of Sentry “the company”; millions of dollars have paid the salaries of engineers, designers, and product people to produce the software we know and love today.
They are the primary contributors to their own product and the existing "community" that use in-house versions remains unaffected, they can continue to use modified versions and contribute back features everyone else can benefit from, which I see no reason why they wont continue to do as they can continue enjoying all the benefits of being able to freely use their own hosted versions. But those outside contributions are going to still pale in comparison to the vast majority of contributions that Sentry makes in improving their own product, the most valued contributions Customers are going to make are in the form of feedback, feature requests and detailing how they're using the product.
They're definitely not "toss aside the open source community", their BSL is specifically targeted so that "it won’t change anyone’s ability to run Sentry at their company". You're insinuating the opposite that they're discarding their existing community, when their license is specifically targeted to allow continued free usage by their customers and is only designed to prohibit their competitors from taking of Sentry's investments and using it to compete against them.
This change gives them a more sustainable business model that better protects their investments against competitors reselling their efforts and undermining their business model that's directly used to fund the investments in making a better Sentry product. It's a win for Sentry the product and company and their customers, the only losers from this change are cloud monopolies and Sentry's competitors who are more than welcome to use their own efforts and investments in creating their own competing product.
Who is sentry hurting by making this change?
Good open source citizens usually don't close their code to prevent competition. If you want to go proprietary that's fine, but you're going to get infinite push-back if you continue to say you're a good open source citizen.
They're not falsely claiming that BSL is open source. They're not switching to "code dump" open source model where they'd just dump 3yo old code on your head. They're not completely closing it off either (which would be entirely legit move if they wanted to).
Seems like they're doing the best they can, while still trying to, you know, make a business. Time will tell if BSL is the right move, but looks to me like they're sincerely trying.
There are words, and there are actions.
The actions indicated by that blog post aren't those of "good Open Source citizens".
Today the primary goal should be to build an open software ecosystem independent from the SaaS / Cloud behemoths and with a business model that isn't based on surveillance.
Nothing is actually free. Open source was built on a social contract with certain "gift culture" assumptions. SaaS is violating that social contract by only taking and in a way that ultimately harms the 'freedom' goals of open source, so the social contract must evolve.
Companies will be able to invest more into their infrastructure without much risk. Customers can still contribute back knowing that they will eventually be able to use the OSS version once it matures.
Over time we're seeing there needed to be this sort-of middle ground license for companies, which is essentially, "anyone can use it as a dependency, but you can't use this product, slap a different label on it and then compete directly with us" and it seems that this and related licenses are going to accomplish that.
https://books.google.com/books?id=xBANKuFJWtUC&pg=PA306&lpg=...
EDIT: s/GPL/AGPL
If you want a concrete example, take Redis. (and it was longer ago, but I think I recall something similar with mongodb)
Redis Labs offers a hosted cloud offering, Redis Cloud Pro. They literally run off of AWS, as near as I can tell just selling managed EC2 instances, with replication etc. Then Amazon launches ElasticCache, which is running apparently unmodified Redis code, with AWS-developed management software on top.
Redis changed their licensing following that launch, for mainly the same reasoning as Sentry mentioned - Open-source company sells managed hosting, uses that money to further development of the open-source software. AWS (or Azure, or Google) launches a competing service, contributes nothing back to the open-source software. It's not healthy for the long-term prospects of the community (but it's great for AWS investors bottom lines).
Redis also continues to be BSD licensed.
For even more nuance, Redis Labs wasn't the author of Redis, they only sponsored the author. They weren't the first sponsors either, and nothing's stopping others from sponsoring Redis either, as long as it continues to be BSD licensed. That's the point of Open Source, that anyone can come with even just a brick to add to the cathedral, and everyone enjoys the benefits from the addition of that brick.
With closed source software, that freedom is gone.; all progress now has to go through (and be owned by) just one entity. I wouldn't want to contribute to a BSLed project because I'd be a second-class citizen in it. And even I did put out a BSLed patch to a BSLed project, the project owners can't use it for as long as I retain the copyrights on my patch.
If Amazon needs to make changes and opem source it, they can and without risk to their market because its value is in scale, balance sheet protection, name recognition for management buy in, and the integration on their AWS platform.
Running AGPL code on your server without making it all AGPL or GPL (which itself is only possible because of an explicit exception) is discouraged, or at minimum a legal gray area, at least from what I understand.
BSL code on the other hand is totally fine to run on your server, as long as the service you're providing isn't within the specified area.
But since you're not "free" to use that code in any product, it's not considered free software.
Personally, I think at some point the distinction between free and not free is arbitrary at some point, because while it's true that the BSL code can't be freely reused in truly open source project, you also can't reuse AGPL code if you're using the vast majority of open source licenses for your project.
This line _really_ bugged me. These licenses are still a perfect fit and more than sufficient for how OSS is distributed & used today. What they’re maybe not perfect for is starting an open source, VC funded business, but they never have been. And the companies that face “existential threat” are a small minority of the total activity going on under these licenses, so maybe, ya know, the problem is the small collection of companies trying to operate this way and not the license.
I'm not against these sorts of licenses. But we should all be aware that companies like this (and Mongo, Elastic, etc) are a step away from the OSI model of "open source". Which is more about many orgs collaborating on a shared solution so we don't need a vendor, rather than what this is - a vendor opening up code and allowing contributions.
To the open source fundamentalists expressing disdain: why is the ability to commercialize a piece of code such an important part of the OSS ethos to you? Why are proprietary protections, even when the code itself is still freely visible, usable and modifiable, such a step backwards? What about the very real threat of a business 1000x your size just deciding to fork your code and eat your lunch? Are businesses with open source products supposed to just accept that risk in the name of being good OSS citizens? I'd still much rather see a business with source available code, which will still benefit their users and the community at large - would you rather it be OSI approved open source or nothing?
"Open core" products have an open source core. Sentry won't any more.
> Enter The Business Source License (BSL)
This license is NOT open source. Don't call it that. Actual open source advocates like me will keep hectoring you until you stop.
The blog post says this: "due to the grant restriction, it is formally not an open-source license."
> It’s a brave new world, but we believe this licensing change will best ensure the future of Sentry and that protections-oriented OSS licenses like the BSL will become increasingly common as time goes on.
"protections-oriented OSS licenses like the BSL" - I guess they can't call it an "Open-Source license", but calling it an "Open-Source Software license" is ok? Are they supposed to mean different things?
Also I think that the assertion that it's "actively harmful" is wildly hyperbolic. Sentry isn't going to be out there copyright trolling people and you know it; they're trying to protect themselves from a very specific category of IP infringement. And there is still much potential upside to it's openness that you're willfully ignoring.
> you can inspect, modify and use the code as you can with any OSS, the only things you can't do is commercialize or redistribute it.
That depends on your definition of "use". IMO this is like the the opposite of the GPL and it creates a licensing mess. If I find a piece of code in Sentry that I would like to use in a separate project, that project now has to be licensed under the BSL and subject to those terms unless I can prove I pulled it from some version of the source from however many years ago. And if there's bug fixes to that code, I can't use those bug fixes until the change date expires for those bug fixes. And depending on what license my project currently is, determining if I can even "relicense" as BSL is messy. The end result being that nobody is going to want to use that code in their own projects, and if they do they're likely walking into a licensing mess which they may not even realize.
And that's half the point right? They're happy to take community contributions, but they don't want people using their code. Which, sure, I work for a company that sells software, I'm not against that. But in my view that's not "open source".
They're very clear in stating that the license is not open source.
Yes, they don't call it that. Seems like the actual open source advocates will hector them before they even start.
> It’s a brave new world, but we believe this licensing change will best ensure the future of Sentry and that protections-oriented OSS licenses like the BSL will become increasingly common as time goes on.
The proper term for licenses like the BSL is "source available". You can view the source, but you cannot use it under terms which conform to the Open Source Definition.
Of course it would be great if everything could remain truly open source, but I can understand the IP concerns as Sentry grows, and I am appreciative of the communication and commitment to offering the same product for self-hosting as your SaaS product. I'll be continuing to use and support Sentry and am interested to see how the BSL model goes here compared to something like open-core.
Patents and Copyrights are more than an order of magnitude more temporally restrictive. This is great stuff, I hope it proves to be commercially viable and sees broader adoption.
I’m happy as a Sentry user, and while we’re using the cloud offering right now in our early stages, it’s good to know that if we would crumble under the costs, we can always host our own instance. (Which of course is unlikely to happen, what I expect to be a part of the strategy)
The moral equivalent of the BSL is to close-source the software, and to offer free-for-use licenses of the closed-source version. They can continue having a fully open-source release, but the release would be changes from 3 years ago.
Sentry isn't doing this because they want the contributions. They want the benefits of open source, without any of the costs associated with it.
Also, the closed-source code not being viewable makes it more likely that folks won't accidentally introduce copyright violations into their code, which frequently happens when proprietary code is put into github.
In either case, the code is closed-source, but BSL allows them to accept free code from volunteers without providing it back to them for 3 years.
You're suggesting a strictly worse outcome for the majority of people (users, and sentry) in the name of purity.
Sentry is granting you a license, for free, to do anything you want with the software except provide a commercial competitor to their hosted service. People using the software for free may still decide to contribute code. This is not a one-sided relationship here. Both parties are getting something of value.
If the contributor is not allowed to do something with their work that the receiver is allowed to, is that not one-sided?
The benefit you speak of is available to both parties. The benefit I speak of is available to only one.
In Open Source, every party gets all the benefits, all the time.
Now, I'm not disagreeing that one of the goals many people have for building code is to make money. But this line between apps and libraries is completely artificial and seems to exist for no reason other than justifying their closing a previously open source project.
I generally believe that people should get a reward for the work they do. For me personally the rewards I got for my work on Flask, Jinja and many of my Open Source libraries was non monetary but awesome on many other levels. I got to travel to many countries, speak at conference, and I got a lot of experience and exposure through it. I am content. However I know from many people that they wish they could also make a living from Open Source libraries and I do not have an answer to that — yet?
I believe the BSL is an answer for applications, I don't think it works for libraries because of the reasons mentioned. I wish I had an answer however for people that want to live off their Open Source work.
The line might be arbitrary for some, but it's not arbitrary for me.
Then they get a job teaching art to the next generation of people who really, really want to live off of making art.
It is. It turns libraries into a free commodity and this turns the efforts of developer into unpaid labor for companies selling software or services.
I don't think libraries should be unpaid labor — I just don't have an answer for monetizing them. That's the difference.
I think with a suitable developer culture (people actively contributing back to the commons), that this is a great model. Unfortunately in the real world there are many more people willing to take from open source then contribute.
Almost all users of Sentry.io benefit from the sort of freedom that FOSS is built on. They can control and modify the source that they are working with - sentry.io doesn't take away their rights.
At the same time, sentry.io does not have to compete against clones which are using sentry's own R&D against them.
I much prefer this over more restrictive alternatives.
As far as I understand there’s still nothing preventing me from forking their code, just from selling it for 3 years.
I do wish more companies would use these kinds of "Doom clauses" and contribute old software to the commons once it's no longer commercially viable.
I don't mind when my open source library is one tiny part in a larger project that is commercial and making money. But I'd be upset if someone forked my library, changed the name (or not), and started trying to collect donations. Even if they changed the library I don't know at how much they'd have to change it before I'd not feel taken advantage of.
Selling 1 is the same as selling 2, is the same as 200. If anything, distribution the costs will go up due to bandwidth (unless the distribution becomes decentralized).
The problem is that we live in a world economy desgined by and for material products with (in many cases) marginal costs. Making a single paperclip is expensive, making one thousand makes every paperclip cheaper, making more makes them even cheaper. If paperclips were software, the moment anybody makes a single paperclip, anybody can have one.
Software is (or rather, digital things are) different. The best model of ownership over software does not get along with the way ownership works in the market.
Many dependency managers just grab the latest release of an open source project, and you as a software developer may not be aware that one of your open source dependencies has changed their license in a way that affects what you can do with your project.
It seems a lot of projects are starting out as true open source projects and then once they have built up a user base, are changing their license to something else. It would be nice for me to have a better way to monitor this for my dependencies than just checking the front page of Hacker News.
Their software also converts into Apache-2.0 after their conversion period, where it by definition also becomes available under a permissive OSI approved license.
Being licensed under an OSI approved license (that their software converts to after their conversion period) makes it "Open Source" by definition, it does not make it "closed source".
My other side project is a PaaS which I hope to release as Open Source, which relies on several open source products itself. I also hope to offer a hosted version of this product. It is still a very young idea, with some code written for it, trying to get a proof of concept done. I had considered using Sentry for an APM tool in this product- but now if I go that route I will have to fork the pre-BSL version of the Sentry code and maintain it myself...
If my PaaS is successful, I do plan to contribute back to the open source tools it will be based on, both in terms of development and financially, as well as promoting them prominently! I am not looking to cut anyone out by providing a low value-add service and keeping all the profits for myself!
Given that Sentry is primarily the sole contributor behind improving and advancing their own product, making it more sustainable directly translates in being able to have more resources into making a better product whereas having their efforts stolen and repurposed by a competitive AWS/Azure hosted solution would directly make it worse. They'd be pouring their millions into competing against themselves whilst the cloud providers can use their marketing + monopoly network effects to reap all the commercial efforts off Sentry's investments.
The only losers here are the cloud oligopolies and Sentry's hosted competitors, Sentry ends up with a more sustainable business model they can invest in making a better product, which benefits their product and all their customers.
The other ideal is the principle of free software being like software I would write myself. MIT and the unlicense are strong versions of this, where I can use them in (nearly) any way I would use software I had written from scratch. The BSL is the better model for this, because it entails paying for software that, in a few years, you will own in this strong sense. Open core entails no such guarantee, and if the company producing it went under, there is no guarantee that they would release the source code under a permissive license.
I think the impetus behind their decision is that they didn't observe a strong open development community, so they didn't feel they would impact that too strongly by using the BSL. The really interesting license would be a combination of both, that is having a truly open core, then licensing everything else under the BSL or equivalent. This is probably avoided for the complexity factor, but would probably entail the best of both worlds.
But it’s troublesome that they road the open source movement for years to grow and are now closing the license. Perhaps it’s a business reality. I wonder if there are any supporters or users or other stakeholders who thought open meant continuing to be open. They’re getting a slap in the face today.
I think what they meant to say was "open source licenses (including GPL, BSD, and Apache-2.0) are not sufficient to prevent Google or Amazon from competing with our hosted service business."
Do you have any proof to back this assertion?
> It’s important to remember that Sentry “the project” has been developed almost exclusively by employees of Sentry “the company”; millions of dollars have paid the salaries of engineers, designers, and product people to produce the software we know and love today.
I don't have any skin in this game, but they claim that most of the code contributions were by employees paid for by Sentry. Do you have evidence to the contrary?
On a side note, most people contributing to F/OSS don't like AGPL either. They'd instead by griping about that. Folks be irritated one way or another. His profit and their jobs are safer with people griping about BSL, though.
And nowhere is that list to be found. So it appears Sentry is violating the license for external contributions.
Wait what?
Easy to be a purist, hard to reconcile that purism with the need to run a business (and let's not forget, pay engineers and other employees with the proceeds of that business).
This corporate take over and redefinition of open source needs to stop. The "Business Source License" is not an open source license, and lying to the community about it is nothing short of gaslighting. This decision is bad for the community, and no amount of marketing speak and lying from sentry is going to change that.
The benefits include things like volunteer labor, more alpha testers, and community goodwill. The negative is that you have less control over how your software is used.
I don't have an answer to how we can stop AWS from reselling open source software. I do know that redefining open source is not the way to handle it though.
Look, if Sentry wants to make money selling their software they should have just been proprietary from the beginning.
AWS has more than enough resources to re-implement (or fork/maintain) your software. So if you write a license that pisses off your own community and prevents AWS from using it, then that's probably what they're going to do, and now you have no users.
The answer to AWS running a hosted version of your software is, encourage it and ask for patches and contributions back.
They're saying you can use it for anything except building a competing product.
You drew a line in the sand, do not presume that someone else will draw the line in the same place. For example, some people draw the line at GPL. I, personally, greatly prefer a BSL license to a fully proprietary license. That means, from me, they do get both.
If we just let everybody call them self opensource and free, those terms will loose all of its meaning.
The fact that BSL is better than completely closed source option is different discussion.
But they take the successful open source thing, skin it, provide something similar with the same API, and that's it.
This contributes back nothing to the community. It actively distorts the cashflows. (Because instead of hiring someone to set up a let's say ES cluster, or buy it from elastic co. they buy it from AWS.)
Many developers at Amazon love(d) using Sentry, and one wanted to contribute (in a small way).
If you don’t want it to be open, don’t make your code open. (It’s not open by default.) If you do, don’t be surprised or dismayed when someone takes you up on the offer you created.
There are more things than the extremes.
I don't think we need software Manichaeism. Software can be as open or closed as anyone likes with many degrees in between.
It is preferable for everyone to have software that is relatively permissive but has barriers in place as to not run into a tragedy-of-the-commons like situation where large companies simply take the code of small innovators wholesale and profit off their work without contributing back. License extremism is silly.
Why would we be better off if sentry completely closed down their source code, thus robbing everyone of running and using sentry themselves?
BSL is just better proprietary licence. It definitively isn't open source. I think of it as better way to do shareware. But there is big difference between shareware and open source and we don't want to muddy it.
If all you do is use sentry internally (which is a major use case for this particular piece of software) you can do what you want. This is not at all close to a proprietary license.
Can I sell this product as SaaS ? Can I put that code in a library that would be usable by SaaS product ? Who decides if it competes with sentries ? How about if sentry suddenly adds functionality it didn't have before, so now it competes and before it didn't.
Or maybe they don't get to do their IPO and are bought out by oracle(or similar). And their lawyers smell an opportunity ?
If this code would be any other standard open source licence the answers is simple. I don't even have to ask anyone.
But sure if I wanted to use it mostly like flexible shareware internally I can do that.
I think that's a fair decision for them to make and license their code accordingly.
They said very explicitly in the article that this is technically not "open source"
I do disagree with the use of “technically” in the last line. It’s simply “not open source” (which is, of course, fine).
Does it matter if they do that or do their own thing with an interoperable API (possibly starting with a code base forked from the last open source release)? Do you think that AWS can't afford the engineering to do the second if there is a business opportunity and the first is foreclosed by licensing terms?
Aside from all the other arguments, I don't think this licensing gambit has a chance of actually protecting substantially against the problem that supposedly motivates it, except by reducing the profile of the product to a level where AWS has no reason to care about releasing a compatible service.
Free software is the one about freedom.
This license (BSL) is source-available, but it is clearly not compliant with the terms of the Open Source Definition, which Sentry acknowledges.
See also:
https://en.wikipedia.org/wiki/Source-available_software
https://en.wikipedia.org/wiki/Open-source_software
https://en.wikipedia.org/wiki/Alternative_terms_for_free_sof...
They do state that it is not an open source license in the article:
> Although we’ve come to refer to the BSL as eventually open-source since it converts to an OSI-approved license at the conversion date, due to the grant restriction, it is formally not an open-source license.
They're sending a giant Fuck You to anyone who contributed their time and effort to the project. It's a completely unethical thing to do.
I have no problem with someone using one of these horrible licenses, if they use it from the start. But to adopt it after the fact is blatant exploitation.
No shame in one party deciding to just walk away.
I hear lots of people complaining about this. That it's some sort of theft. Yet, I've rarely seen people actually use the OSS license and decide to take it their own direction.
I think this really ends up reaffirming what Sentry is saying in the first place. It's hard to build a OSS project and you get too many freeloaders.
You're basically a freeloader and now you're upset that there's no longer a free ride.
BTW. Not trying to be insulting by using this term 'freeloader'. I wasn't trying to be derisive just saying you were getting value for free.
Less bloat, no vendor lock-in, works with any logger.
I believe the current number is ZERO.
I have put a lot of time/money perfecting the recipe/brand . I started selling it to local businesses and have been expanding slowly but steadily. I don't have big production scales yet so I can sell a bottle for $3.
Now come Big Beer Co., #1 on the beer market world wide. They take my recipe and can sell it for $1 thanks to their economies of scale. I keep making my beer better and better whiel Big Beer Co. keeps the original recipe they "forked".
I start losing customers: yes I keep improving on the recipe but it does not justify paying $3 instead of $1. Eventually, I die and Big Beer Co. are the only one remaining selling my recipe.
Is it because they made a better product? Nope.
If you could, that would still be the smallest part of the dynamics of why people drink craft beer and how the economics of scaling up production of a recipe work.
* - And trade secrets don't lend themselves to openness.
Perhaps I could have been more clear: I explicitly share with everyone the exact process/recipe so it is reproducible without any other research.
The real problem you have is lets say you are that craft brewer and you are doing really well with your $3 a bottle beer, so well in fact you want to expand so you can prep for your big IPO. Well it turns out brewing beer at a large scale is fairly hard, but lets say you figure that out because your an awesome brewer. Its even harder to run a national distribution network, and you have no clue how to do that. You will quickly learn that the reason Big Beer Company is doing so well has very little to do with the taste of their beer. Yes they do a lot to make sure their product is great, but mostly its to make sure the product is uniform, and reliable. The real magic is the business side, they have suppliers, an distributors who can get their product into every store in America. Their product isn't beer their product is beer distribution, you can't compete with that, because your a craft brewer not a logistics expert.
This is the same thing going on with the big cloud providers, if your product is just a logging system you will loose to the company who can deliver that service to users at scale. The product is the service not the software.
All these "formally-open-source companies" are learning the same lessons we learned in the early 2000s: competing on software alone only works if you're licensing a proprietary product, or you're giving it away as a lock-in tool for a platform you control. The alternative is to compete on service and support, which works until you compete against a platform. A big player with a platform will just take ten million dollars and a year and a half and write their own version of it, and their customers will use it because it integrates with the platform's products better.