Live data from Hacker News

FSL: A License for the Bazaar, Not the Cathedral

lucumr.pocoo.org

141–150 of 201 posts

Re: FSL: A License for the Bazaar, Not the Cathedral

#141
post #136

Earlier quoted context omitted.

We welcome you to spend 15 years and 10s of millions of your own money to compete with us, by writing your own software. If you think taking someone else’s software and spending ad money to sell it is “competition” I don’t know what to tell you.

Did you even read what I wrote? I said that I don't think they need to give people access to their software. That it might even be unfair to expect them to do so. But if they don't do it, they can't call themselves FOSS. It would be unfair to expect a restaurant to sell everything at a 50% discount, but if they said they were doing that and it turned out they weren't, I'd have every right to complain.

Where do we (Sentry) ever call ourselves FOSS?

If FOSS is represented by the community in this thread I want no part of that toxicity.

We do what we think is good and for developers and customers, and the broader open source ecosystem. A lot of us have been doing that for quite some time and will continue to do so.

Re: FSL: A License for the Bazaar, Not the Cathedral

#142
post #112
post #101

Earlier quoted context omitted.

This. I'm not sure why it's so difficult for people to grasp that open source in of itself is not a business model. It can make money sure, but for the most part that's neither guaranteed or likely. If anyone can take your code and resell it as a competitor or use it for free, then by definition you're not going to be able to monetise the way traditional software businesses can. All the attempts to block large corpor…

The idea of the source being available but software not being “free” is fine by me. I want the source so I can fix bugs instantly instead of trying to convince some mid-tier product manager having gone through 5 tiers of support. That is a huge benefit over source-unavailable proprietary software, or (heaven help us) SAAS.

And there's nothing wrong with that, it's just not open source. It's source visible/available software, which has been a thing for ages. Old school forum scripts like vBulletin, Invision Power Board, XenForo and WoltLab run on this very model. As does about 90% of proprietary CMS software in general.

The problem is that a lot of companies seem to want to have their cake and eat it; they want the public contributions and kudos from making open source software, while treating it like proprietary software where the source is (maybe) available to end users.

Re: FSL: A License for the Bazaar, Not the Cathedral

#143
post #58

Earlier quoted context omitted.

> Anyone trying to develop open source with this will be stuck two years behind the official release and so it won't be worth trying. Only if you're a direct SaaS competitor. In that case, you'll have to diverge based on two year old code, which seems fair to me. (And you're always free to start your own project, if you want to compete...) > I don't get how it solves that freeloader problem either. Because freeloadin…

> Because freeloading competitors are stuck with two year old code, putting them at a disadvantage, or compelling then to invest in that old code (some of which might find its way into the original branch). This makes no sense though. If you don't want competition, why give your source away? If you do want competition, why put it at a disadvantage? That's why I am so negative about this license. It's just someone try…

> If you don't want competition, why give your source away?

Of course they don't want competition, but what they do want is customers like me, who will never voluntarily choose to become fully dependent on a single third party for anything remotely important.

Re: FSL: A License for the Bazaar, Not the Cathedral

#144
post #141

Earlier quoted context omitted.

Did you even read what I wrote? I said that I don't think they need to give people access to their software. That it might even be unfair to expect them to do so. But if they don't do it, they can't call themselves FOSS. It would be unfair to expect a restaurant to sell everything at a 50% discount, but if they said they were doing that and it turned out they weren't, I'd have every right to complain.

Where do we (Sentry) ever call ourselves FOSS? If FOSS is represented by the community in this thread I want no part of that toxicity. We do what we think is good and for developers and customers, and the broader open source ecosystem. A lot of us have been doing that for quite some time and will continue to do so.

EDIT: actually, you couldn't be more blatently lying about this.

https://open.sentry.io/

> We're Open Source

The title of the page. You really thought you could sneak that past me. You cannot seriously make a reply like this when you have an entire domain name dedicated to the tile "We're Open Source". That is the most obvious of obvious lies. Even the page title "yes, we're open source" is a kind of passive-aggressive jab at people who think you aren't.

Stop pretending to be open source and stop calling the open source community toxic.

------- End Edit -------

https://lucumr.pocoo.org/2023/11/19/cathedral-and-bazaaar-li...

> I assert that the FSL's approach is more closely aligned with Open Source ideals than mere source availability.

https://blog.sentry.io/introducing-the-functional-source-lic...

> We think it is a compelling option for Open Source-minded SaaS companies such as ourselves who wish to grant freedom

> for Open Source-minded SaaS companies such as ours, we think it’s a strong option.

This entire article is full of vague legal-speak designed to associate yourselves with FOSS as much as possible without actually saying you are. I can't see why you would do this unless your intention is to mislead or you have been mislead yourselves. You spend so much time talking about user-freedom, which has nothing to do with this license as it promotes developer sustainability over user freedom (even more-so than a simple non-compete license).

Like it or not, this is misleading. You should clarify your language on the matter. You aren't open source, and you've admitted as much yourself. You aren't "open-source minded" either (whatever that means). You said in the article that you should find a name for what you are doing, well, one already exists. It's called "source available". Open source software exists for anyone to use and profit from as they wish. You make the source of your code available because you think it will make a better product. You say that your software will become FOSS if you stop working on it to create more confidence in your product. These are all focused around selling your product, rather than around being genuinely free and open. Until you admit that this is what you're doing, you will be misleading people.

Re: FSL: A License for the Bazaar, Not the Cathedral

#145
post #133

Earlier quoted context omitted.

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

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 sti…

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/

Re: FSL: A License for the Bazaar, Not the Cathedral

#146
post #141

Earlier quoted context omitted.

Where do we (Sentry) ever call ourselves FOSS? If FOSS is represented by the community in this thread I want no part of that toxicity. We do what we think is good and for developers and customers, and the broader open source ecosystem. A lot of us have been doing that for quite some time and will continue to do so.

EDIT: actually, you couldn't be more blatently lying about this. https://open.sentry.io/ > We're Open Source The title of the page. You really thought you could sneak that past me. You cannot seriously make a reply like this when you have an entire domain name dedicated to the tile "We're Open Source". That is the most obvious of obvious lies. Even the page title "yes, we're open source" is a kind of passive-aggressi…

It’s not misleading. You claiming we say something we do not is.

I’m not going to continue this conversation as you’ve shown only to be here in bad faith.

Re: FSL: A License for the Bazaar, Not the Cathedral

#147
post #146

Earlier quoted context omitted.

EDIT: actually, you couldn't be more blatently lying about this. https://open.sentry.io/ > We're Open Source The title of the page. You really thought you could sneak that past me. You cannot seriously make a reply like this when you have an entire domain name dedicated to the tile "We're Open Source". That is the most obvious of obvious lies. Even the page title "yes, we're open source" is a kind of passive-aggressi…

It’s not misleading. You claiming we say something we do not is. I’m not going to continue this conversation as you’ve shown only to be here in bad faith.

If you explain how I've been in bad faith here, I'd be willing to rectify that. You asked a question and I gave you a pretty straight answer. I just can't see why you'd talk about FOSS so much if you really "want no part of that toxicity".

I also don't think it's bad faith to say that your decisions were motivated by selling your product. That's a perfectly reasonable motivation. I don't think it's bad faith to say you are misleading people, I never implied that you wanted to. You literally said a few replies ago that you thought I had been mislead into thinking you called yourself FOSS when you didn't. Maybe I am just stupid, but I don't think it takes and idiot to read "open source-minded company" and conclude that you are doing something open source. (In fact, wouldn't it be bad faith to assume that I was lying about what you've said rather than just mistaken?)

Re: FSL: A License for the Bazaar, Not the Cathedral

#148
post #81

Earlier quoted context omitted.

The people we're concerned about are not the hundreds of thousands of Sentry users, including those that self-host. We're concerned about people who have taken the software for the purposes of competing directly against us, that hinders our ability to monetize the work. Monetizing the work helps us continue improving the software and distribute it for free use, benefitting those aforementioned real users (e.g. https:…

There seems some kind of dissonance for me. You create a new license to keep competitors artificially in check. Doesn't this hint to a flawed business model?

what's "artificial" about a license? does proprietary source code keep competitors "naturally" in check? what does that term mean here?

Re: FSL: A License for the Bazaar, Not the Cathedral

#149
post #113
post #112

Earlier quoted context omitted.

The idea of the source being available but software not being “free” is fine by me. I want the source so I can fix bugs instantly instead of trying to convince some mid-tier product manager having gone through 5 tiers of support. That is a huge benefit over source-unavailable proprietary software, or (heaven help us) SAAS.

"I could fix it myself if needed" quite often comes up on HN and other programmer forums but I honestly have to wonder how many people could actually fix deep issues in production grade software. For example, there are plenty of bugs open on the issue trackers of (say) postgres or kubernetes yet despite the source of those being available I'm willing to bet a vanishingly small amount of users would be willing or capa…

It depends what the software is of course, but I've definitely fixed issues in a not unreasonable amount of time that in some cases would not even have been within the terms of any support contract (and would certainly have taken a tier 1 or tier 2 vendor application support an unacceptably long amount of time to do the same, assuming they didn't just close the ticket as unsupported use case).

Would I be able to do that for the Linux kernel? Of course not. But the vast majority of software out there is nowhere close to that level of complexity. And there are specialized groups that are trustworthy that we pay enormous sums to handle that and have had good experiences with.

So it depends but it's definitely a selling point of open source for a lot of systems engineering and adjacent roles that need to glue together lots of disparate pieces of software in sometimes unusual and unsupported ways, and sometimes for platforms that are not technically supported, or that the vendor is not able to establish any confidence in us that they will be able to support it competently for the next 10+ years for any number of reasons. That often requires forking the codebase.

To summarize, as someone essentially in the business of insuring for fortune 500s that aren't software vendors against startups and other companies deemed non-trustworthy or risky in some other way...the vast majority of YC style companies inevitably fall into the category of company where their software would not pass risk management processes for enterprise wide deployment without a proper open source license. A lot of that is down to regulatory requirements as well. It isn't some sort of irrational FAANG company "not developed here" ego boost.

For those of you that are new to the startup world, or weren't around back in the before times of the 60s-around about the mid 2000s up until the financial crisis, this may not make much sense. But it's very much the case that this ecosystem of software startups would not exist in any significant way if it had not gone all in on open source. I'm not sure how I feel about that morally or ethically but its something to think about when you are deciding how to license your software.

As far as these weird source available licenses go...it's an option but it's risky. Those familiar with the history of computing will know that the old mainframe OS's and commercial Unix's were both once source available and that ended up burning a lot of people when they started to restrict access to the source (a lot of our companies had and still maintain custom operating system modifications to legacy platforms from back in those days). The institutional memory of source available licenses (or in the case of MVS, no concept of software licensing at all) being used to turn the screws on customers is still very raw in the much slower moving world of traditional industries. Enshitification is not a new idea, some industries have been through multiple cycles of that process and have developed defense mechanisms.

Re: FSL: A License for the Bazaar, Not the Cathedral

#150
post #13

I like it. I totally get the problem projects like mongo, redis and sentry face. AWS, azure etc just eat their lunch and don’t help anybody. That will kill open source in the long run. This still gives me access to inspect the code, contribute fixes I might want, self host if I feel like it or pay someone for the SaaS if I don’t, knowing the money goes to someone who contributes to the project. And if the original au…

Two years is like 20 years in most software ecosystems. If a JS library or mobile front end used this license, by two years the underlying tech that old version used would all be extinct.

No it isn't. 2 years is very recent in most software ecosystems. Even in the JS world it is really very recent, depending on the software. E.g. 2 year old Bootstrap is perfectly fine.

2 years seems hilariously short for me. If AWS want to rip this off they'll be very happy to use code that is only 2 years old to do it. Or fork a 2 year old version and reimplement only 2 years of work.

4 years makes way more sense, and even that is quite generous IMO.

Post reply on HN