Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FSL: A License for the Bazaar, Not the Cathedral

lucumr.pocoo.org

Post reply on HN
Print view View original

61–70 of 201 posts

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

#61

Post by tedivm »

jorams wrote: post #35

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

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.

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

#62

Post by geerlingguy »

growse wrote: post #48

The definition of "harmful free-riding" is not good, and its use to justify the license is problematic. > Consequently, the common pool resource may be under-produced, overused, or degraded. Additionally, it has been shown that despite evidence that people tend to be cooperative by nature (a prosocial behaviour), the presence of free-riders causes cooperation to deteriorate, perpetuating the free-rider problem.” Soft…

I don't understand the philosophy of wanting to use open source and gain the community / benefits of it... but using a proprietary sales model.

It just doesn't work, and once you start calling users of your software who contribute nothing back anything resembling "freeloader" (whether or not you use that word), you've lost the whole concept of why most of us care about true open source. We can use it, we can learn from it, and for a very select few, we can even contribute to it or support the main devs monetarily or otherwise.

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

#63

Post by miragecraft »

James_K wrote: post #22

So, essentially, this is a closed source or source available licence. 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. I don't get how it solves that freeloader problem either. The one benefit I can see is that it forces software to stay relatively up to date as, if they don't make enough changes in a two year period, they will likely…

> I don't see any benefit to the developer using this license except that it makes them feel like they are doing open source.

This is not designed to attract open source developers, but offers reassurance to end-users against hostile vendor behavior (drastic price increase, disagreeable change of direction, general lack of development etc).

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

#64

Post by geerlingguy »

ic_fly2 wrote: 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.

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

#65

Post by the_mitsuhiko »

mcny wrote: post #42
the_mitsuhiko wrote: post #38

Earlier quoted context omitted.

> My understanding is that if I wanted to fork a piece of software, this licence would prevent me from doing so for two years. Then after those two years, I would essentially be stuck using an old version of the source and have to play catch-up with the devs, who would be able to use my work for free but I would not be allowed to use theirs. The answer is a bit of yes, and a bit of no. If the project is actively main…

What are your thoughts on AGPL? Is it not good enough? Do you think (lets say it out loud because we all know what we are talking about) Amazon Web Services will have advantage over you if you picked AGPL as your license? At the end of the day, I think your sales team has to earn its salary. It can't just phone it in like (I assume) Microsoft sales does with Microsoft SQL Server. Why isn't AGPL good enough? Genuinely…

> What are your thoughts on AGPL? Is it not good enough?

I'm generally not a fan of GPL based licensed because it means that you create a massive dis-balance between the original copyright holder (who can dual license for commercialization) and everybody else. It might be fine for Sentry or another SaaS business, but then you cannot even take pieces of code and use it in another project that cannot be GPL licensed because for instance it needs to go the app store etc.

GPL (and AGPL in particular) is considered such a tainted environment that many steer away from it entirely. AGPL also is from the v3 family of GPL licenses which have outright bans in many commercial environments. But GPL in general is a too complex topic to address in a HN comment for me.

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

#66

Post by bentlegen »

growse wrote: post #55
bentlegen wrote: post #43

Earlier quoted context omitted.

> My interpretation of this license is that it's effectively saying: "you can't do anything with this while we're working on it". I disagree. It depends if you're forking it to use it, or if you're forking it to compete commercially against the authors. The license does not prevent you from the former. You could fork it and do what you want with it to monitor your own non-competing software. And if your goal is the l…

> I disagree. It depends if you're forking it to use it, or if you're forking it to compete commercially against the authors. The problem is that whilst the license attempts to define what "competes" means, it's not a good definition. Specifically: Competing Uses specifically include using the Software: 1. as a substitute for any of our products or services; 2. in a way that exposes the APIs of the Software; and 3. i…

I'm not a lawyer, but here's my non-official interpretation:

1) If you host the software, and say "hey get your Sentry over here", that's basically a substitute.

2) Means use the work in such a way where you expose its APIs (i.e. the software is returning API responses). Note this is written as "using the software ... in a way that exposes the APIs of the software".

Perhaps this could be made more clear, but I believe this was written with the understanding that there is prior art on the copyrightability of APIs, not some feigned attempt to assert a copyright.

3) If you're building some kind of software observability platform that leverages Sentry.

If you're concerned about doing any 3 of those, then yes, perhaps you should not use the software. Overwhelmingly 99.99% of software people aren't doing anything remotely close to any of these clauses.

I'll also note that Sentry itself was licensed for 4+ years under BUSL using similar terminology (that was arguably far more vague). The inclusion of non-competitive language in the license did not stop users from using the software – because again, most people aren't competing.

You're welcome to make your own decision, of course. No one is forcing you to use anything.

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

#67

Post by the_mitsuhiko »

geerlingguy wrote: post #62
growse wrote: post #48

The definition of "harmful free-riding" is not good, and its use to justify the license is problematic. > Consequently, the common pool resource may be under-produced, overused, or degraded. Additionally, it has been shown that despite evidence that people tend to be cooperative by nature (a prosocial behaviour), the presence of free-riders causes cooperation to deteriorate, perpetuating the free-rider problem.” Soft…

I don't understand the philosophy of wanting to use open source and gain the community / benefits of it... but using a proprietary sales model. It just doesn't work, and once you start calling users of your software who contribute nothing back anything resembling "freeloader" (whether or not you use that word), you've lost the whole concept of why most of us care about true open source. We can use it, we can learn fr…

> once you start calling users of your software who contribute nothing back anything resembling "freeloader"

Who does that? Certainly not us.

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

#68

Post by the_mitsuhiko »

jorams wrote: post #35

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

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

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

#69

Post by joshuaissac »

growse wrote: post #48

The definition of "harmful free-riding" is not good, and its use to justify the license is problematic. > Consequently, the common pool resource may be under-produced, overused, or degraded. Additionally, it has been shown that despite evidence that people tend to be cooperative by nature (a prosocial behaviour), the presence of free-riders causes cooperation to deteriorate, perpetuating the free-rider problem.” Soft…

> If your business model relies on no-one else using your software to compete with you, don't open-source the software.

I think this is the point of the FSL. Businesses with the business model you described can use it instead of open sourcing the software, and the terms switch to an open source licence only after two years.

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

#70

Post by growse »

joshuaissac wrote: post #69
growse wrote: post #48

The definition of "harmful free-riding" is not good, and its use to justify the license is problematic. > Consequently, the common pool resource may be under-produced, overused, or degraded. Additionally, it has been shown that despite evidence that people tend to be cooperative by nature (a prosocial behaviour), the presence of free-riders causes cooperation to deteriorate, perpetuating the free-rider problem.” Soft…

> If your business model relies on no-one else using your software to compete with you, don't open-source the software. I think this is the point of the FSL. Businesses with the business model you described can use it instead of open sourcing the software, and the terms switch to an open source licence only after two years.

Sure, but then just do proprietary and then release the software under Apache. What's the actual point of the FSL?
Post reply on HN