Hacker News new | past | comments | ask | show | jobs | submit login
Re-Licensing Sentry (sentry.io)
348 points by troydavis 15 days ago | hide | past | web | favorite | 280 comments



> The BSL lets us hit our goals in a clean and low-impact way: it won’t change anyone’s ability to run Sentry at their company, but it will ensure that we are protected from our work being used in an anti-competitive fashion

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.


We agree that this language isn't correct and are going to publish an update. Thanks for pointing this out.


But they're not competing. They're not trying to do something similar in a more efficient way. They're parasites - genuinely, even literally. They're taking away the energy sentry needs to run themselves but, if they succeed too well, they will destroy their own capacity to run.

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.


It does reduce the competition of the "We provide Sentry as a Service" kind but it still allows people to create their own Sentry-like product of which they can also provide as a service.

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.


It would be cool if they started that way, but closing their source and pretending that it's to make the market more competitive is really a stretch.


They aren't closing their source though, just making it against the license to use it as a hosted service.

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"


"Open source" has a definition, and they are removing their project from that open source definition. Even their own blog post acknowledges that they are no longer open source.


Saying that the source is "closed" seems a stretch though. Its certainly not free software any more. But even if it doesn't meet the official definition of open either (at least, for 3 years per contribution), there's still a lot of utility to be had.


Proprietary software with code that's viewable is actively harmful. It's worse than being closed. If you read the source, and use it (or a very similar version derived from it) in your code, you're including a copyright violation into your code.


You can still modify the code for personal and business use, as long as you’re not making money off of it, you’re fine. This is far better than it being closed source.


You can make money of it. You just can't use it to run a SaaS based on Sentry. This is a lot narrower than a general "non-compete" with a very minimal "non-commercial" restriction.

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.


it may prevent me from hiring you, because i can't trust that you don't accidentally use something you learned from that code in your work


Sure- freeware, trialware, and other licenses have a lot of utility too. That doesn't make them "open source" though.

Words have meaning, and trying to change the meaning of open source to benefit corporations is not something I'm willing to get behind.


But this restricts corporations from selling this as a service. Similiar to how some open source liceases require you to provide any modifications if you choose to reuse and modify.

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.


> They are still open source because the source is open.

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.

https://opensource.org/osd


Open Source has a definition. It includes things like GPL and MIT- a wide range of options. The BSL is not an open source license.


Well, what is your solution? Have Sentry go bankrupt because AWS takes their service and offers it at a scale Sentry can't?


the solution is to vet the license and consider whether it is compatible with the current Open Source definition.

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.


Can you identify a single company that's happened to?


No, because they’re dead. Withered on the vine.


So, "source available"?


"source available" but with a built-in mechanism that converts the source to "open source" after 36 months, hence "eventual open source".


How's it different from AGPL? It seems like AGPL creates certain restrictions on the internal order of a company which uses AGPL code for the benefit of the AGPLed code's community. And this licence is basically the same.


Because the BSL flat out bans the use of the source code for a specific purpose for 36 months and mostly behaves like Apache-2.0 for most other intents and purposes, whereas the AGPL affects all users (commercial or non) and requires them to publish source code for all publicly accessible services using the AGPL licensed code, regardless of purpose.

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").


This ignores the nuance. It is to level the playing field. Sentry would not be able to compete against Amazon hosting their service and reaping the financial benefits, and nor should they have to (and to do so with Amazon's resources available to them would be a Herculean task). If you're not a fan of the model, roll your own codebase.


> Sentry would not be able to compete against Amazon hosting their service, and nor should they have to.

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)


So you're inverting a word here, poorly. Competitive and anti-competitive are not antonyms, the latter has a more specialized meaning.

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.


> It is pretty clearly free riding to take the creative output of another company, repackage it for money and release nothing in return.

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.


Oracle has been free riding red hat with unbreakable Linux, for years. Then red hat got bought for 30 billions. When you are confident about you ability to outsmart the competition and keep your customers, you don't have to use those new semi-open licenses. They are a legal risk for anyone who copies or reuses the code.


It is anti-competitive as big players give the sw away at a loss that they make up elsewhere by the nature of being huge. I increasingly think so much so to the extent of regulation should disallow massive platform providers to be both the compute marketplace and the sw on top: they need to pick. Feels like when the EU went after MS for similar company squashing antics. Competing with free/unprofitable is anticompetitive.


Is the creative output really “from another company” if it’s licensed under permissive OSS terms?


It's only competitive if you have a fighting chance. Me (as an indie dev) competing against Sentry is different than a $900 billion company competing against Sentry. Shouldn't it be a fair fight in the marketplace? There is no fair fight to be had against Amazon.

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 think there is 24/7 user support and very different software consultant like support and AWS can't actually provide the latter even on a product they control.

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.


A project can be relicensed at any time. This is a known quantity (just as a commercial product's price or availability can change without notice). To think that because it is open source, all future versions will be open source, is naive at best. To expect contributors and project owners to not be compensated for their work (or not enact controls through licenses to protect their ability to monetize pieces of their work) to support a belief system (absolute "open source") is downright unacceptable.

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.


A product can get additional licenses and members of a community can move to a fork under the additional license.. But as far as community, it's a little like going to a party only to discover it is a church meeting. Once or twice miscommunications happen but at some point you realize this miscommunication is the model.

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.)


> a REAL open source community

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.


That's silly, I've worked in a closed source community with cross company stakeholders and we had no trouble understanding we weren't open source Scotsmen. Sentry seems to know this too, and this unnotable change is strangely notable here.

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.


If you have business policies that actively disable you from being able to compete, then in a way its "self-defeating". You could say that "self-defeating" is the same as anti-competitive, because, well, if your company doesn't exist, that's one less competitor.

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.


> 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.

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...


I don’t think you caught my claim exactly. Let’s say Sentry is being honest when they say they have to do this else they wouldn’t be able to make enough money to survive. In that case, it’s good for competition.

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.


It's anti-competitive because it allows larger companies to squeeze smaller players out of the market thereby reducing competition. This kind of anti-competitive behavior shares characteristics with predatory pricing (https://en.wikipedia.org/wiki/Predatory_pricing).

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.


While I agree with the statement, I think the tone may be a bit off-putting.

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 a wide swath (very likely the majority) of the community is totally fine with not-open licenses. It’s the default condition for new code and I personally have zero issue with 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 don't think this is accurate.

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.


> 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.


Not necessarily. There's nothing stopping an entity from suing you in 5 years for your use of Sentry in those intervening 3 years.


We're huge fans of Sentry and have it deeply integrated in our products. The fully open source nature has helped us a ton with these advanced integrations, being able to look at the code to see exactly what is happening instead of relying on docs (which are great as well, not faulting them).

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.


> It's clear we need a license that allows software to be developed in the open but prevents this type abuse.

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.


You can fork it, you can mod it. But you cannot sell forked sentry as a service to companies. If companies want sentry they can host it themselves and you can provide customization/support services for that.


> But you cannot sell forked sentry as a service to companies?

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?


Better at ops? do they have issues?

The options are: Use Sentry.io, host it yourself, or use something else.


It's possible to fork all of the repos until the first change is introduced with the new license. So, if you want to fork at any point in time, it's going to be based on the last release prior to the new license.


> 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.

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.


It wasn't Opbeat. But from that same thread, interesting to see how zeeg's views on licensing have changed:

https://news.ycombinator.com/item?id=12800893


Ripping off someone else's project and doing a 'find and replace' of the name is IMO morally fine.

If they can do a better job of marketing with that new name, they deserve the success.


Let's say 2 companies raise $10 million each. One company spends $8 million on R&D and $2 million on marketing. The other company re-uses the former company's open source work and pours all $10 million into marketing.

Who will win? Who should win?


^^ this is exactly the right way to approach this. The answer is not obvious, not to me anyway. The $10 million marketing company will crush the original company, the product will wither without technical backing and fade into obsolescence. Long term everyone loses. How can we change the rules of the game (license?) so the end users 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.


What does "win" mean here? Survives 5 years without being bankrupt/bought? Has a high valuation? Survives 20 years?

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.


Is it morally fine in every case? Or just in cases where the project was initially open source? If the latter, why, and why should anyone try to maintain an open source business if that's the case?

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.


One might say it's morally fine because it was explicitly allowed by the license.

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.


So, Sentry is no longer Open Source at all, though people might potentially be able to collaborate on three-year-old versions (or, hopefully, use whatever unified fork pops up from the last Open Source release).

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.


> Sentry is no longer Open Source at all

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.


> We're firmly committed to being good Open Source citizens.

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.


A company can be good open source citizen without open-sourcing everything.

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.


Taking an open source project and closing it is not being a "good open source citizen". It's actually the opposite of that.


Those are deceptive tactics. How can one expect to spin it and make knowledgable people swallow it?


Why should we trust you not to change that in the future?


You shouldn't. Then again, they have no obligation to give you anything in the first place. And yet, they do.

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.


Sentry also got work for free from people who assumed the open source project would stay that way. That's the thing about open source- it does have benefits, otherwise people would never choose it.

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.


> 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

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.


The vast majority of outside contributions for any project come from people who use the product already or plan to use it. They contribute value but they also derive value, so to me, that's a wash right there.


"who assumed the open source project would stay that way"

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.


> Sentry also got work for free from people who assumed the open source project would stay that way

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.


Exactly. If you want an expectation of continued openness, choose copyleft.


That's why the gpl without CLA remains the best collaborative platform. That's a lesson for me, Stallman was right, as they say.


All of those contributions are still open source. You're trying to cast them as having "closed off" the code or betrayed the contributors, but all they've really said is "from this point forward we need some basic protections from our business being ripped off".


This is such a perfect example of the vocal minority crying foul. You’re all over this thread whining that a corporation is protecting its interests from parasites because it doesn’t fit your idealistic view of open source. You don’t need to trust them not to change things in the future. If you contributed, you’re still free to use the code your modifications...for free ($).

Who is sentry hurting by making this change?


Question of trust is always hard. I believe that our heart is at the right place and I think many people interacted with us over the years probably got a pretty good picture of how we work.


That's a real polite way of saying that we can't trust you not to relicense other projects in the future.

Lets be clear here too- I'm using your product right now, and I feel that this is a huge betrayal of trust.


> That's a real polite way of saying that we can't trust you not to relicense other projects in the future.

There is no good answer to a loaded question like this. If you suspect malice I have nothing I can say to counter this.


Unless you're trying to build a competing product to Sentry, nothing's changed, from my interpretation.


There are several other use cases that will be affected:

- 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).


> 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.

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.

https://github.com/getsentry/sentry/blob/master/LICENSE#L12


Good points but I would say, just like legal teams have become more familiar such open source licenses and their nuances, they’ll eventually come around on this too and be able to better articulate the differences.


Only your first paragraph is a potential concern. The rest are fine according to the license.


The difference between theory and practice is that in theory, there is no difference.


Other comments are interpreting the license as allowing money to be made so long as the service you’re providing is not hosting error logging. You’re right, the license isn’t as good as it was before, but it’s also not as bad as some are saying.


Why are you entitled to all future releases of Sentry under the same license terms?


your front page marketing still says "Sentry provides open-source and hosted error monitoring"

https://sentry.io/welcome/


pipelining problem - we're definitely going to fix and clarify things so we're not confusing any of our customers


> We're firmly committed to being good Open Source citizens.

There are words, and there are actions.

The actions indicated by that blog post aren't those of "good Open Source citizens".


I somewhat suspect companies that apply "creative" licenses like this haven't been under a corporate legal department before.

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.


> 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.


If you're that paranoid for your software, you can vendor the source, sign the tag with publicly-verifiable GPG key, and include some cryptographic timestamp in the description (e.g., hash of the current Bitcoin block or something)

Also, print all of that, get the legal to seal the pages, and put them into a safe.


> 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.

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.


> 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.

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.


Are you really sure that your big-company legal team won't want to review this odd situation?


No, but I'm sure they won't have to look at git logs to date the software.


>convincing them Github is a reputable party

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.


While they don't appear super frequent, they cut releases: https://github.com/getsentry/sentry/tags

Pick one which was cut at a particular point in time and you're done. Doesn't seem that complicated.


It seems the restriction is on offering a competing product with Sentry's codebase. This seems fine. I'll still submit bug reports or even contribute fixes here. My current employer isn't a cloud provider or an exception handling as a service company, but we still might want to run Sentry in-house. Previously, we might have contributed fixes/features in the interest of spreading our own maintenance burden. This still seems possible and I don't see a reason to not contribute back for my use case.


I'm fine with it and I think it will actually yield MORE open source code, not less.

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.


Open source ideology is stuck in the 90s when the primary goal was to displace closed source lock-in platforms like Windows, and that ideology has become an unquestionable dogma.

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.


Wishing you guys well.

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.


This is the old Aladdin Ghostscript model, where the software is proprietary for one year after release and is then reverts to GPL. I think Ghostscript ditched this scheme 10-15 years ago.

https://books.google.com/books?id=xBANKuFJWtUC&pg=PA306&lpg=...


Why not GPLv3+? Under that license, it's possible for someone to offer a commercial fork, but it requires that the source is released under the same license, which makes third-party commercial forks 1) not a good business plan and 2) not contain code that the original author can't merge to the original branch, which are both aspects desired by the author. The GPL is a free/open-source license as defined by FSF/OSI. If additional permissions are needed, they can be added as allowed by section 7 of the GPLv3. In my opinion, the GPL fosters the best free software community because contributers can be certain that their code is not used in "anti-free-software" ways.

EDIT: s/GPL/AGPL


But it doesn't necessarily have to be a fork. It can be the raw unadulterated software that Amazon wraps a service layer around and then who would trust the a small player against one of the largest companies in the world?

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.


GPL is only concerned about redistribution of your program. A modified version can be kept private as long as it's hosted on your own servers and not distributed. The primary concern of Sentry is large cloud providers that have more capital and better economies of scale providing their hosted service for a cheaper price.


I see. Would AGPL fully solve this problem?


Not fully but 99%. Most "SaaS" companies would avoid running it or pay a license for a special approval.


What's the 1%? Of course, paying a license would be a desirable negotation between the author and SaaS company, so this isn't an "issue".


The way I see it, the BSL is similar to the AGPL but weaker.

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.


You probably meant the GNU Affero General Public License in this case cuz the software in question runs on a server on the network


Amazon, Azure and GCP could burry Sentry as a company with that option. It's actually happened a few times at this point.


Can you give an example? Is what you're referring to what the AGPL is designed to fix?


If AWS decides to "adopt" your platform, and autoscale it, and undercut your sustainable pricing model because they have economy of scale, does it even matter that the source is available?

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).


But Redis was always BSD licensed. Every release of Redis was released with the full knowledge that anyone could do anything they wanted to with Redis, as long as they provided attribution and didn't claim a warranty.

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.


Ok then, the extra modules that Redis Labs maintains, which used to be licensed under a modified Apache2 licence, and are now under a "source available" license because it causes less confusion about if it's actually OSI sanctioned or not.

https://redislabs.com/legal/licenses/


This is one of the things I appreciate with Azure's Marketplace, at least it's easier to list/find services on Azure with pricing baked in...


“Previous licensing models – the “open core” model, GPL, and permissive licenses like BSD and Apache-2.0 – are not sufficient for the way OSS is distributed and used today.”

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.


> Protection from other companies selling our work

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.


> But if we move to an “open core” model that better protects our IP, in our eyes, that means we’re no longer an open-source company.

"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.


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.

Yes, they don't call it that. Seems like the actual open source advocates will hector them before they even start.


Wrong. They call it an "OSS" 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.


Probably because the source is still open. This whole discussion strongly reminds me that open-source and free software are not the same.


This sort of confusion is exactly why this battle is worth fighting.

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.


This now has been rectified. Apologies for the misrepresentation, wasn't intentional.


> 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 very clear in stating that the license is not open source.


> This license is NOT open source. Don't call it that.

The blog post says this: "due to the grant restriction, it is formally not an open-source license."


"formally". They're using weasel words to pretend it's still 'open-source', but that they just can't technically call it that. And later-on in the article they say this:

> 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?


I don't think it's weasel words. They're just acknowledging that the OSI doesn't recognize the BSL as an Open-Source license, but the source is still open in the literal sense. Not only that, but most of the things associated with code being open source are still true: 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.


I would argue it's weasel words because they're implying it's "really" an open-source license and OSI is wrong. And later on they directly call it an OSS license, directly in conflict with a few paragraphs ago when they say it's "formally" not an open-source license.

> 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".


It's definitely weasel words. Open Source has a definition. The source may be publicly viewable, but that isn't "open". It's still closed, and it being viewable is actively harmful, as it'll lead to copyright violations sneaking into other projects.


Yea I understand that there's a technical definition that it falls short of, but again they're very explicitly noting that it falls short of that, so I don't see how it's being ambiguous or misleading. And I don't buy that it's not "open" - it's out there in the public; it's open for contribution from the public; it's open to be modified and deployed except if you're a monitoring provider. The OSI doesn't have a monopoly on the definition of the word "open".

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.


I think this is great; if I ever start a SaaS business I'll happily follow Sentry's example and use the BSL if I want to develop in the open.

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?


I have run the self-hosted version of Sentry for a couple years at my job now and it has worked fantastically, and I also use the SaaS product during freelance. The self-hosted releases take time to appear after launching on SaaS, but this is understandable as it takes time to coordinate things making it downstream to the public repo from internal stuff. And the self-hosted version is rock-solid once running, I never worry about it.

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.


I'm really confused at the vitriol in the comments, does this license not become a true OSS license after the change period? IANAL but that seems to be the case to me. It's so confusing what part of this is frustrating? I think keeping a 36 month buffer of features to maintain an a commercially viable edge to fund work on a project is extremely reasonable. It seems like a really good and virtuous model.

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.


It’s a “vocal minority”. Seriously, it’s just a handful of people replying to every single comment. Sentry is being perfectly reasonable here.


This seems fairly reasonable. It’s understandable that you don’t want others to offer commercial offerings of Sentry.

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 BSL is a "have your cake and eat it too" license. It allows a company to accept contributions from third parties, without those third parties being able to use the changes commercially. It's immoral.

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.


I respectfully disagree with the suggestion that this is immoral.

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.


> People using the software for free may still decide to contribute code. This is not a one-sided relationship here.

If the contributor is not allowed to do something with their work that the receiver is allowed to, is that not one-sided?


One-sided would imply that only one party benefits. You clearly benefit from being able to use and improve software, for free, for practically any purpose.


> You clearly benefit from ...

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.


Alternatively, third parties can volunteer their time to AWS by contributing to open source software!


I don't understand the practical difference of your suggestion.


If they close off the source, they can't accept contributions from 3rd parties.

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.


It also allows users to modify the source and run it on their own systems.

You're suggesting a strictly worse outcome for the majority of people (users, and sentry) in the name of purity.


Armin Ronacher's blog post concerning this topic: http://lucumr.pocoo.org/2019/11/4/open-source-and-saas/


I find the distinction between libraries and applications to be rather self serving. It's basically saying "I want to use these open source libraries to bootstrap my business, but I don't believe others should be able to use my code in an open source way because apps should have profit".

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 find the distinction between libraries and applications to be rather self serving. It's basically saying "I want to use these open source libraries to bootstrap my business, but I don't believe others should be able to use my code in an open source way because apps should have profit".

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.


I see it as the same as the art school graduates who really, really want to make a living out of making art and finding in the real world a really, really small minority of artists can live off the art they produce.

Then they get a job teaching art to the next generation of people who really, really want to live off of making art.


I wouldn't use the term self serving. Armin has made massive contributions with open source libraries (Flask, Jinja2, Click, etc).

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.


> I find the distinction between libraries and applications to be rather self serving

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.


> 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 it's interesting that one of the reasons Sentry gives for re-licensing their code (most/all of the major contributors work for Sentry) is also one of the reasons they gave 3 years ago on this site when asked why copycat services did not concern them: https://news.ycombinator.com/item?id=12800539


Seems a fair compromise.

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.


Elasticsearch and MongoDB has really started an interesting debate on Open Source Licensing..More Power to Opensource Software Providers that need to reap the benefits of their work.


They haven't started a debate. The debate of "should we be open or not" has been going on for as long as Open Source has existed. And we've had licenses that attempt to sound open without being open for a long time as well, under names like "shared source".


On the whole, while sad that it happened (it feels like a loss somehow), I think this is probably one of the better licenses they could have gone with.

As far as I understand there’s still nothing preventing me from forking their code, just from selling it for 3 years.


I don't blame Sentry. FOSS is a fine ideal for hobby and academic projects, but it doesn't pay the bills. 36 years on and the most successful business model for FOSS is to convince someone rich to lose money on it. (Cf. Gilmore at Cygnus, Shuttleworth at Canonical.)

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.


That's the only business model as long as you ignore Automattic, Chef, CloudBees, Cloudera, Confluent, Databricks, DataStax, Gradle, Hashicorp, nginx, Puppet, RedHat, and many others.


Some of those companies make money by selling proprietary software. They are thus proprietary software companies, and bad examples of open source software business models.


What are good examples?


Red Hat. They work with the community upstream, and they open source all their stuff.


I expect to see a lot more of this with GitHub Sponsors coming online. As it is now you can take any BSD, MIT, ISC, GPL open source project and start collecting money from it, not using it in another project, just by asking for money period. The licenses above all allow this. It's only going to take a few bad actors for the actual devs to start wanting a new license that somehow keeps the project open source but only let's them collect the donations. I have no idea how that will work but it seems a likely outcome.

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.


the issue with all these (mongodb, elasticsearch, sentry, redis, etc...) is that software doesn't work with zero marginal costs, software's creation and distribution costs are different, the same goes to anything digital.

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.


A little off topic from the actual post, but I wish that there was an actual service or program that was a "re-licensing sentry". That is, given some list of open source projects, it would email me if any of the projects changed their license.

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.


This is a very disappointing development. I was hoping to implement Sentry for a side project I have been working on, now I will have to find an alternative or use an old version, as I refuse to rely on closed-source software.


You wanted to run a sentry as a service side project?


I have two main side projects I am working on right now- one would be a SaaS product in which I would just be using Sentry as a tool- that would still be allowed under the BSL- however, I am leary of using non-open source code like the BSL because the BSL does not grant the community the freedom to fork it and use that fork as an open source project (Any fork of Sentry going forward would either need to start from old code or be under the BSL license and the new community would be at a disadvantage as no one could use the new product to offer an APM service. This removes the primary motivation for the maintainer (in this case Sentry the company) to remain benevolent.

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!


In this case you could request an additional use grant from us (Sentry). It doesn’t mean it’s not possible, it just means you’d need permission.


Nothing about this announcement makes it closed-source software.


Huh? Did you read the announcement? They clearly state that it is no longer under an open source license.


It not being recognized as an official OSI license does not make it "closed source", their source code is still fully and freely available to customers who can continue to using and customizing their own modified versions as they see fit. None of which they could do if it was "closed source".

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.


It is not fitting the requirement widely agreed for defining software Open Source: it creates a restriction on usage.


Which is both clearly spelled out in the article and irrelevant to my original comment where "Nothing about this announcement makes it closed-source software."

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".


It is no longer an open source license, and is now a "source available" available license.


Its interesting to see them reason that the BSL is more open source than open core. Do others think that? It is certainly more free as in beer for most users.


One ideal is the open development model, where anyone can come along and submit patches, where multiple companies can conspire to create a project, and so on. Open core, where you have a central project that is open source, then a number of plugins that are less open source, is the better model towards this goal. The worry is that members of the community will begin recreating features that have already been added to the paid version, and releasing them as open source. Under the BSL, you have a tension here because the paid version will become part of the free version in a few years. Under open core, you'd ask the community members to release the feature as a plugin, and the two separate plugins can coexist.

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.


Having a sustainable funding model for open source isn’t necessarily a bad thing IMHO. The potential upside here is that Sentry will be able to invest more into large improvements to the code knowing that their funding is sustainable. This is to the benefit of everyone who wants to use this software in the purest sense of open source, which is running the code on your own systems.


This isn't a sustainable open source model though as the code is not open source.


As they state in their article it's eventually OSS (after 3yrs it converts to OSS) and you're basically unaffected you're reselling a competing hosted version, you still have full access to the source code and can continue to run your own/modified version in house.

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.


BSL seems pretty decent... it becomes open in a simple, easy-to-understand way.

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.


> Previous licensing models – the “open core” model, GPL, and permissive licenses like BSD and Apache-2.0 – are not sufficient for the way OSS is distributed and used 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."


people's labor should be well compensated. this is a good move from Sentry, Mongodb and others that will follow. yeah, you've people with freeware or fsf idealism i.e Stallman ideas.That Sentry and the others betrayed their ideas. But simply, FU - let them get paid. Sentry is an amazing product. & the people who work on it should be able to put food on the table & sleep well, without worrying about Amazon n parasites. I think the greatest misconception is between open source and open core. & we should start labeling a bunch of software on Github as such. Now the parasitic cloud providers such as AWS won't profit via someone's work. when they hardly contribute to open core | source


Sentry, mongodb, et al. all got as big as they did by promising to be open source. Do you think they'd be where they are today had they not been open sourced? I personally do not.


> Sentry, mongodb, et al. all got as big as they did by promising to be open source.

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?


We recently adopted the BSL too. Here's a blog post that goes into detail about our rationale.

https://www.zerotier.com/on-the-gpl-to-bsl-transition/


That post states that GPL or AGPL would be adequate for your protection needs but you opted for BSL instead due to “GPL-phobia”. So why not dual license under BSL and (A)GPL? That way open source purists (including me) would have a license they considered acceptable, without it compromising your goals.


It's an interesting idea. The BSL seems like a safer choice given the wording straight-up blocks SaaS's. They're the real threat to ZeroTier.

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.


This was a great read!


When will there be a 10.0 Open Source Release? It's harder for me to support this when I saw open source pull requests denied that in hindsight would have let more users run their own hosted sentry with features such as OpenID Support.


I can't help but feel that if companies like Amazon, Google etc had been fairer in their dealings with open source projects (by either contributing more code or by paying the authors) that we wouldn't be in this situation.


What does this mean for people who have already contributed? Do you have to get permission of everyone who made a PR merged? Did they have some sort of CLA that allows them to re-license? Just curious how this works.


It doesn't appear they have a CLA. The old license was BSD 3-clause, which states: > 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. > 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

And nowhere is that list to be found. So it appears Sentry is violating the license for external contributions.


content of the blog post aside, this is just completely obnoxious and distracting: https://gfycat.com/sphericalfrailalligatorgar


Yes, but at least you can submit a PR to fix it.


You say that like it's a good thing, rather than being a way for corporations to extract value from free labor to line their own pockets.


Have you considered that SaaS is just a terrible business model?


Tell that to Amazon, who seem to be making it into an extremely successful business model.


> Minimal limitations on usage of code; as free as possible

Wait what?


Seems reasonable.

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).


Yet another company that uses the open source community to grow and then rips the rug out from under them.

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 "Business Source License" is not an open source license, and lying to the community about it is nothing short of gaslighting.

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.


I feel like they're being very honest. If you (or anyone else) feels strongly, you can always fork the code now and develop it. You and I have no right to the _future code_ that Sentry might write and license under different terms.


This is equivalent to Oracle (possibly the worst bad actor in open source history) killing OpenSolaris.

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.


How do you propose stopping AWS taking the code wholesale and selling with an upcharge? Is that what open source is?


AWS is emphatically NOT "taking the code", they have a license for it. If you don't want people to use your work commercially, then don't license it to them to use it commercially. It's pretty simple. Once you tell people what they can and can't use your software for, then it is no longer free; you don't get both.


But that's exactly what they're doing.

They're saying you can use it for anything except building a competing product.


>then it is no longer free; you don't get both.

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.


Well yes but open source has well established definition.

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.


I would have no problem with AWS were their shit open source. Starting from all the ugly Perl, that holds whatever obscure nefarious systems in perpetual black magic motion.

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.)


For what it's worth, here is an Amazon contribution to Sentry.... https://github.com/getsentry/sentry/pull/4231

Many developers at Amazon love(d) using Sentry, and one wanted to contribute (in a small way).


Creating open source software is a choice. No one is required to do it. That choice has both benefits and potential negative consequences if your goal is to commercialize.

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.


Exactly, and they made the choice to no longer do it. Feel free to fork it and maintain their effort.


Which if fine. They're allowed to do it. The community of people who use and contribute to the project also get to be mad about it.

Look, if Sentry wants to make money selling their software they should have just been proprietary from the beginning.


> how we can stop AWS from reselling open source software

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.


To be fair, hosting a managed service of something, whether the software is open source or not, is a complicated and difficult task. So, AWS charging for a hosted version of something is not an "upcharge" but a payment for actual services rendered.


I don’t propose we do that. Open means open.

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.


>I don’t propose we do that. Open means open.

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?


Not all use of code is just running it as is. Sometimes you want to take a pice of it and use just that in your system. Maybe you want to fork it and do your own thing with it. You can do that and all the other things you can think of with open source, not with BSL (or you would need army of lawyers).

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.


I don't see how you need an army of lawyers to fork or modify sentry code as long as you don't run a service that is competition to sentry.io.

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.


So if I take few hundred lines of their code, and put them in my product.

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.


As they pretty clearly articulated in the article, they want their code to be open to the extent to allow people to host it themselves and make changes to it as they need, but not so open that they can sell it and make money from it.

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"


If they started that way, it would be totally fair. Given that they didn’t, it’s somewhat off putting but still within their rights.

I do disagree with the use of “technically” in the last line. It’s simply “not open source” (which is, of course, fine).


> If you don’t want open, don’t make your code open.

There are more things than the extremes.


This is pretty extreme though- three years is a lifetime in the software world, and the original codebase being open source means you likely accepted a lot of code from people who thought they were contributing to an open source project.


All of the code you contributed before this change remains open source. You’re free to fork the project.


Yes it actually does mean that is what open source is.


> How do you propose stopping AWS taking the code wholesale and selling with an upcharge?

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.


Can you cite any AWS products that do that? Providing a paid, hosted version of an open source product isn't selling software, it's selling hosting.


Maybe we need a new license that is similar to existing open source licenses with the addition that it can't be used by FAANG.


Nothing is broken, nothing to fix.


It seems to be either that or have amazon rip the rug out from under them AND the open source community at once.


If you're right, why doesn't the community fork it?

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.


This comment breaks the HN guidelines by name-calling and failing to assume good faith. I'm sure you can make your substantive points without doing either of those things. Please do.

https://news.ycombinator.com/newsguidelines.html


Exactly. Those developers they paid millions of dollars could have been paid similar amounts by other companies, and may have cared that they were contributing to a bona fide open source project.


Could you elaborate on how the BSL is "bad for the community"?


It does not offer essential freedoms as defined in the Open Source Definition. This includes the ability to fork the software, make alterations, and sell use the result however one wants to (within the rights of the open source license), including selling it or creating a commercial service based on it. This license restricts the ability of the community to collaborate on the software by placing the community at a lower status than a single commercial sponsor.


You are confusing free software and open source.

Free software is the one about freedom.


You are confusing "source-available" software with "open source" software. Open source software is defined by the definition given here: https://opensource.org/osd

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...


I'm not confusing anything:

https://opensource.org/osd


Agency creating systems for clients, contributes to sentry - bug reports/prs etc, can they use it now? Can they deploy system for their client integrated with self-hosted sentry?


To be fair, the open source community "used" them as well.

No shame in one party deciding to just walk away.


[flagged]


"Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith."

https://news.ycombinator.com/newsguidelines.html

We detached this subthread from https://news.ycombinator.com/item?id=21467673.


Sure, but those are only weasel words and blatant lies. Talking about "Commercializing Open-Source", when you are in fact closing your source code is dishonest. And I think HN needs honesty. Even with some bluntness.


That's how we get flamewars. What feels like honest bluntness on the inside seems like trollish flames on the outside—not to everyone, of course, but reliably to someone, who then feels justified not only in reacting but escalating.

The only way out of this, if you want to have an internet forum that doesn't burn (which we do!) is for everyone to practice making their points in a more thoughtful way. Maybe you don't owe that to the closers-of-source-code; but you owe it to the community if commenting here.

https://news.ycombinator.com/newsguidelines.html


> Maybe you don't owe that to the closers-of-source-code

You assume I have something against closers of source code. Do not assume bad faith please.

I don't like closers of source code who say "Yes, We're Open (source)". https://sentry.io/_/open-source/ or https://sentry.io/welcome/ "Sentry provides open-source and hosted error monitoring".

This is not honest. I think honesty when selling software is important.

I'll take note for the future and will try to present the facts in a more politically correct way. This is an american forum afterall.


I am the VC. I was not really consulted on the change, and after seeing it on HN, texted the founder saying I disagreed :) That said, I'm supportive of the team making the decisions they do! They run the company, not me!


> ... texted the founder saying I disagreed :)

Which direction did you want it to go? Full BSD from day one or locked down closed source?


My gut reaction was to keep things open source


That's not clear at all. It's not hostile to tinkerers. It's hostile to entities that may want to take others open source work and provide a business around that work.

You can still run the software, for free, in your business. You can still change the software, for free, and run that in your business. You can still fork the software, from today, and do what you want with it.

The vast majority of work done on the software is funded by sentry. This hurts literally no one who is legitimate.


It should be noted that this change also means one can't use parts of the code in their FOSS projects, especially if the rest of the codebase in copyleft. I'm not sure anyone was using parts of the Sentry codebase that way, though.

(I guess people can use the code after it converts to BSD, but that's a dangerous gambit, because if a bug - particularly a security bug - is found, you have to wait three years for the patch)

By the way, I have no ill will towards Sentry, though I can't deny it's a loss.


fwiw we basically employ everyone (either full time or as a contractor) that contributes to Sentry, and if we don't, shoot me an email and maybe we can fix that!


It is entirely legitimate to take f/oss software and offer a hosted service of it, directly competing with those who paid money to produce the software, and potentially harming their services business. If “we literally wrote it” isn’t enough to retain your services customers, maybe you shouldn’t have them.


Sure, it's totally legitimate under an f/oss license. Which is why many companies that are spending millions of their own money developing these systems are moving to different models where it's no longer legitimate.

If the puritans aren't willing to accept that, that's their right, and they can take their money elsewhere.

There's a tragedy of the commons element to it all. Company A invests millions of dollars developing a product out in the open for the benefit of themselves AND their users. Users are free to self host for literally $0. Then company B comes along and repackages the solution, usually behind closed doors, and reaps the $millions of benefit with only the marginal costs of operating the product.

The whole argument is very strange to me. Users - end users - have all the freedom in the world. It's only really multi billion dollar companies that are exploiting the work of others for their own personal gain that are being shut out - but the puritans seem ready to defend them anyway. In a world where Amazon (for example) control everything, users have far less freedom.


> Then company B comes along and repackages the solution, usually behind closed doors, and reaps the $millions of benefit with only the marginal costs of operating the product.

Well, they can only reap what company A fails to reap; either by having lower prices, or a better service offering, or being better or more useful in some way, right? I mean, if company A is literally the same name as the software, they have a natural marketing advantage, so company B would have to be better on some axis to eat even part of their lunch.


> Well, they can only reap what company A fails to reap; either by having lower prices

That's basically my entire point. Of course company B gets to have lower prices, since they're not spending money on building the product.


Writing free software does not give one a monopoly on offering a service based on that software, naturally. That's the entire point of free software.

If company A's entire business plan is based around the fact that it's impolite to do that after company A spent that money up front, they're going to have a bad time. That model is dumb to undertake if your lunch can be eaten if someone comes along and differentiates only on price of service.


> You can still run the software, for free, in your business. You can still change the software, for free, and run that in your business. You can still fork the software, from today, and do what you want with it.

You cannot reuse and publish. Matter of fact, even reading it and taking inspiration from it is risky. Words from an IP lawyer I know. It's a proprietary license. There is no shame in that. So don't try to act like you are still an open source company. One has to make a good living. That's not what I was criticizing.

> It's hostile to entities that may want to take others open source work and provide a business around that work.

Consider yourself happy Torvalds didn't think this way. Or Guido. What's your dev environment?


> Consider yourself happy Torvalds didn't think this way. Or Guido.

By all means, fork the software and start providing a business around it then. What you don't get to do, anymore, is provide a business around the output of others moving forward.

A truly open source clone may spring up out of this. I strongly suspect it won't, because there are very few people contributing to this project who aren't employees. The ones that aren't employees are making changes to support the instance they use to support their real business. I personally fall into this bucket. I raise issues, participate in betas, and try to fix bugs where possible precisely because I use the software. I have no intention of packaging it up and selling it elsewhere.


The idea behind community-based development is that anyone can provide a business around the output of others, and it's not a problem because all improvements are shared by everyone.

All the license change says to me is that the development team was very insular and ended up all at the same company, so they ultimately saw no benefit to participate in the wider community. Closing themselves off further is a natural progression from this. That's fine for them, and I'm not going to dig into the deeper reasons why it happened, but for this reason it's a big red flag to me when a FOSS project fails to attract contributors from more than one company.


> The idea behind community-based development is that anyone can provide a business around the output of others

I disagree with this statement. Being able to build a business around the output of others is a side effect, and not the primary reason for open source. I would argue, and many companies are arguing, that the side effect causes more harm than good, and there should be some kind of optional middle ground.

> the development team was very insular and ended up all at the same company

Look, I have no statistics around contributors that are employees vs contributors from other companies. Zeeg may have an idea. But as he said up-thread, they tend to hire those that contribute.

Operating Sentry at scale is no small feat, and I'm not surprised that most companies prefer to spend the money on the SAAS solution rather than on employees to operate it.

> so they ultimately saw no benefit to participate in the wider community

This is the bit I most disagree with. They are still participating in the wider community in the vast majority of cases. There is a single restriction - you may not take the output and duplicate their business.


>I would argue, and many companies are arguing, that the side effect causes more harm than good

I would not. Community development means just that: community development. Everyone contributes to a shared set of code that everyone gets an equal chance to profit from. If you know something the others don't then you can charge them to go do consulting/support/training/etc, but you can't stop them from building a separate business around that code and you can't sabotage the code or the license to go and try to steal their customers. That's part of the deal and no one gets to have their cake and eat it too, not even Amazon or whoever the villain of the day is. There is a middle ground away from this, which is to make parts of your product not open source anymore, which is what Sentry did.

>they tend to hire those that contribute.

That's not a problem in and of itself. It's when they're the only ones doing the hiring. That to me means a product-market mismatch where there are not enough companies to create a competitive ecosystem of other things around the open source project.

>you may not take the output and duplicate their business.

For me as an outsider of this company, this is a negative. I want their business to be easily duplicated. It means they have to work harder and make better products.


There are other products in the same domain. That’s where the competition should be. Not ripping off work.


Reading any software and taking inspiration from it is risky, because software patents inhibit the Progress of Science and useful Arts.

Here's cockroachdb's version of the BSL:

https://github.com/cockroachdb/cockroach/blob/master/license...

You may be right that this doesn't allow modification. I hope sentry words their Additional License Grant better.

> Consider yourself happy Torvalds didn't think this way. Or Guido.

Yes I'm generally happy when I get new stuff for free, but I don't expect that to always happen.


> Yes I'm generally happy when I get new stuff for free, but I don't expect that to always happen.

Sure. But when a product is advertised as open source, I expect it to be true.


Open source never includes the guarantee that there will be future open source releases. If their new license won't work for you, it's as if it just stopped being maintained. Use and/or fork the most recent open source version.


A paragraph of this announcement is literally titled "Commercializing Open-Source". This is a blatant lie.


I think a lot of this revolves around what you think a "tinkerer" should be able to do. You clearly state "learn and reuse parts of your code", but depending on what you mean, people may or may not think "reuse parts of your code" falls under "tinkering".

I imagine people might be split on that point, but I think "reuse and publish" is asking for much more. That's not tinkering, that's making a business, or at a minimum providing a service (even if uncharged and the service is software access).


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: