FSL: A License for the Bazaar, Not the Cathedral
lucumr.pocoo.org
lucumr.pocoo.org
This writing is just as confused. The author is missing the basic points of a license: A license is like a constitution for an ecosystem for how people will interact, a check-and-balance on the monopoly power of the license-holder, and a community contract. The FSL is looked at through none of those lenses. The attempts at empathy with the opposing viewpoints clearly don't express an understanding of those viewpoints. The reasoning is just bad.
Even taken at face value, a license which does not set up an ecosystem of equals is a cathedral license, not a bazaar one. The citation is weird.
Analyses needed for licensing:
- Who will contribute, and why?
- What ecosystem is being set up? One of equals? One with a central party?
- Why will my customers give me money? Does this preserve my ability to make money?
... and so on. Those require deeper dives. "If you build it, they will come" doesn't work. If you want contributions, for example (not everyone does), you want to do a deep dive on the needs, wants, and motivations of potential contributors. An ecosystem of equals (bazaar) will bring in more contributors, but also more competitors.
I'll give a personal example:
In my professional work, I use 100% open-source, largely to mitigate for the risk of what happens when the cloud vendor disappears. FSL mitigates that risk, while BUSL doesn't.
The license seems non-crazy, though, and a huge step up from BUSL. What's concerning, though, is that it's completely unclear that the author understands why this license makes sense, so it's liable to be misused. It feels more accidentally-stumbled-upon.
The author of the post (me) was part of the group at Sentry that created that license. I can’t dispel your interpretation that my writing is “confused” but I can assure you that a lot of thought went into the license.
That blog post is not a “here are all the reasons for the license” but it narrows down on a very specific aspect of it. You can read the original announcement post for more context and you can also listen to a panel discussion about it with me, Chad from Sentry and Heather Meeker who helped us draft it: https://www.youtube.com/live/UB9fo7pnDzY?si=0HVI6FsR42Pn5yP2
> There cannot be a limbo where the rights holder prevents the flourishing of a fork out of lack of interest or fear.
The entire point of this license is to prevent forks of software. It makes it especially easy to do so by simply pushing small incompatible changes on a two-year schedule.
But the really strange part about this is that it assumes a developer that is scared of allowing their work to be forked would decide to use a license that forces them to allow their work to be forked. They simply wouldn't. That's the exact thing they were scared of.
If that was the case, it would be a different license. The point of the license is to enable forks, but with some restrictions. There are many (once) Open Source software projects where the rights holder at one point made decisions that required a full community (or even commercial fork). The license does not want to take that opportunity away. From MySQL to MariaDB, from OpenOffice to LibreOffice, many projects no longer live under the original leadership. There are also other cases such as Xapian which are stuck under a GPL license that prevented adoption, but the rights holder (I believe it was Orange) had no interest in the project but also no desire to relicense under something that would permit commercialization.
The point of the license is ensure that the commercial entity (us) that is funding the project, can do so without taking away the long term viability of the project even beyond the hypothetical future non-existence of that entity.
My interpretation of this license is that it's effectively saying: "you can't do anything with this while we're working on it". Which is fair enough and has its benefits, but it's not open source as much as it is a promise to become open source if the licencor ever loses interest.
All those examples you cited weren't using this licence, and probably would have had a much harder job creating their forks if this license was used. Xapian specifically highlights a flaw in your logic. The creators of Xapian wouldn't have used this license because they don't want to re-licence their software. The only people that would use this license are ones who were already willing to re-license their software. The existence of this license doesn't actually solve the problem because you can't force people to use this license any more than you could force them to use an open license.
*edit: it's worth pointing out that this really does basically kill any chance of a fork. Normally you could start a fork with a single dev and then grow it naturally, but with this license you need a team the size of the official team to put in two years of work, and to keep doing that in perpetuity.
The answer is a bit of yes, and a bit of no. If the project is actively maintained then that company that does so, has the first mover advantage. If that company slows down / does something dodgy, you can fork it that very moment. You can't commercially compete for two years which is correct, but it opens up that opportunity.
> Had this license not been used there would be nothing preventing me from forking the software.
Except potentially an even worse license or an open core model where the best bits are not public at all. I do not believe this to be a better model. You're right that in the hypothetical situation a project could be open source without any restrictions and the original developers can reap the benefits without any free-riders coming along. But our experience has shown that just appealing to the good in people doesn't work.
> All those examples you cited weren't using this licence, and probably would have had a much harder job creating their forks if this license was used.
I would argue that that is not the case. Xapian under a hypothetical FSL would long have been able to commercialize it. MariaDB had more options for commercialization than they do today because of the GPL limitations. That said, I'm not working there so I cannot say how much the GPL was a hindrance.
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 asking, what change does it need to make it better?
Edit: previously on hn https://news.ycombinator.com/item?id=34768668
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.
> 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.
This is very helpful, thank you. I have no insider information about elastic or sentry. Everything I know about the whole thing is from comments such as from HN. What I am hearing from you is that you don't see big cloud providers such as AWS as a threat but rather as an insurance policy so as users you can feel relatively safe in picking a SaaS product knowing that in the future (two years from now?) if the vendor were to go tits up, you can still have someone else who will step in and fill the void. I thought your intention was to make it as difficult as possible for another SaaS provider to compete against you but... clearly not? I appreciate the thoughtfulness of all of this and the pain of SaaS customers because just having the source code isn't enough. Often times, I am simply not qualified to run something like sentry myself and it is a matter of either spending tens of thousands of dollars a year on a SaaS or spending hundreds of thousands of dollars on another dedicated employee.
That being said, what I am reading from your comment is that the problem with GPL at least from the perspective of the user is all about perception and not about substance.
From what I understand as a hobbyist, I can essentially disregard licenses altogether. I am not distributing anything. You could license flask as Oracle Evil License (not actual name of the license, just making it up) and it wouldn't matter as a hobbyist because all I am doing is learning about flask.
What I mean is AGPLv3 should be fine for companies who are not SaaS providers and those who are SaaS providers, should contribute back.
What makes you not a fan of GPL?
I feel like you still aren't understanding what I'm saying here. Suppose a hypothetical version of the Xapian devs existed that were willing to use the FSL, but didn't because it didn't exist at the time. I could email those people, and ask "can you give me an Apache licensed version of your code from two years ago". They would then give me a copy of that code. The license is just a written expression of what a developer is willing to do. The existence of this licence doesn't actually change what devs are willing to do. It doesn't solve any problems. Anyone not using this license can still release old versions of their software under a different licence. Likewise anyone using the licence can always stop using it for future revisions of their software. It doesn't enable you to do anything, and it doesn't provide much of a guarantee to users.
Just to be clear what happened at Xapian: a bunch of people built some software. It was open sourced under the GPL which prevented further adoption. Through some series of acquisitions the copyright holder ended up not caring about it and did not enable anyone to relicense it under another license. If that was FSL licensed to begin with, the moment the copyright holder no longer cared, it would have become available under a license again that enabled commercialization. The folks behind Xapian are unaware of the exact licensing status, but definitely cannot relicense: https://trac.xapian.org/wiki/FAQ/CommercialLicence
They for a while I believe tried to prevent further GPLification of the source.
This isn't really a rebuttal to my wider point that FSL doesn't do anything you couldn't without it. There's nothing stopping you from just releasing old versions under a different license anyway, and no real reason to commit to doing so specifically for the next two years.
That would not work to begin with, and I already explained elsewhere in this comment thread why.
Look, I understand that you do not subscribe to this argument, there is very little I can do to convince you otherwise. I'm coming out of a community that embraces permissive licenses. The FSL plays that tune with a twist that is the exclusivity period.
> There's nothing stopping you from just releasing old versions under a different license anyway, and no real reason to commit to doing so specifically for the next two years.
There are lots of things that can be done, many other licenses can be forged. But some of these are depending on the goodwill of a future actor. All of this seems worse.
Your explanation seemed to be predicated on the idea that you would have to stick to the terms of your own licence. This isn't true. A license only describes what other people can do. As the copyright holder, you can do whatever you want. For instance, you can offer a dual license, or offer different licenses to different people. An FSL-GPL is perfectly feasible.
> But some of these are depending on the goodwill of a future actor.
The FSL also depends on this. Someone releasing FSL code could easily switch to a different license at some point in the same way that someone who was releasing their past source code could decide to stop doing so. This would result in an almost identical situation in practice. The FSL still offers no difference from just releasing the source voluntarily, because it is just you agreeing to release the source voluntarily.
In the future. A copyright holder can’t change the artifact you are already holding.
> The FSL also depends on this. Someone releasing FSL code could easily switch to a different license at some point
Sure. At which point it no longer is FSL licensed. The code drop of today is fully open source two years from now. Nobody can take that away.
Yes, but you can literally just copy the GPL into the bottom of the FSL and you have a valid license.
> The code drop of today is fully open source two years from now. Nobody can take that away.
If you open-source the code-drop from two years ago, no one can take that away. There are two cases here:
If the code isn't FSLed and the dev decides to stop distributing source, a fork will have to be made using the outdated source that has previously been released under an open license.
If the code is FSLed and the dev decides to drop FSL, a fork will have to be made today using the old code, or can be made later using code that's just as out of date.
These aren't substantially different.
That something useful is restricted, which is the point of the license.
I think the intention here is reasonable and honest as presented by the big list. Whether the actual legal language matches that intention - who knows. I'm worried that it might not but IANAL.
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 latter – to fork the project to compete with the original authors – why do you feel you should be allowed to do that? Sentry is developed by employees on its payroll, not from community contributions (with a caveat that there are many parts that are fully permissive OSS, licensed under Apache 2 or MIT, and those projects do have some community contributions). And yes, the license is meant to discourage this competing use – for 2 years.
The right to make alterations to someone else's intellectual property does not exist except as granted by licence or fair use exceptions.
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. in a product or service that offers the same or substantially similar functionality to the Software.
(I suspect this is on purpose, and the actual motivation of the license author is to try and discourage anyone else from using / forking the software, whilst at the same time getting marketing cred for pretending to be "open". It's a source-available license. Others may come to different conclusions).
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.
Here's a history:
https://en.wikipedia.org/wiki/Copyleft#Viral_licensing
FYI: The Linux kernel is GPL, and is used on most cell phones, routers, and a huge number of other embedded devices. It powers most of the servers on the internet too. It's simply not the case that it has been any hindrance to commercial use. You should reconsider some of your comments. You equate GPL with non-commercial.
I've built software under GPL-style licenses which has generated hundreds of millions of dollars of commercial value.
It limits some modes of commercialization, but this is one of the places your thinking is confused.
What does that achieve? You can just use the two-year-old copy of the code.
> The entire point of this license is to prevent forks of software. It makes it especially easy to do so by simply pushing small incompatible changes on a two-year schedule.
I couldn't say it's the motivation, but this easy ability to make forks unable to effectively stay in sync goes against the motivations of free software. And for that reason, "I'm out."
That doesn't contradict what I wrote.
The thought shows.
What it doesn't show is understanding or (and I don't mean this aggressively, but I'm worried it will read as such) competence.
To give an analogy, if a lawyer came learned programming and wrote a very clever piece of code, but without any of the experience or background that develops from having been a software engineer or formally trained, you might get something interesting, but probably not necessarily helpful. There's a body of things which people in the field know from decades of collective experience which they would be missing.
When there's a post like mine, there are two possibilities:
1) You're missing something
2) I'm missing something
I would at least be open-minded to the former, since that would have implications which could adversely impact your business.
To be crystal clear: I don't think the license is bad, stupid, or unreasonable (your previous one, in contrast, was). I would never do business with BUSL. I would with FSL. It's a reasonable scheme.
However, the connecting logic and analysis between the license and business strategy is missing, confused, or incorrect. It's also incorrect about the implications of GPL/AGPL and dual-license models. Without that logic, you will misuse it. You won't be able to leverage the advantages of open-source, and you might be blindsided by the downside.
You're trying to do something novel. In business, I tend to think about things which are:
- Competitive advantages. There, I'm trying to do something better, novel, and develop unique expertise.
- Everything else. There, I follow best practices, outsource, and otherwise don't invest.
You're very much doing something novel outside an area of your (personal) area of expertise. My advise would be to either:
(1) Go with best practices
(2) Develop expertise.
For the latter, my advice would be to talk to someone like myself, Eben Moglen, or otherwise, until you can articulate their arguments, how they think about licenses, understand why that's reasonable, and articulate their arguments to others (not cynical versions of them) to the point where someone like myself believes you understand them. At that point, you're ready to innovate from there to gain business advantage. Before that, you're not; innovation is likely to lead to market disadvantage.
It may also be that people within your business have that background (I don't know how your positioned). Perhaps Heather and Chad know something you don't. In that case, it's incumbent for you (and others inside) to pick it up, so you can leverage it in day-to-day decisions and outwards communications.
Consider me as a potential customer. If I read a blog post like yours, it will reduce your odds of a sale, since it raised red flags about your competence in my head. If nothing else, if you understand that perspective, you can avoid raising red flags (even if I'm the one missing something; others will be missing the same thing too). It's good business to dispel the notion your writing is confused, since sales is all about winning hearts and minds.
If that's the case, you will have a very hard time selling to folks like me.
That's bad business.
Even if I'm wrong, you need to figure out how to reach customers like me.
> If you take issue with Open Source developers having opinions about Open Source licenses and similar ones, then I'm afraid you will run into many more folks like me.
I have not found this to be the case. Most have more curiosity and less ego.
I'm not even sure what I have to sell to you? What do you think I'm selling to you?
You've taken me from: Nice competitor to New Relic, and open-source.
To: Nice competitor to New Relic, and open-source, but with an ego problem, doesn't want me as a customer, and likely a bit incompetent.
Every public interaction is about building brand and sales. I'm offering transparency on impact. That's a gift. It's hard to get frank customer feedback. You're treating it as an insult.
> A license is like a constitution for an ecosystem for how people will interact, a check-and-balance on the monopoly power of the license-holder, and a community contract.
finally gave me an answer to the question that bothered me for a while: how do we reconcile the goal of making FOSS available for everyone to run/tinker with/distribute freely with the issue of corporations leeching off community-created FOSS? Now the solution is clear to me: less focus on licenses, more focus on people interactions and actual contracts.
Instead of writing some code and throwing it to the MIT-license winds with little hope to gain anything in return it should be possible to create software cooperatives, i.e. real legal entities, with a simple premise: the code is free for non-commercial use; any person whose contribution was accepted is free to join the cooperative; any company that wants to use software stewarded by the cooperative has to pay for it, with said payment being shared among the members and/or saved for later. That would be an overkill for a tiny personal weekend FOSS project, but for serious products the overhead of formalizing the community would likely be totally worth it.
I'm pretty sure I'm not the first to come up with such an idea, I wonder if anyone has already implemented it in practice.
> less focus on licenses, more focus on people interactions and actual contracts
This gives the impression you support sticking to truly Free and Open Source software licences.
> the code is free for non-commercial use
A licence that explicitly forbids commercial use in this way is neither a Free Software licence nor an Open Source licence, by definition.
> I wonder if anyone has already implemented it in practice
The Business Source Licence (aka BSL, or sometimes BUSL for some reason) pretty much does this. [0] It is neither a Free Software licence nor an Open Source licence. (They're pretty upfront about this, which is good.)
BUSL/BuSL gets used as BUSL is the SPDX identifier. It's the SPDX identifier as BSL was already taken, by the Boost Software License, which predates it.
> Free software is software that gives you the user the freedom to share, study and modify it. We call this free software because the user is free. [2]
I believe you'd agree that everything-as-a-service and tivoized products do not make users free, even if they technically don't violate the terms of FOSS-licensed code that they incorporate.
> The Business Source Licence
Yes, I've heard about that license, but I think it's mostly applicable when an already existing company decides to make its product more open, while I was thinking of the opposite — a group of independent contributors realizing "hey, we've made something big, let's protect our work (and potentially get rewarded for our efforts)" and creating a more formal entity around it.
[1] https://opensource.org/osd/ [2] https://www.fsf.org/about/what-is-free-software
It's not a mere technicality, it's an important point of principle.
The FSF used to use the term semifree for such licences, but now just call them proprietary or nonfree. [0]
Similarly the OSI page you linked shows that the OSI considers non-commercial restrictions to breach criterion 6, No Discrimination Against Fields of Endeavor.
> you'd agree that everything-as-a-service and tivoized products do not make users free, even if they technically don't violate the terms of FOSS-licensed code
Tivoization was addressed in GPLv3. The SASS point is less clear-cut as it's not obvious how to define the relevant boundaries, but roughly speaking the AGPL addresses this.
Not all problems can be addressed by software licences though.
> a group of independent contributors realizing "hey, we've made something big, let's protect our work (and potentially get rewarded for our efforts)" and creating a more formal entity around it
The point remains that if they adopt a licence that prohibits commercial use, the project is no longer Free and Open Source software. There's certainly a place for formal organisations though, and there are many of them in the FOSS world: FSF and GNU, OSI, SFLC, Linux Foundation, Apache, Mozilla, Eclipse Foundation.
There's also TideLift which seems to be doing well raising funds for FOSS contributors while also improving software quality. [1]
[0] https://www.gnu.org/philosophy/categories.en.html
[1] https://medium.com/general-catalyst-amplified/introducing-ti... (I would link to their official About page but it's pretty uninformative)
For the entire first paragraph, I had no idea who you were referring to; then I realized you were talking about Stallman!
The Richard I was imagining in my head was more Hendrix, not the various oddities and eccentricis of Stallman.
> 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.”
Software doesn't wear out, or degrade through use. The analogies offered to other, physical common services are nonsensical.
Also, there's plenty of projects that are open source, have an enormous amount of usage, and don't suffer from this problem. The difference between these and projects which perceive they suffer from the "harmful freeloading" problem is not the license, it's a badly-thought-through business model.
If your business model relies on no-one else using your software to compete with you, don't open-source the software. Especially don't whine about it and then pretend to open source it. Just do proprietary.
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.
Who does that? Certainly not us.
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://github.com/getsentry/self-hosted).
You create a new license to keep competitors artificially in check.
Doesn't this hint to a flawed business model?
The new license actually allows for more competition, because it has a shorter change date to permissive OSS than the aforementioned prior license (2 years vs 3 years).
So another read of this is: the business model is going great, so much so that we're comforable switching to a more progressive license vs. what we had.
I think it’s worth reading the announcement from 2019 when Sentry first switched to BUSL. The original article links to many such pieces.
Then release your software under a source available non-compete license with the caveat that it will become open source when you stop working on it. (Basically what you have already done.)
Don't pretend it's FOSS or that it has anything to do with open source because it isn't and it doesn't. You have not made the software open until you have relinquished it to the community at large to do whatever they wish with it. Open source developers dislike this kind of marketing because it muddies the waters of what isn't and isn't free. If someone contributes to your software thinking it's free, you have mislead them to profit off their work. I don't care what you do with your code, but don't mischaracterise it. Don't give big talk about how you "believe in open source" or whatever. Say that you are source-available, and that isn't FOSS, but say no more than that. Especially do not say that you are "The Future of Open Source". That is nothing but a lie an it's obvious why real open source developers giving their time for the public good would take offence to it.
Open source is like charity. Don't call yourself a charity or associate yourself with charity unless you actually are one.
Done.
Note that the license website is pretty clear that it is not Open Source. If you find a place where that is not true, you can open an issue on the website’s repo and we’ll address.
Then fix this one: https://open.sentry.io/
You have admitted that you aren't open source and that this is a blatant lie so remove it.
Because the users who pay / use the software as the developer intended are to be rewarded with new features sooner.
> Either you want competition or you don't
Customers want competition. To a first order approximation businesses don't. No one want competition for SEO which is essentially what is being suggested here. If the product can be taken and spun up instantly on any new release all the "competition" is on who can make page 1 of Google. As we have all seen with stack overflow content this is not ideal.
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.
> 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.
I’m not going to continue this conversation as you’ve shown only to be here in bad faith.
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?)
Open source is constantly under attack from various corporate entities, so it makes sense that we should guard our image. Asking people to be clear about what is and isn't FOSS is a basic consequence of that. FSL is a source available license, and I am simply asking that its users make this fact clear instead of trying to associate themselves with FOSS. That is not unreasonable. That is not toxic. That is simply asking that people don't obfuscate the truth.
> Asking people to be clear about what is and isn't FOSS is a basic consequence of that.
You are throwing around wild accusations bordering on the conspiratorial and making demands that are just beyond reason. The simple good-faith reading is that the Sentry people want to be as "open as possible" without compromising their business to the point of being unviable. There is nothing I know in the entire context and history of Sentry that would dispute that, and you've certainly provided zero evidence of it.
Quite frankly it amazed me that the people at Sentry even try in the face of complete rubbish that's being thrown around here by various people.
> People have come out of Guantanamo Bay less tortured than that analogy.
A charity is an organisation of people can donating money or doing volunteer work to contribute to a cause they see as in the common good. An open source project is an organisation of people donating money or doing volunteer work to contribute to a piece of software for the common good of its users. They are more than a little similar. Even if they aren't, people deserve to know where their work goes if they are doing it for free.
You suggesting we are anything but what we are just makes you look like you have an agenda at best, or foolish at worst.
All you're doing is harming the broader community by arguing about nonsense which is factually proven to be untrue. You came in here trolling as best you could, making false statements without reading or educating yourself on any components. Making statements as if you're a legal expert, as if you're an expert on open source history, on who or what Sentry is or has been.
1. A majority of Sentry's source code permissive open source. This is a fact, and easily verifiable.
2. FOSS is not Open Source. So when you constantly equate the two you simply come off as misinformed.
3. Sentry has continually shown good faith in a variety of activities, including donation of services, financial backing of large projects, financial backing of our dependency graph.
4. We are not rug pulling - we migrated our BUSL-licensed projects to FSL. BUSL is already non-compete source-available, FSL is the same thing but a more aggressive time-delay, and a better license conversion mechanism.
5. There is no "vague legal speak designed to [do anything harmful]". If its vague to you, maybe you should stay away from licensing, or you should start contributing back intead of creating toxicity on internet forums. In fact, the FSL is designed to be _more easily understood_ than prior licenses of its type.
2. I know. I type one because it is shorter. As cool of a pedantic ad-hominem as this is, my arguments all hold up when you replace FOSS with open source. So imagine I have done this.
3. Irrelevant.
4. Irrelevant.
5. Irrelevant.
Stop calling everyone who disagrees with you toxic. Stop lying about being open source on your website https://open.sentry.io/.
Several of our core services are licensed under the FSL (previously the BUSL). Some of that code was open source a _long_ time ago, some was never open source. Most of our projects are licensed under permissive licenses, including many projects which other companies rely on _to directly compete with us_. When I say "the majority of Sentry is open source" I mean that literally, both with many older versions of our software being more free than any copyleft license would make it, as well as many of our "hard" technologies being open by default.
None of my points are irrelevant beause you're all over this thread suggesting bad faith by Sentry, by our employees, by others in the community. You seem to have an awful lot to say about how harmful Sentry is, and how harmful some of our employees are who have been contributing in significant ways for their entire career. That is definitionally toxic, and exactly why HN has such a bad reputation.
Is the messaging on that URL you found misleading? Yes, and we will improve upon that, but that doesn't make you right. You just continue to look like someone with a grudge who is wildly misinformed, making demands as Anonymous Internet User #67.
Will you improve on the rest of your messaging? For instance, the FSL is not "closer to open source than source available". It is just source available. You seem to view "that URL" as something external to your organisation – a little slip-up in an otherwise clean record – but I see it as a logical continuation of a long process of making yourselves seem as close to open source as possible. Every communication I've seen has been worded to downplay the ways FSL is not open source. You start by calling it a "not OSI approved" license instead of just source available, then you move on to an "eventually open" license then a "mostly open" license then a "more open than not" licence. Dropping the qualification is just the end point of all this. If you had started with the attitude "this isn't open source, we wish it could be but we can't manage that", you would not have eventually told a full blown lie. A lie is just what happens when you keep permitting half-truths. It's the exact reason I'm so pedantic about this and view even the small missteps as so important. You have seen here the direct consequence of them.
Real improvement on this matter will require you to change a lot more than the most obvious failure.
> you're all over this thread suggesting bad faith by Sentry, by our employees, by others in the community. You seem to have an awful lot to say about how harmful Sentry is
I believe that communicating you are open source when you aren't or attempting to create ambiguity in the definition of open source is harmful. It doesn't matter who's doing it. Doing unrelated good deeds isn't an excuse. You could be curing cancer or creating world peace for all I care, I would still insist that you do not associate this source available license with open source. I have accused you of doing this to improve sales, which is bad faith as it may be you had some other reason, but also an important point to make – these kinds of misrepresentation may influence people to pay you money and hence have real stakes. People in this very thread have said they bought your software under the impression it had some of the favourable aspects of open source which are impeded by the FSL.
> That is definitionally toxic, and exactly why HN has such a bad reputation.
Maybe people would reply to you in a less "toxic" manor if you didn't make every attempt possible to insult them and every community they are a part of. Just a passive-aggressive suggestion.
> You just continue to look like someone with a grudge who is wildly misinformed, making demands as Anonymous Internet User #67.
So you admit to being incorrect, and to having lied in a number of aspects, but you still want to keep insulting me? And you think I will come out of this looking bad? Maybe you should apologise for your mistakes instead of demeaning me and and the entirety of the open source community and HN. A simple "you are correct" would have sufficed even if you couldn't manage a "sorry".
sorry, what?
All Free Software licenses are also Open Source licenses. so how can FOSS be not Open Source?
If you don't, it's pretty weird to want to do what you "think is good for the broader open source ecosystem".
But now that the idea is "out there" everyone can produce it, perhaps even cheaper. Actually, all other things being equal they will always be cheaper because they don't have three years of development costs.
Does this mean that selling these coat hangers is a "flawed business model" because cheap Chinese knock-offs can undercut her (small) business?
I know lots of people here don't have a lot of love for patents, and neither do I, but these kind of protections do exist for a reason. That doesn't mean I think that our current systems of patents is the best solution, but it also doesn't mean we shouldn't have any protections. And "be better at marketing" strikes me as a very poor answer.
My point here is that "produce something, but take a bit of protection against being exploited" is fairly reasonable in many cases. I also don't think it's "artificially" because under more traditional EULA-type software you're not allowed to do anything except "run it, but only in the way we want".
the coathanger is the kind of case that patents were intened for.
software patents are different.
as far as i am aware most people dislike software patents specifically and are fine with other patents.
and even with software patents the problem is not the idea of patenting software, but the broad scope and timeframe. for software 20 years are just to long, and many patents are to broad.
if software patents could be reduced in scope and more importantly reduced to a lifetime of eg no more than 5 years, they would be much less of a problem.
When the FOSS you're trying to build and share isn't covered by those- when you need to self fund so you can have an actual life- that's where it's always broken down. Patreon/gofundme type stuff can fly in single dev setups, but doesn't scale when it's a large team. There are exceptions to what I'm stating, but as a general rule, this is my experience across a couple decades of FOSS.
So if you want to build this thing full time and share it with others, and not subsist just on cardboard ramen and other folks coaches, what's your options here? Provide a paid service in parallel (we host it for you). What do you do when others take your development work- which has an inbuilt RD cost (development)- and try to compete with you via offering lower prices since they're just paying hosting rather than hosting + development?
The phrase you quoted "harmful freeloaders" does not appear in any of our texts. The word we used are "free-riders" and that does not refer to our users. Our users are free to use the software without contributions in any matter they want. What is not acceptable is to use it to run a competing SaaS business.
This is nit-picking pedantry. The term "free-riders" appears six times on this site https://fsl.software/, but my bad for using a slightly different term that has the same meaning. From your very public announcement and linking to the text, it's pretty clear what you think of some of your users.
> Our users are free to use the software without contributions in any matter they want. What is not acceptable is to use it to run a competing SaaS business.
You're redefining the concept of "user" to suit your own ends.
(There was a talk given at Strange Loop titled The Economic of Programming Languages by the creator of Elm about this and it sounds like he's hesitant to release something interesting he's been working on because of it. So it's a real issue in my opinion that can lead to a worse outcome for most of us.)
It's perfectly reasonable not to subscribe to this ideology. I don't particularly think it is a very good or well motivated ideology. However, you can't pretend that you are a free software adherent while also wishing to prevent certain uses of your software.
Note that Stallman has explicitly come out against IBM RedHat's similar complaints about people distributing copies of RHEL for free for this very reason.
The clause is not written in good faith. It's designed to essentially make it enormously risky to use in any serious environment, because the actual ambition by the clause author is that no-one else uses their software.
I don't challenge that the license may have shortcomings, but I think better evidence is needed before bad faith can be asserted.
Then the next sentence immediately goes into ways in which it is not intended to be used. Make up your mind guys.
All the attempts to block large corporations from using their code, block competition using their work, etc feel like the actions of companies that went open source for the social brownie points and because it was the 'right' thing to do, then realised too late that their business isn't going to work the way they expected it to as a result.
If anyone wants to work on open source/release their work as open source, the best thing to do is for them to treat it like a hobby with no expectation of a return at the end. If they want money for their software and hate the idea of infinite competition, then open source isn't the right model for them/their company.
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.
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.
Some other patch that was written by someone else at my company is now part of postgres.
Most recent examples I can remember: polars data conversion errors, batch sizing in azure service bus sdk, some weird validation thing in pydantic and the performance monitoring in sentry not working as expected. The pydantic bug got a patch / note in the docs that was actually already merged.
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.
This is not a "user" in any common-sense definition of the term. And yes, these people are "getting a free ride" (i.e. "free riding") because they get software with zero cost to them. That's on its own is not really a bad thing – I "free ride" loads of stuff, as do we all – but the "undercuts our business model" is. I'm not a huge fan of the "free rider" phrasing because it doesn't emphasize the core problem, but it certainly means something different from what you're taking it means.
Simple saying "your business model sucks then", as the previous poster did, is too easy. SaaS is the obvious business model for something like Sentry, and this benefits not just Sentry but also the users who don't want to self-host (i.e. most users).
There are other ways, but they're much harder. PostgreSQL and Linux are mostly developed by organisations which use or offer PostreSQL and Linux as a service, so it's more or less the same business model but with extra steps. Ideally having the SaaS company separated from the software development like that is better, but also really really hard to do because it's a catch-22: you need to develop a community for the software, but to develop the software you need a community. PostgreSQL's and Linux's pre-cloud roots are a huge boon here.
Their comment doesn't say that. Did they edit their post, or are you just shamelessly throwing around made up quotes?
> the "harmful freeloading" problem is not the license, it's a badly-thought-through business model.
Open source code is a much better protection for your customers than an escrow because all kinds of events can occur that don't quite trigger this escrow but which the customer could never have allowed to be risks if they'd been itemised.
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.
I’m not sure it’s actually a good idea, just that I think I understand the intended logic of it.
> but is closed now to create scarcity
1. It's not about scarcity. The software has always been given away for free for non-competing use (it was licensed under BUSL for 4+ years with a non-compete Additional Use Grant before this change).
Sentry's cloud offering (sentry.io) has always "competed" with its own free self-hosted users, and the new license doesn't change that. It's strictly about preventing free-riders who monetize the work without giving back.
> it’s different from simply switching to Apache later because it’s the promise that’s doing the heavy lifting
2. I agree, but I want to clarify that it's not a promise (which could be broken). It's a grant that is written into the source code itself (in the LICENSE file). If you possess a copy of the code today with this LICENSE file, in two years that copy will be Apache 2.0.
So you would rather have completely closed source instead of Open Source-but-for-one -detail?
That's some puritanical ideology-driven nonsense. Be against this license if you wish, that fine and I'll happily debate anyone about it. But this is not a position I consider valid because obviously "more open" is better.
Yes, because it's more honest about its intention. "but-for-one" is not open by definition, and trying to draw an equivocation is, ironically, free-riding off the virtue and benefits of actually open source projects.
They're not dishonest. That you're unwilling or unable to accept anything other than a black/white worldview is not their problem.
And "not open by definition" according to what definition of "open"? It's a vague and nebulous word that can mean any number of things. You don't get to single-handedly define this. Hell, people were using "Open" to mean all sorts of things long before 1998 as it was pretty much the buzzword of the late 80s/early 90s.
It's not a new term.
> They're not dishonest. That you're unwilling or unable to accept anything other than a black/white worldview is not their problem.
You can't be "a little bit open source". You are or you aren't. Some people might not accept that the definition is clear and well-formed, but for a lot of us it is. If you want to write proprietary software, great. People just get annoyed when it's dressed up as "a bit like open source".
Of course you can. There are 10 bullet points on the OSD. If you meet 9 then it's 90% there. This is obvious better than 80%, which is better than 50%, which is better than 0%.
> Pretty much everyone I know in the industry uses the definition of "open" defined by the OSI, in relation to "open source"
OpenLinux, OpenDOS, OpenGL, OpenBSD, OpenStep, X/Open (later: Open Software Foundation, The Open Group), Common Open Software Environment, OpenVMS, etc. etc. Some of these are also "Open Source", some are not, and for some "Open Source" doesn't even make sense. But all of these usages of "Open" predate "Open Source", and I'm sure there are dozen more examples if I cared to look further. Oh, and here's Bill Joy using "Open Source Code" in 1985: https://www.youtube.com/watch?v=0DdoGPav3fc&t=826s
The fact that HN has a discussion about "what Open source really means" demonstrates that NOT everyone has the same definition, otherwise these discussions wouldn't exist.
To lay claim on not just the phrase "Open Source" but the very adverb "Open" is not just historically incorrect but also hugely unreasonable.
Way may just have to agree to disagree then. I find it interesting that the only time anyone talks about "mostly" or "nearly" open source is in the context of a company looking to get the marketing benefit of association, and maybe some people to do some free contributions for them, without being bound by the social contract at the heart of the FOSS values. But maybe that's just me.
> To lay claim on not just the phrase "Open Source" but the very adverb "Open" is not just historically incorrect but also hugely unreasonable.
So this is my bad, I should have been clearer. When I said "'but-for-one' is not open by definition,", I meant in the context of FOSS, and specifically the definitions the OSI maintains. "But-for-one" violates criteria #5 & #6.
And yes, the word "open" has existed for a long time, but that's sort of why the OSI standardized the term. This has been a solved problem for decades, and efforts to dilute what it means are only ever looked upon with extreme skepticism.
If people think the OSI definition is bad or incomplete, then that's an argument worth having out in the open. But that's not what I see.
What's the advantage of these "semi" almost but not all the way open licenses?
> You can apt/pip/npm etc install and integrate pieces written by others in your own solution stack without having to call a lawyer. These non-open source licenses force you to stop and think, ask your lawyer before you build on top of them.
Try doing that with AGPL, or even just the GPL, or CDDL, or any number of licenses. There's tons of OSD/Four Freedoms compliant licenses that come with conditions; you really do need to look at them and can't "just" do whatever and already need to think about it.
And personally I really have trouble especially with the GPL licenses; try reading them and determining what exactly they mandate in various edge cases. We have tons of people clarifying all this (which may or may not be applicable to your situation/jurisdiction), but going on just the license is often very non-obvious.
> What's the advantage of these "semi" almost but not all the way open licenses?
I can fix bugs for starters. From a purely pragmatic point of view this kind of "I can fix my own problems" is >95% of the value for me.
I can easily self-host (including some hacked-up version which addresses some specific needs).
I can see what the code does if something is unclear.
There's tons of advantages. The only limitation is "don't compete with us". There's probably a few edge-cases, but practically speaking almost everyone is unaffected and they can treat Sentry as "just MIT" (or Apache) for almost all practical intents and purposes. People talk as if there are all sorts of caveats and booby traps here, but there aren't.
Re: GPL, the license is 30 years old, it (used to be) well understood and has an extensive FAQ. It has 2 main flaws: it's unappealing to SilVal VCs and ostracized by big tech. And it's promoted with one single-minded organization. Both things made it unpopular in the past 10 years and it became suddenly obscure.
Re: shareware/shared source code owned by a single corporation. History shows that the possibility to fix bugs locally is only a theory. None of the projects using that license scheme still does or exists. Think Eucalyptus, read their conflict with NASA and how that led to OpenStack. At best, you will have to maintain your fork.
The proper place to find ways leading to a sustainable business is not creating new licenses but iteration on business practices.
But latent bugs are discovered at a rate that is roughly proportional to use, and for application software running under general purpose operating systems on personal computers or servers the operating systems and hardware gets updates which can cause problems for applications.
That imposes a maintenance and repair burden if you want to keep applications working that is very similar to the burden imposed by wear and degradation when you want to eep some physical thing running.
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 authors bork the product and after two years it becomes clear they won’t fix their ways, I can fork the old product code I liked and develop it into the product I want. Heck if I’m right and my idea is better than the original I’ll eat their lunch too.
Big iron UNIX would keep going and cherry picking from the BSDs as it had done until the lawsuit took place.
It is no surprise that all new FOSS OSes for IoT, none of them embrace copyleft licenses.
I know that AWS made a blatant hosted version of Elasticsearch without contributing back but the other examples are less damning.
Azure's MongoDB offering is just the MongoDB API on top of their own document-oriented storage and querying architecture. Their globally scalable Redis offering is most likely also their own implementation and only using the same API as Redis.
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.
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.
> 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.
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.
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.
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.
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.
> 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.
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.
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 be forked and someone else will add the fixes that the devs weren't. But this is also potentially a negative as it inventiveness regularly breaking compatibility with old versions.
I don't see any benefit to the developer using this license except that it makes them feel like they are doing open source. A better approach would just be to accept public contributions under a closed, source-available licence. Or, better still, just offer separate personal and commercial licences.
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 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).
> I don't see any benefit to the developer using this license except that it makes them feel like they are doing open source.
Is there really a need for this amount of negativity/scepticism?
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 trying to have their cake and eat it too. Also, I don't see what's to stop someone free-loading off a two-year-old copy of your work.
Why not? I mean you're literally arguing against the business decision we are making. We believe in Open Source, we believe in funding Open Source, we are trying to find a balance that is possible to walk for a SaaS business. I'm surprised people generally take the binary view that "either Open Source with no protection or go proprietary completely".
> Also, I don't see what's to stop someone free-loading off a two-year-old copy of your work.
Nothing, you can do that!
But you don't believe in it enough to do it.
> I'm surprised people generally take the binary view that either Open Source with no protection or go proprietary completely
Because FOSS is about community contributions. People contribute to something owned by the community for the good of the community. Yet here you have claimed the near-exclusive right to profit from the code. FOSS is saying that you expect some of your users to contribute to your code, so you are effectively saying: "contribute to my code for my benefit, and I might let you use it in some circumstances" which is antithetical to the FOSS saying "contribute to public code for public benefit".
> Nothing, you can do that!
Then why not let people free-load of the current version? The answer is because you want to be the only ones who profit from this software. This license exists to keep you as the soul or primary beneficiary of the code for the duration of time you are developing it, unless you make a decision so fundamentally bad that people are willing to wait two years to fix it. I'd wager you don't think you'll make such a decision.
FOSS is explicitly about letting anyone do anything they want with your code, even if you don't like it[1].
[1] https://www.gnu.org/licenses/gpl-faq.html#NoMilitary
> More generally, a license that limits who can use a program, or for what, is not a free software license.
Absolutely not. This is never what it meant.
If you go back the Four Freedoms then it talks about "freedom to do with the software what I want", and certainly not about "software developed with a specific methodology" or "community contributions". The OSD says more or less the same, in a different way.
Ask Richard Stallman: I'm 100% convinced he will tell you the same. It has ALWAYS been about giving users freedom about their own computers, never about "the greater good of the community" of anything else.
The disagreement about the DSL is that the "use the software for any purpose"-freedom is breached. You can disagree if that's a big deal or not, and if that will or won't impede community contributions, but "you must accept community contributions" never played a part of that and never should play a part in that. I will quite literally take down every single one of my many free software projects if it ever becomes to mean that, and suspect many others will too.
On a personal level YOU may think that this is important, and that's fine. But that's something different. Usually I would take this as a "I care about this" and not be too pedantic about exact meaning of "Free Software" or whatnot, but you're incredibly fastidious about the "correct usage of FOSS" all over this thread, it's a hugely painful that your understanding of what it even means is just factually incorrect.
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.
Exactly. So they should stop pretending they're open source when this is really just source available as a sales decision. It's also bad for customers like you since you might be mislead into thinking they actually are open source, when in reality they do a lot to prevent any competing services which makes users much more locked-in than it might seem. If you want to switch, you'll either have to self-host if the issue is with their prices, or do 2 full years of development to implement your own version if they make a decision you don't like. It would probably be easier to switch to a competing service at that point, so you are just as locked into them as you are to anyone else.
It would be much better for you if they actually were open source because then you wouldn't be locked-in, and it would be at least a little better if they stopped lying about it.
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).
I don’t know how I feel about this. Or, okay, right now I feel that I’ll believe it when I see the old versions actually go open source for, say, several times the declared period. (The first BUSL versions of Sentry, from 2019, only started running out their timers a year ago.) Otherwise, I ... don’t think that, say, Stallman would call it evil? It’s certainly better than the other non-FOSS possibilities. And yet I feel absolutely no desire to contribute (to the non-FOSS versions) under such conditions, and I wouldn’t suggest others do so, either. So I don’t know if there’s a “bazaar” to have here, or if the “bazaar” should spend its efforts on such cases instead of going elsewhere.
You are, just not in a competing commercial service. For that you would have to wait for two years. Which is precisely the point. In a non commercial, self hosted setting you're free to incorporate these patches.
It’s just that for me the phrase “exclusivity period” would imply that you could compete as a provider of sufficiently-old versions. And technically you can, except the script kiddies will take you down in a heartbeat, and in that respect you’re in a very different world from the one the original developer was at that point in the past even if alternative offerings are ignored.
(Consequently, the original developer is not competing against old versions of their own software the same way as Microsoft used to be competing against old versions of Office or Apple is now competing against older Macbooks.)
I give you an analogy from the real world: MySQL was bought by Sun and then merged into Oracle. The original developers didn’t even like that direction and forked the project and build MariaDB. Some of the code they took was even older than the latest release. There can always be situations where a project withers for years and you get stuck with a license that impedes commercial revitalization. The FSL doesn’t come with that risk.
I have no interest in contributing to a code base that where my contributions wouldn’t be open source for two more years. You’ll find naive developers out there, but my free time won’t be spent contributing and my company would never allow me to contribute.
Some people choose to scratch their own itch and commit small bug fixes. For example, if you are running Sentry internally and you're monitoring a dozen software projects with ~50 users, it might be in your interest to fix some edge case you've hit that's causing your team grief. You could also open up a ticket on GitHub, or do nothing at all and just continue to use free software as-is without contribution.
It sounds like you aren't a user and have very little incentive to contribute. So I agree, don't!
So your company would rather spend significantly more time and effort to work around problems? Because that is what 100% closed source usually means: "I found some problem, the vendor can't be arsed to fix it, the solution probably isn't too complex, and now I need to do some complex stuff to work around it".
Their product isn't Free Soft anymore. They feel that they can increase revenue with a more restrictive license, a business move that doesn't require this cathedral and bazaar white washing.
We also don’t ask you to build our software for us, and instead give it away for free.
In Czechia "release" is a legal act done by author(or right holder). You can do it by uploading code on Github etc.. But it is something author did themselfs.
You can not perform legal act (releasing) with extra conditions like a delay. Either you did it or not!
For the same reason you can not put extra conditions in Last Will (house is yours, but you have to take care of my cats). That part is simply not enforceable and gets ignored by notary!
So I am worried, clause about Apache license is invalid, and software may get forever stuck under less permisive license!
There are definitely fundamental legal questions in Open Source licenses that differ from country to country, but you're most likely incorrect that a delay cannot happen in Czechia. Delays in (non software) licenses are very common and have been held up in courts. In fact, that's the common case of many licenses that they hare different rights associated over time.
> For the same reason you can not put extra conditions in Last Will
I doubt that whatever regulates wills restricts contracts or licenses.
But the way it is written, it changes existing license! Effectively making a new release! You can not do that in EU, what if user does not agree with the new licence? It is quite illegal in most EU countries!
You can not swap licenses like that! Many scammers do that, and there are strong pro-consumer laws to prevent that!
What is worse, it even terminates old license after two years! Really really stupid lawyer worked on this!
Here is the text:
> On the second anniversary of the date we make the Software available, the Software will become available under the Apache 2.0 license. On that date, the Terms and Conditions above automatically terminate and the following terms become effective:
It is not illegal as the license terms are available from the start. The text of the license effectively changes. If you do not agree with what the license looks like after two years, you should not enter into that agreement in year zero.
> Many scammers do that, and there are strong pro-consumer laws to prevent that!
Consumer laws are largely based on the idea that you cannot take away people's rights, you can generally add rights. Even if there was a hypothetical case that you mention, it would be legally absurd in the FSL case. You could have the license swap over in the US, after which point in time no trace of the FSL remains and the license file can be legally swapped. In that case you can re-import the source code into your country.
- You started using product
- One year latter ASF stops existing, apache.org returns 404 or viagra ads.
- Two years latter, original FSL gets terminated, your new license for that software are 404 errors or viagra ads. You now have no license and should stop distribution!
Think what you want, software under FSL is on my ban list.
More importantly if you want to make a fork you can always retain that license the moment you fork, not the moment the license swaps. In fact you probably would want to start collecting contributions under Apache 2 straightaway.
With the economic situation how it is I think we will see a lot of these sorts of things shake out as our current direction is unsustainable.
If I write software I can release it how I want. I can release it as gpl. If someone approaches me wanting a closed source version I can do that.
If I submit a patch to the Linux kernel I can also give that patch to Microsoft to put in Windows.
The closed code isn't 'based on' Apache code. The copyright holders have released the older code as Apache.
The original author would retain copyright and they alone could make that software available under another license (eg: dual licensing) but nobody else would be in that position.
I release software X under license that turns to Y license after z years.
I am free to take exactly the same code and do the same at a later date.
Or are you referring to code by a second submitter where their code goes gpl, but then you need to re get their permission to restart the clock.
I still think you could work around that if the license is structured correctly.
Treat the source tree as it stands at a point in time as a release that becomes open source 2 years later, but keep the core project closed.
So all code in the project is always available to be in the project.
If I release software under the gpl and to someone to integrate in a closed source application. You don't have gpl code in a closed source application. You have code with 2 licenses.
This is perfectly ok, the two pieces of software can coexist.
This would be the same, if correctly structured.
The only nit would be that code would be forever dual licenced. Some evil company could buy up the code base and do whatever they want and not release code back for 2 years.
Are they so unable to compete in their space that merely copying and hosting a current version is a substantial threat (even if modifications are shared)?
With either Sentry’s FSL license or FOSS, you as a user can run your own. If you want a paid managed service, you can pay Sentry. With FOSS, there can be competitors who offer such service using the same exact up-to-date version, and undercut Sentry on price (since they aren't paying developers). With FSL, they’d have to run a 2-year old version. That’s a disincentive to competitors.
BUT: even with FOSS, a similar disincentive exists, because the maker of the FOSS software could decide to change license, forcing competitors to run a stale version or invest into their own development, or pay up for licensing.
Seems if you are small enough, pure FOSS is better for this reason (the option to release future changes under a different license is always there). But if you are big enough to have competitors, and you can’t convince enough competitors to pay or revenue share (e.g. through support agreements), then FSL can be a way to twist their arms without hurting most other users too much. (It does hurt to some extent, as the many arguments in this discussion point out.)
For the record I don't care what qualifies as open source, as that is a commercialized term and thus will lean toward permissive or permissive + trademark stuff like the MPL and Apache licenses.
It seems the best way to build libre software, from my perspective, is through the AGPL. Compliance is as easy as providing a link to the repository of code you use to provide the service.
If a license like FSL catches on, what stops modified licenses from cropping up with extended expiry terms? Before you know it, a SaaS suddenly needs 5, no... 10 years before it becomes profitable! Because we should care about profit in a bazaar or a community...
As well-meaning as these efforts are to help developers find more sustainable means of developing, I don't think this is going to help. Security patches in the community-friendly code will be 2 years behind, guaranteed. People who can't pay for the latest version will have to use an old version which might be broken.
We need to come to terms with the idea that capitalism and volunteering can't easily coexist. The incentives and goals of business are opposite that of libre software development. Libre software seeks to enable everyone regardless of their assets.
By all means, solicit ways to incentivize your work in libre software. Relicense if you must, but I will steer clear of this license like the plague. It is not compatible with software freedom until its expiry date occurs, and even then it's questionable and hard to trust.
I care about software freedom but ultimately decided that I wasn't going to spend my time on something where other people participating couldn't respect me, or acknowledge and appreciate my contributions. I've been on both sides of that relationship and I know how it should be done, but few ever reciprocated when I tried to be cordial.
https://drewdevault.com/2021/01/20/FOSS-is-to-surrender-your...
Apache is the same org that actively harms one of the highest visibility open source projects by keeping "Open Office" around. Their licenses are similarly unwelcome IMO.
I'm confused about your concern then if v3+ is preferred. Apache 2 is compatible with the GPL 3 family of licenses, it's just not compatible with the GPL 2 family of licenses. The only incompatibility of Apache 2 are GPLv2 licenses, but so is GPL 3.
Apache 2 has some benefits to the user over MIT, but the GPL incompatibility is why there are two flavors of FSL.
The idea being that "you may use this software under the terms of ${license} or under the terms of the GPL" means there's absolutely no question as to GPL compatibility for the people who value that, and you can pick the value of $license to taste (I use the same license as perl for CPAN releases, but for other languages using whichever is the most popular permissive license you like in that ecosystem is likely a good answer).
I note downthread you have reasons why you can't do that with the GPL, and it might be worth having an explanation of that written up somewhere findable given that honestly hadn't occurred to me so I may not be the only one, but I figure disjunctions are still worth mentioning as a general tool even if not applicable in your case.
I doubt that. I'm not even sure the MIT license is compatible with GPL because it requires the notice be kept intact, which might be considered an additional condition if the code is merged with GPL licensed code. Apache 2 and GPL 3 might be compatible in spirit, but I doubt they are compatible to the point you can pull some Apache code into a GPL3 project and drop the text of the Apache license. Also, if it is essentially the same terms then there is NO reason to actually have a different license and it just confuses things.
IMHO we actually need a new "do whatever you want" license besides MIT and BSD that make zero conditions on derived works or their inclusion of any particular license text. OTOH that would seem to imply you could claim the code as your own in the derived work (and then try to sue people using other legit forks for example).
> > 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.
> > my theory about embrace/extend/extinguish seems to be as accurate as I thought.
> This is confused. Embrace/extend/extinguish means to initially participate in an open standard and then extend the standard in such a way that the non-extended version is sidelined.
I'd encourage people to read the entire thread rather than seize on the cherry-picked comment, additionally loaded with terminology like "they want to destroy open source", which doesn't appear in the original thread.
I can't speak for whit537, but I do work at Sentry, and I feel your comments about our intentions are disingenuous. We are open in that we feel the existing models don't fit our needs, and we're trying to evolve the language to make non-compete licenses more approachable and thus more mainstream. That doesn't mean an elimination of existing popular OSS licenses. We're even explicit in saying, "FSL is for SaaS businesses". That's pretty narrow, and probably excludes 99% of software.
Note that the FSL is developed in the public, and echoes the language I've used above[1]. But if you believe pursuing additional licensing mechanisms means we're destroying OSS, there is probably little I can do to disavow you of that notion.
Speaking of disingenuous, every time the sentry people come in here to talk it's always strawmen. My issue is with sentry trying to redefine open source, not your creation of new licenses. If you want to put out proprietary or shared source licenses I'm cool with that, but when you try to mislead people into thinking those licenses are open source I think you're crossing a line. Your head of open source himself said he wants to redefine open source in a way that restricts how people can use software. That is the issue.
Good that I'm not the only one who feels that way. Every comment by Sentry people I've read here so far was basically a mix of straw man, word lawyering ("We didn't say this. We said something that means the same to anyone who doesn't actively try to think of some fringe interpretation, but OBVIOUSLY that means you misquoted us. How unfair.") and aggressive "you are against us! Meanie!"
Or in other words, to use their quote back on them: If you are convinced your license is the best thing since sliced bread, there is probably little we can do to disavow you of that notion.
I don't think anyone in this thread has claimed that this license is the best thing since sliced bread, or even described it as "great". It is a license we have chosen to use that we think is good for us, and we think it has merit for similar SaaS businesses who choose to share their code as we do.
(If I'm mistaken and someone has claimed that, I am happy to be corrected.)
But: I still wish you the best. The sustainability crisis in open source is a real problem and I hold my fingers crossed for a good solution.
Let's not pretend the "feedback" on these types of things is generally less than stellar, and often quite toxic. Some people are convinced this is part of some dark and sinister plot and will use even the slightest hint to "prove" this. The dynamic here is not the easiest to navigate.
Here's what Armin wrote in the parent linked article:
> ... 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.