It's very hard for me to take anything which starts with CatB seriously. It was very charismatic, beating up a strawman which didn't exist, and zero of it played out as expected. Eric Raymond is mostly gone, as everything he's touched has failed. Open-source has started to realize Richard was right about ethics, as the two movements have increasingly converged. Richard, for his part, is still marginalized, socially awkward, and everything seems to be playing out by the playbook he wrote in the nineties.
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.
> 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
For what it's worth, your writing is confused. For instance:
> 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.
> The entire point of this license is to prevent forks of software.
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.
I feel like one of us is fundamentally misunderstanding this license. 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. Had this license not been used there would be nothing preventing me from forking the software.
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.
> 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 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.
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 asking,
what change does it need to make it better?
> 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.
> 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.
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.
> Xapian under a hypothetical FSL would long have been able to commercialize it.
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.
> 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.
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 is such a niche case it's not really worth talking about, but the original devs still released it under GPL. The FSL is literally just the Apache license in this case. So you aren't arguing for the FSL, just that the original devs should have used Apache instead of GPL. That's just your opinion. If there was a version of the FSL that converted to GPL after two years, you'd have the exact same issue. The FSL portion of the licence is not relevant as no one was ever interested in releasing Xapian under a closed licence for a limited amount of time.
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.
> If there was a version of the FSL that converted to GPL after 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.
> I already explained elsewhere in this comment thread why.
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.
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.
> 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 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.
> 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. in a product or service that offers the same or substantially similar functionality to the Software.
(1) & (3) are highly subjective, and (2) attempts to assert a copyright claim over APIs (definitely doesn't work across most jurisdictions). No-one is going to seriously use this software with such a badly written and vague license.
(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).
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.
Copyright is about copying. For instance, if I buy a book, I cannot distribute copies of that book. But I can write whatever I want in the book, change any of the text in it, provided I don't then copy the modified text. They own the copyright to the intellectual property, not the physical item you are given or the bits in your computer's RAM, which you are free to do as you please with.
If you follow the link to the actual license, it does list done explicitly permitted uses. So yes, it does seem that you can fork it and do something useful with the fork.
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.
GPL doesn’t work in an environment that requires further restrictions or where the distributor doesn’t want to uphold it. For instance you won’t be able to put GPL code onto the App Store. The viral nature of the license also carries perceived business risk and harms adoption.
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.
> 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."
I suppose not much. So the licence does succeed in forcing software to go open source after two years, but before that, it still effectively forces the maintainers of forks to put in an equal amount of effort to the holder of the licence. This makes a fork much harder since it would require a development team equal in size to the official one two years to bring it up to date.
That’s only if you care about the same additions that the original developers do. However, a fork is usually motivated by a disagreement on the trajectory. Or you don’t actually want to fork, but only want to monetize their work SaaS-style, which is exactly what the FSL is intended to prevent.
> 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 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.
It's very hard to read your comment and take anything away but a "holier-than-thou" attitude. 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.
> It's very hard to read your comment and take anything away but a "holier-than-thou" attitude.
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.
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.)
> The Business Source Licence (aka BSL, or sometimes BUSL for some reason)
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.
You and Symbiote are technically correct, what I'm suggesting wouldn't match The Open Source Definition [1]. But being "correct" matters little to me, what matters is promotion of the idea & usage of free software.
> 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.
> what matters is promotion of the idea & usage of 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]
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.”
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.
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.
This. I'm not sure why it's so difficult for people to grasp that open source in of itself is not a business model. It can make money sure, but for the most part that's neither guaranteed or likely. If anyone can take your code and resell it as a competitor or use it for free, then by definition you're not going to be able to monetise the way traditional software businesses can.
All the attempts to block large 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.
The idea of the source being available but software not being “free” is fine by me.
I want the source so I can fix bugs instantly instead of trying to convince some mid-tier product manager having gone through 5 tiers of support. That is a huge benefit over source-unavailable proprietary software, or (heaven help us) SAAS.
"I could fix it myself if needed" quite often comes up on HN and other programmer forums but I honestly have to wonder how many people could actually fix deep issues in production grade software. For example, there are plenty of bugs open on the issue trackers of (say) postgres or kubernetes yet despite the source of those being available I'm willing to bet a vanishingly small amount of users would be willing or capable to dive in and fix the issue themselves.
Yeah, happens quite a bit. Also just being able to dig and figure out why something is doing a weird thing happens all the time. I’d say about once a month in my team of three people, and we’re not even doing fancy stuff.
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.
I rarely fix bugs in my dependencies, but I have found having the source available to be very useful in working around bugs in them. It's frequently the difference between a workaround that appears to work but I don't know why and might just cause different problems and a workaround that I know is correct.
It depends what the software is of course, but I've definitely fixed issues in a not unreasonable amount of time that in some cases would not even have been within the terms of any support contract (and would certainly have taken a tier 1 or tier 2 vendor application support an unacceptably long amount of time to do the same, assuming they didn't just close the ticket as unsupported use case).
Would I be able to do that for the Linux kernel? Of course not. But the vast majority of software out there is nowhere close to that level of complexity. And there are specialized groups that are trustworthy that we pay enormous sums to handle that and have had good experiences with.
So it depends but it's definitely a selling point of open source for a lot of systems engineering and adjacent roles that need to glue together lots of disparate pieces of software in sometimes unusual and unsupported ways, and sometimes for platforms that are not technically supported, or that the vendor is not able to establish any confidence in us that they will be able to support it competently for the next 10+ years for any number of reasons. That often requires forking the codebase.
To summarize, as someone essentially in the business of insuring for fortune 500s that aren't software vendors against startups and other companies deemed non-trustworthy or risky in some other way...the vast majority of YC style companies inevitably fall into the category of company where their software would not pass risk management processes for enterprise wide deployment without a proper open source license. A lot of that is down to regulatory requirements as well. It isn't some sort of irrational FAANG company "not developed here" ego boost.
For those of you that are new to the startup world, or weren't around back in the before times of the 60s-around about the mid 2000s up until the financial crisis, this may not make much sense. But it's very much the case that this ecosystem of software startups would not exist in any significant way if it had not gone all in on open source. I'm not sure how I feel about that morally or ethically but its something to think about when you are deciding how to license your software.
As far as these weird source available licenses go...it's an option but it's risky. Those familiar with the history of computing will know that the old mainframe OS's and commercial Unix's were both once source available and that ended up burning a lot of people when they started to restrict access to the source (a lot of our companies had and still maintain custom operating system modifications to legacy platforms from back in those days). The institutional memory of source available licenses (or in the case of MVS, no concept of software licensing at all) being used to turn the screws on customers is still very raw in the much slower moving world of traditional industries. Enshitification is not a new idea, some industries have been through multiple cycles of that process and have developed defense mechanisms.
And there's nothing wrong with that, it's just not open source. It's source visible/available software, which has been a thing for ages. Old school forum scripts like vBulletin, Invision Power Board, XenForo and WoltLab run on this very model. As does about 90% of proprietary CMS software in general.
The problem is that a lot of companies seem to want to have their cake and eat it; they want the public contributions and kudos from making open source software, while treating it like proprietary software where the source is (maybe) available to end users.
What Sentry objects to is people setting up "super-error-reporting.com" with an unmodified copy of the Sentry software without contributing anything back, which undercuts their SaaS business model.
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.
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.
> The phrase you quoted "harmful freeloaders" does not appear in any of our texts.
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.
Would you mind explaining why you have a problem with a clause stating "use our product however you wish, as long as it is not to compete with us"? It sounds reasonable to me and the opposite which you are defending sounds unsustainable and harmful to the open source ecosystem.
(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.)
The free software movement generally believes that software exists only to solve problems for its users. The creator of a piece of software has no moral rights to profit it from it more than any other user. Richard Stallman doesn't complain that Linus Torvalds used the GNU userspace tools to outocompete HURD out of existence.
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.
In brief: "use our product however you wish, as long as it is not to compete with us" doesn't define "us" (you now, or for all perpetuity? What if you get bought by a large litigious-happy database vendor?) or "compete" (same market segment? Geographical area? Product type? Specific use-case?).
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 think you're right to assert bad faith. Look at Sentry's track record allowing users to self-host, and this as a step that makes their work more permissive than what they previously had (for example, the shorter duration).
I don't challenge that the license may have shortcomings, but I think better evidence is needed before bad faith can be asserted.
You may be right, I may be wrong. I just find it difficult to look at a phrase in a license which has been deliberately crafted to be intentionally vague as being anything else.
The people we're concerned about are not the hundreds of thousands of Sentry users, including those that self-host.
We're concerned about people who have taken the software for the purposes of competing directly against us, that hinders our ability to monetize the work. Monetizing the work helps us continue improving the software and distribute it for free use, benefitting those aforementioned real users (e.g. https://github.com/getsentry/self-hosted).
I think folks need to take a step back from 'business model' and think about how one does large scale FOSS w/out existing on ramen for a decade or two. In the old days you could do FOSS via university gigs (IE, an institution effectively donating resources) or work for a corp that uses said FOSS as part of their products.
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?
A few days ago there was a story about some lady creating a new kind of coat-hanger that you can fold so it takes up less space.[1] Pretty simple idea once you see the finished product, but getting all the details right so it actually works well isn't always easy, and it took her about three years(!) Presumably she wasn't working on it full-time for 3 years, but clearly a lot of effort went in to this "simple" idea.
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".
I know lots of people here don't have a lot of love for patents
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.
Sentry was already using BUSL (Business Source License) for 4+ years with a non-competitive Additional Use Grant. So we had already been doing this for a long time.
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.
So why don't you switch to a fully progressive license? What you're saying here is "we're putting our competitors at slightly less of a disadvantage, and that's good", so why not release under a free license and not put your competitors at any disadvantage? Either you want competition or you don't. What's offensive about this to some people is that you're trying to have the best of both worlds. Pretend that you welcome competition while still suppressing it. I don't think there's anything wrong with you not giving competitors your source code, but I'd rather you were honest about it instead of using this silly half-measure.
> Why don't you switch to a fully progressive license?
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.
We welcome you to spend 15 years and 10s of millions of your own money to compete with us, by writing your own software. If you think taking someone else’s software and spending ad money to sell it is “competition” I don’t know what to tell you.
Did you even read what I wrote? I said that I don't think they need to give people access to their software. That it might even be unfair to expect them to do so. But if they don't do it, they can't call themselves FOSS. It would be unfair to expect a restaurant to sell everything at a 50% discount, but if they said they were doing that and it turned out they weren't, I'd have every right to complain.
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.
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.
> 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.
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.
1. Then call yourself "mostly open source" instead of "open source"
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/.
Sentry releases a large variety of software. Some of it is licensed under OSS (which, yes, I will be pedantic about, because OSS is one less character than FOSS, and I do not believe in copyleft).
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.
> Is the messaging on that URL you found misleading? Yes, and we will improve upon that
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".
well, for most intents and purposes they are interchangeable. there are very few Open Source licenses that can't also be considered Free Software licenses. at worst they are the same in spirit but incompatible for some technicality. or they are much more open, but compatible, so i don't think it is fair to argue that the difference matters.
To claim that the FSL and Sentry is completely disconnected from FOSS and something different entirely that should never under any shape be associated with it is, quite frankly, just weird. It's "almost FOSS" and they're quite upfront about that, more so than they really need to be. You can decide if you care about that or not, but it's just not misleading under any sort of reasonable definition. This is a profoundly silly and frankly toxic hill to die on.
Imagine if you had donated to a "charitably minded" organisation, then later discovered that they were only an "almost charity". I don't think you would be pleased with that. This is how someone donating their time and code to FSL projects might feel. They are not "quite upfront" about the fact that they aren't FOSS [1].
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.
"Open source" is not a charity and you don't donate to Sentry. People have come out of Guantanamo Bay less tortured than that analogy.
> 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.
Go to this link https://open.sentry.io/ and explain how it is made clear that Sentry isn't actually open source. You can't. No amount of good faith turns "We're Open Source and we don't feel the need to qualify that statement" into "we aren't open source but we'd like to be close to". They are even directly asking in that page for help (for people to volunteer their time). The title of that page is a lie and they make no attempt to clarify it. I can't think of any good faith reason why they wouldn't just write "We're Source Available" since that is a more accurate description of what they are and they've been repeatedly told this. It's obviously less misleading not to over promise when you don't actually know the truth of the matter. The only justifications I can imagine for that title are that they either don't understand that they aren't open source, or that they want to appear open source to attract customers. Given they've had it explained to them repeatedly and even members of their company admit in this thread admit that they aren't open source (but claim they don't say that they are which is a lie) and that the page in question is advertising their product, I can only conclude the latter justification. That they are doing this to move product rather than to inform 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.
Thank you. I hope to see this quickly amended to reflect that your software is source-available. I would also advise that you are very careful around this in the future. As you can see, I and many other developers are very passionate about this topic and any perceived miscommunication could be disastrous for Sentry's reputation.
If you explain how I've been in bad faith here, I'd be willing to rectify that. You asked a question and I gave you a pretty straight answer. I just can't see why you'd talk about FOSS so much if you really "want no part of that toxicity".
I also don't think it's bad faith to say that your decisions were motivated by selling your product. That's a perfectly reasonable motivation. I don't think it's bad faith to say you are misleading people, I never implied that you wanted to. You literally said a few replies ago that you thought I had been mislead into thinking you called yourself FOSS when you didn't. Maybe I am just stupid, but I don't think it takes and idiot to read "open source-minded company" and conclude that you are doing something open source. (In fact, wouldn't it be bad faith to assume that I was lying about what you've said rather than just mistaken?)
I don’t feel “given you already have a proprietary license, why wouldn’t you just make it freely permissive” needs much explaining. We develop the software; the exclusivity period helps us monetize the work (vs giving it away to someone else who would).
I think it’s worth reading the announcement from 2019 when Sentry first switched to BUSL. The original article links to many such pieces.
So, you don't want to competition from large cloud providers, but you also want your source to be available to users, and you want to give them a guarantee that the software will not simply die once you stop maintaining it.
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.
> 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.)
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.
There's an issue about size here too. When you are a small tech company there is a very real risk you will not exist in one-year.
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.
> If your business model relies on no-one else using your software to compete with you, don't open-source the software.
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.
Open Source is what allows developers to make their choices without having to ask for permissions. 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.
What's the advantage of these "semi" almost but not all the way open licenses?
I mentioned apt, pip etc because Sentry, Elastic and everything is built by integrating hundreds of packages. Nobody builds 100% of the code they ship to users and customers. These non-open source licenses make things like pip impossible to exist. This is why people and organizations familiar with Open Source react so vehemently against them.
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.
These things aren't in apt (other than non-free repos), so that's not really a problem. I'm not sure about the pip and npm policy on these types of things, but Sentry isn't a library you would add, so it's not really a problem. But it's fine to keep Sentry out of pip as far as I'm concerned.
> 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.
> So you would rather have completely closed source instead of Open Source-but-for-one -detail?
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.
Pretty much everyone I know in the industry uses the definition of "open" defined by the OSI, in relation to "open source": https://opensource.org/
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".
> You can't be "a little bit open source". You are or you aren't.
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.
> 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%.
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.
> 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.
I wish the article had spelled this out a little better, but the reason many businesses have open source licenses for their software is to assuage their customers’ concerns about lock in and permanence (will your startup be around later? Will you jack up the price? Don’t worry, it’s open source). The downside, of course, is that it’s harder to sell stuff if it’s also available for free. I believe the theory here is that this license promises to open later to fix the lock in fear, but is closed now to create scarcity. So under its logic, it’s different from simply switching to Apache later because it’s the promise that’s doing the heavy lifting.
I’m not sure it’s actually a good idea, just that I think I understand the intended logic of it.
I think the direction of your comment is right, with two caveats:
> 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.
> Software doesn't wear out, or degrade through use. The analogies offered to other, physical common services are nonsensical.
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.
>AWS, azure etc just eat their lunch and don’t help anybody
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.
No it isn't. 2 years is very recent in most software ecosystems. Even in the JS world it is really very recent, depending on the software. E.g. 2 year old Bootstrap is perfectly fine.
2 years seems hilariously short for me. If AWS want to rip this off they'll be very happy to use code that is only 2 years old to do it. Or fork a 2 year old version and reimplement only 2 years of work.
4 years makes way more sense, and even that is quite generous IMO.
I might be missing something here, but this doesn't seem compatible with the bazaar model at all. You say
> It also enables contributions by the community for the latest version and not old source code.
But you will not be able to accept such contributions without an additional license, because you yourself would be unable to use them for a Competing Use (running your service). This makes it much closer to a cathedral, with a "small bands of mages working in splendid isolation". Sure, your work will be publicly visible, but that's it.
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.
When the head of open source was explicitly asked about whether they're trying to redefine open source his response made it very clear that they are-
> > your end goal is to exclude commercial reuse from the open source definition
> This is fairly accurate, though there are a range of possible outcomes we would be satisfied with.
Anything they say should be considered with that in mind. These are not good actors in the industry, but are people who are trying to replace open source software with a shared source version. Unlike other companies, such as Hashicorp, who admit that their software is no longer open source Sentry wants to have their cake and eat it too.
> but are people who are trying to replace open source software with a shared source version
Note that the thread you link to is a situation where they took an entirely closed source product, CodeCov, and made it source available under BUSL (and now FSL).
> Unlike other companies, such as Hashicorp, who admit that their software is no longer open source Sentry wants to have their cake and eat it too.
From the parent article (FSL: A License for the Bazaar, Not the Cathedral):
> But one thing is clear: until its expiration, the license does not qualify as Open Source. While I recognize the sensitivity around the term “Open Source”, I assert that the FSL's approach is more closely aligned with Open Source ideals than mere source availability. I consider it an “Eventually Open Source” license, though perhaps a more fitting term needs to be found.
That's some real deflection. While the overall thread was certainly about CodeCov, the questions I asked your head of open source where very clear and not tied to that specific case, and their responses were as well.
I do admit it's nice hearing that the Director of Engineering at Sentry has a higher standard for what is or isn't open source software, and I hope that attitude spreads to the rest of the company. I still think that everything that Sentry does in and around the Open Source community should be seen through the lens of what the Sentry Head of Open Source has directly said, and through the actions and statements of Sentry outside of that.
I don’t feel it’s deflection because Armin is the creator of Flask, a founding engineer, and our Principal Architect. He additionally is a member Sentry’s senior engineering/product leadership, and a key contributor to our licensing efforts. It’s his blog and his personal comments, and we are not a monolith, but I feel his statements are a good reflection of our values. Mine at least. (Disclosure: I’m also a part of this group.)
The Head of Open Source has followed up on the Codecov conversation and expanded on those comments [1]. I earnestly hope you’ll weigh these official comms higher than an HN comment.
Even in that blog post, where you get so close, you do this-
> We want to be able to continue to develop Sentry and Codecov as single source Open Source projects
You're stilling calling it "Open Source", but are calling it "Single Source Open Source" as if that's some distinguisher. You're even lower casing the "single source" part to try to emphasis the Open Source part of it.
Your team spends paragraphs admitting it's not open source, all to just continue using open source to describe your projects. It does so in "official comms". You guys should just come up with a better name for this already and stop trying to claim software that isn't open source is open source.
> But you will not be able to accept such contributions without an additional license
Without going into us, many open source projects do that. If you submit code to the Python Software Foundation you also give it under an additional license than what ends up on people's computers. That's a pretty common situation in plenty of Open Source projects already, particularly if they want to remove license restrictions in the future.
For us in particular we also specifically do not pick the FSL in situations where we believe the utility is so great, that we want to enable further collaboration. All our SDKs for instance are BSD/MIT/Apache2 licensed (depending on the SDK). Our most precious internal library for symbolication including the service are not FSL licensed, despite the fact that I know some of our competition uses it and don't give back. Because we believe that collaboration here is for the benefit of everybody.
> This makes it much closer to a cathedral, with a "small bands of mages working in splendid isolation".
We are not mages in isolation, we build in the open. Every commit is deployable, every commit is runnable.
There could be a contributor licensing agreement in place that effectively transfers copyright. But yeah, this is a potentially sticky point. It's inherent to the license that one party is special
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 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.
> Anyone trying to develop open source with this will be stuck two years behind the official release and so it won't be worth trying.
Only if you're a direct SaaS competitor. In that case, you'll have to diverge based on two year old code, which seems fair to me. (And you're always free to start your own project, if you want to compete...)
> I don't get how it solves that freeloader problem either.
Because 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?
> Because freeloading competitors are stuck with two year old code, putting them at a disadvantage, or compelling then to invest in that old code (some of which might find its way into the original branch).
This makes no sense though. If you don't want competition, why give your source away? If you do want competition, why put it at a disadvantage? That's why I am so negative about this license. It's just someone 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.
> If you don't want competition, why give your source away?
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.
> 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].
> Because FOSS is about community contributions. People contribute to something owned by the community for the good of the community.
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.
> If you don't want competition, why give your source away?
Of course they don't want competition, but what they do want is customers like me, who will never voluntarily choose to become fully dependent on a single third party for anything remotely important.
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.
> 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).
I don’t think it’s reasonable to call it a “two-year exclusivity period”—it’s more like a two-year dead man’s switch. As long as the original SaaS is relevant you are never competing with it, because you won’t be able to reuse any security fixes that the original developer made. Unless, of course, you are Amazon or Oracle, and can afford an independent security team.
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.
> because you won’t be able to reuse any security fixes that the original developer made
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.
That’s why I said “competing” and not “using”, yes.
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.)
> 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.
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.
You can always clean-room reverse engineer it. Or you can look yourself for 0-days in the released version, and develop simultaneously the fix for the closed and the open source version. You just have to be creative.
> It also enables contributions by the community for the latest version and not old source code.
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.
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".
There are many people who use the software, for free, to monitor their own non-competing software projects (it turns out that overwhelmingly most people aren't competing with Sentry).
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!
I wish Sentry would stop free riding on Free Software movement by pretending their product is part of 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.
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!
> You can not perform legal act (releasing) with extra conditions like a delay. Either you did it or not!
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.
Yes, they could put extra paragraphs that become valid after 2 years, that would be OK.
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:
> But the way it is written, it changes existing license! 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!
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.
- 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.
That’s a purely hypothetical situation. Even in that case a court would very likely uphold the license just by the name. For what it’s worth plenty of software is only referencing a license by name or reference and I’m sure you are using that software as if that license were there in hardcopy.
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.
While I am not entirely persuaded the specifics of this license are correct it does seem to be a potential improvement over the status quo and so it is good that it is being tried.
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.
SQLite is the first thing that comes to my mind when I think about "cathedral" projects, but apparently it's not truly "cathedral" in the original meaning ("…with no beta to be released before its time", while SQLite is built in the open, albeit by a few people).
Doesn't the license conflict with itself? The "not-yet-Apache-licensed" code is obviously derived from the "now-Apache-licensed" code, thus it must be "Apache-licensed" too.
Apache 2 is not copyleft: derived works of Apache-licensed software can be distributed under more restrictive terms as long as all the acknowledgments, etc., required by the original are still in place.
That is true in principle but not how the FSL functions. The FSL ceases to exists at the two year anniversary and turns into another license (eg: Apache 2). If it were to turn into GPL the before and after code pieces would not be compatible.
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.
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.
A today FSL artifact is an amalgamation of Apache/MIT licensed stuff and FSL licensed stuff. This amalgamation would not be possible with GPL per the GPLs license terms.
Why doesn't Sentry simply use AGPL instead of this 2-year BSL?
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)?
It makes sense for a successful product that’s being hurt by competitors packaging it up and selling as a paid service. My advice: for a younger product, keep it actually open-source (FOSS).
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.)
How is the FSL any different than tiered, expiring copyright terms? This is a step backwards for libre software. It's like a mix between copyright and patent, in the sense that the monopoly (patent) expires after a given point, but you're still bound by license terms that are less permissive than they should be to be libre software.
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.
Please stop using the Apache licenses. License compatibility is too important. Use MIT (my preference) or BSD if you want a "permissive" one and GPL or LGPL otherwise (v3+ preferred). Anything else is just making non-reusable code.
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.
>> Apache 2 is compatible with the GPL 3 family of licenses, it's just not compatible with the GPL 2 family of licenses.
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).
This sort of discussion is what leads me to be fond of license disjunctions - perl's use of Artistic|GPL being the one I'm most familiar with.
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.
As a reminder, the head of open source for Sentry came into hacker news and explicitly said he wants to destroy the existing definition of open source and replace it with one that is VC/Corporate friendly.
> > 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.
It feels like you intentionally omitted his immediate follow-up to your quoted comment:
> > 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.
> 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.
> when you try to mislead people into thinking those licenses are open source I think you're crossing a line.
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.
> Speaking of disingenuous, every time the sentry people come in here to talk it's always strawmen.
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.
> 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.)
Let me rephrase it a bit less aggressive, I think "disarming" the discussion is good: I understand the part that you think it works good for you (hey, why else would you use it?) and you hope it can help others. But the 'vibe' I get from your answers is very .. Stallman-y? And at least to me that's very off-putting.
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.
Most comments I've seen are just clarifications, and they're usually pointing towards a good-faith reading of what was said, rather than a "what evil plot for world domination does this hide?"-reading.
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.
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.