Hacker News Reader

Comment by jorams | Hacker News Reader

I might be missing something here, but this doesn't seem compatible with the bazaar model at all. You say

> It also enables contributions by the community for the latest version and not old source code.

But you will not be able to accept such contributions without an additional license, because you yourself would be unable to use them for a Competing Use (running your service). This makes it much closer to a cathedral, with a "small bands of mages working in splendid isolation". Sure, your work will be publicly visible, but that's it.

View on HN

That's their goal. The head of sentry's open source policy has openly stated that he, and sentry as a whole, want to change the definition of open source so that it has additional limits that make it easier to profit off of and control.

This conversation from three months ago is really enlightening: https://news.ycombinator.com/item?id=36972824

When the head of open source was explicitly asked about whether they're trying to redefine open source his response made it very clear that they are-

> > your end goal is to exclude commercial reuse from the open source definition

> This is fairly accurate, though there are a range of possible outcomes we would be satisfied with.

Anything they say should be considered with that in mind. These are not good actors in the industry, but are people who are trying to replace open source software with a shared source version. Unlike other companies, such as Hashicorp, who admit that their software is no longer open source Sentry wants to have their cake and eat it too.

> but are people who are trying to replace open source software with a shared source version

Note that the thread you link to is a situation where they took an entirely closed source product, CodeCov, and made it source available under BUSL (and now FSL).

> Unlike other companies, such as Hashicorp, who admit that their software is no longer open source Sentry wants to have their cake and eat it too.

From the parent article (FSL: A License for the Bazaar, Not the Cathedral):

> But one thing is clear: until its expiration, the license does not qualify as Open Source. While I recognize the sensitivity around the term “Open Source”, I assert that the FSL's approach is more closely aligned with Open Source ideals than mere source availability. I consider it an “Eventually Open Source” license, though perhaps a more fitting term needs to be found.

That's some real deflection. While the overall thread was certainly about CodeCov, the questions I asked your head of open source where very clear and not tied to that specific case, and their responses were as well.

I do admit it's nice hearing that the Director of Engineering at Sentry has a higher standard for what is or isn't open source software, and I hope that attitude spreads to the rest of the company. I still think that everything that Sentry does in and around the Open Source community should be seen through the lens of what the Sentry Head of Open Source has directly said, and through the actions and statements of Sentry outside of that.

I don’t feel it’s deflection because Armin is the creator of Flask, a founding engineer, and our Principal Architect. He additionally is a member Sentry’s senior engineering/product leadership, and a key contributor to our licensing efforts. It’s his blog and his personal comments, and we are not a monolith, but I feel his statements are a good reflection of our values. Mine at least. (Disclosure: I’m also a part of this group.)

The Head of Open Source has followed up on the Codecov conversation and expanded on those comments [1]. I earnestly hope you’ll weigh these official comms higher than an HN comment.

[1] https://blog.sentry.io/sentrys-open-source-values/

Even in that blog post, where you get so close, you do this-

> We want to be able to continue to develop Sentry and Codecov as single source Open Source projects

You're stilling calling it "Open Source", but are calling it "Single Source Open Source" as if that's some distinguisher. You're even lower casing the "single source" part to try to emphasis the Open Source part of it.

Your team spends paragraphs admitting it's not open source, all to just continue using open source to describe your projects. It does so in "official comms". You guys should just come up with a better name for this already and stop trying to claim software that isn't open source is open source.

Feedback accepted. We’re still sharpening our language, and the FSL is the best articulation of what we want to do today.

> But you will not be able to accept such contributions without an additional license

Without going into us, many open source projects do that. If you submit code to the Python Software Foundation you also give it under an additional license than what ends up on people's computers. That's a pretty common situation in plenty of Open Source projects already, particularly if they want to remove license restrictions in the future.

For us in particular we also specifically do not pick the FSL in situations where we believe the utility is so great, that we want to enable further collaboration. All our SDKs for instance are BSD/MIT/Apache2 licensed (depending on the SDK). Our most precious internal library for symbolication including the service are not FSL licensed, despite the fact that I know some of our competition uses it and don't give back. Because we believe that collaboration here is for the benefit of everybody.

> This makes it much closer to a cathedral, with a "small bands of mages working in splendid isolation".

We are not mages in isolation, we build in the open. Every commit is deployable, every commit is runnable.

There could be a contributor licensing agreement in place that effectively transfers copyright. But yeah, this is a potentially sticky point. It's inherent to the license that one party is special

Reply on news.ycombinator.com