I'm really glad that they've made a conscious effort to be transparent in the fact that this is not open source. That said, I'm less sure how I feel about the movement as a whole. I admire the desire to make source code transparently available, and let people use it for free, but I think strict open source is the best net good for the world we live in. I can run apps on Linux in any cloud I want to because every cloud is free to run it. And so I benefit from getting to choose among competitors (including self hosting) where that doesn't exist in a world where competition is forbidden.
It's also ironic to me that this software is being built on top of git, and thus is a business model entirely dependent upon FOSS, while wanting to differentiate and build a business on top of it with a moat but still sharing the code in a way that protects them. It just seems like an uncomfortable position straddling the fence between two paradigms.
Maybe I'm privileged in the fact that I've always lived comfortably enough in my career to feel like I can write and release OSS under the most permissive terms (whether it's used or not). But that feels like the best way to give back to the movement that effectively led me into this career for free, and lets me pick from offerings that are forced to differentiate on price or other features rather than whether they can license the software.
If I'm using an open source product, I'm generally very happy to spend long hours debugging edge cases, writing detailed bug reports, pushing fixes, suggesting and adding enhancements and generally being involved in the community, knowing that I'm doing my share and improving the experience for everyone.
Nowadays it is increasingly likely that my effort is eventually going to be relicensed and repackaged into non-free software without my consent, and no one (not even me myself) will be allowed to continue to benefit from my work.
IMO the issue really lies with the VC funding model. Every single one of these projects that has done a license bait and switch has taken outside funding, and these investors want to see an exponential return, which simply cannot be attained by keeping the software free. Stewardship by a reputed open source foundation is the only possible future for such projects if they want to actually stay open and do right by their community.
> Nowadays it is increasingly likely that my effort is eventually going to be relicensed and repackaged into non-free software without my consent, and no one (not even me myself) will be allowed to continue to benefit from my work.
I disagree with the conclusion you have drawn here. In the scenario you describe, you (and everyone else) can continue to benefit from your work. The original project is still there, it's still just as useful and open as the day you made your contribution. How then is anyone prevented from continuing to benefit?
While true, I think the reality is that this is still being figured out in the legal system right now. Forks of redis and hashicorp products should be completely fine theoretically, but there's a lot of legal chaos right now with the owners of the BSL versions trying to figure out if/how to prosecute the open versions for adding similar features to the "source available" versions. I've heard contributors to the forks on popular podcasts having to say "I'm not sure I can comment on this right now" due to ongoing battles and legal advice.
I'd love it to be cut and dry fork-wise but there are parties with vested financial interests trying to keep the OSS forks frozen in time. If anything, "source available" is almost weaponized because if you've looked at the available source, it's tenuous. And if two implementations of the same feature look similar (as they will) it might not be as easy to convince a jury that it's not a copying of copyrighted now-unlicensed code.
> these investors want to see an exponential return
Don't think this is the reason, at least for Sentry. They've been in business for more than a decade.
The bigger reason is that it would take AWS 2 weeks to offer a version of their product. It would be API compatible because it would be exactly the same code. AWS would offer an introductory price of $0 for the first year. Not all Sentry customers would switch, but many would. Sentry would continue to develop their product, while AWS maintained a skeleton crew to deploy their changes and make most of the money off it.
While it may be easier to assume the worst of people, ascribing all kinds of intentions to them, just listen to them. They say "we don't want AWS to deploy our product and take all our customers". They say it because it's what they're really worried about.
Sentry raised $90 million in a series E round in May 2022, and their total funding is sitting at $217 million.
No cloud provider even offers a hosted version of Sentry, so it's not like that's an issue for their business. Spinning up a VM and deploying your own version is incredibly straightforward. Which is exactly why they now need to switch licenses and put newer features behind more restrictive terms so users are forced to pay.
> Which is exactly why they now need to switch licenses and put newer features behind more restrictive terms so users are forced to pay
Sentry switched to BUSL in 2019, almost 5 years ago.[1]
Most of the aforementioned fundraising occurred after the license change (e.g. the $90MM round you mention from 2022, and another $60MM round in 2021).
The "restrictive terms" - which again, were introduced in 2019 - are that you can use the software but not use the code to compete against the software's authors. For 99.99% of users, this has been a non-issue, because most people have no interest in doing so.
I like your product, but I tried self-hosting it -- twice over maybe four years -- and both times it just fell apart and destroyed itself in about two months after being set up. Proper configuration and regular upgrades as recommended by documentation, afaict. I'm ready to admit that I'm a complete idiot, but I have never had anything like that with any other product. I have my own theories for why it keeps happening, but not having any proof will keep them to myself...
Open core is a tried and true business model. It’s essentially just freemium, which businesses have done forever. If a healthy proprietary product can be built on the open source base, that’s a win-win. The company gets revenue and a sustainable business; the community gets free open source software with a highly motivated steward. There’s no reason to relicense if it works.
Things can go wrong in various ways of course, and drawing the line in the right place is a challenge, but that doesn’t mean that every VC-backed open core product is doomed to relicense. There are many examples of it working out well for both the company and community.
Open core in practical terms keeps many useful parts away of a product. A good example of this is clickhouse recently which keeps some of the most interesting features locked to the cloud version exclusively.
This is the reason why I believe Fair Core [0] is superior to open core, because the former eventually open sources everything, while the latter never open sources the useful parts. That's actually one of the main reasons I relicensed to the FCL from the ELv2 [1].
> Open core in practical terms keeps many useful parts away of a product.
Well yeah of course. If nothing useful is held back, no one is likely to buy the paid version of the product. That's how freemium works.
If you're relying on an open source project, you should want it to have a sustainable business backing it, and that means there needs to be a reasonable balance between free and paid features. If a project isn't helping anyone make money, no one is likely to do all the thankless tasks required to keep it healthy and growing, and there's a good chance it will end up abandoned eventually.
And if people want to run Open Core businesses I don't want to stop them. I just happen to believe that Fair Source is a better tradeoff than Open Core because it means that if the company goes under, you have a guarantee that _all_ of their stuff (that you relied on) becomes Open Source.
Ok, that definitely helps to clarify your point—thanks. But in that case, it sounds like the specific concern is more about open sourcing any proprietary components if the company fails, which seems orthogonal to the specific license. A provision like that would also be fully compatible with open core.
> Nowadays it is increasingly likely that my effort is eventually going to be relicensed and repackaged into non-free software without my consent, and no one (not even me myself) will be allowed to continue to benefit from my work.
The curious thing (and developers have the right) is that permissive licenses, like MIT, are growing every year while copyleft licenses like the GPL are decreasing in popularity. According to a loose Statista graph, ~41% of OSS projects used permissive licenses in 2012. By 2021, it was ~78%.
Personally, if I was making a solo OSS project, I completely get it. If Google wants to use it, even if they never gave back, I would be honored and quite possibly get a job from that. Using GPL just means my software will only be useful to GPL-loving compatriots, which is to say, almost nowhere outside the Linux communities. It's also not fair when my company (like most companies) benefitted immensely from various bits of MIT/Apache licensed software, so to give back to the community as a whole with the GPL feels unfair.
> The curious thing (and developers have the right) is that permissive licenses, like MIT, are growing every year while copyleft licenses like the GPL are decreasing in popularity.
Not very surprising given the sizeable army of all the “developer evangelists”, “developer advocates”, and “devrel people” who have been quite vocal on the gpl-bad-mit-good stance, all the while being on Big Tech’s dime, one way or another.
Why would Big Tech want to promote this view so much? Commoditize your complement, that’s why.
> but I think strict open source is the best net good for the world we live in.
Hard disagree. I think, importantly, that it is case-dependent.
I don't think it's "the best net good" that essentially the only companies that are able to make a profit from certain types of open-source products are Google, Amazon and Microsoft. It took quite a long time to determine if it would be possible for companies to build business models off open source, and so now that (again, for certain types of software) those business models basically evaporated due to the hyperscalers, I love this "fair source" movement.
Like you said, I think it's great that they are not trying to confuse this with open source. I think each has its place, and I think it's good that they sound like they're not trying to "compete" with open source, they're just trying to build a model where companies can be permissive with their source code but not have all their profits sucked up by giant tech companies.
> It's also ironic to me that this software is being built on top of git, and thus is a business model entirely dependent upon FOSS, while wanting to differentiate and build a business on top of it with a moat but still sharing the code in a way that protects them
To be fair (no pun intended), they could build it on top of two-year-old Git just the same. I rather fear that two years of DOSP are too short to be attractive for many companies that might otherwise adopt that license model.
When we really think about it, what's the real fear behind 2-year vs 4-year DOSP? Is it that users will choose the 2-year OSS version over the latest version, or that it encourages more viable competition? The former sounds like a value problem, and the latter sounds like an adoption problem, and those share a root problem.
The BUSL with a 4-year delay has shown to work, so why wouldn't the FSL with a 2-year delay also work? I personally feel like 2 years is a good enough head start i.r.t. competition, while providing users with more viable options to recover a lost or sunken ship.
The longer a product/service exists, the easier it is to compete with it based on the version two years prior, in particular if the source of the current version is also available (even if you can’t use it verbatim — but you can build your own variant of newer features, possibly even with a fully compatible API).
I’m assuming that they do keep improving the product, but the longer the product exists, the lesser that improvement will be, relative to what was achieved cumulatively in the years before. A moat is built up by keeping accumulating years of improvement, not by only retaining a constantly diminishing lead.
This will probably be the biggest weakness with the FSL.
Some companies will say, "it's FSL 1.1, but three years." Or, "it's FSL 1.1, but four years." Or, "it's FSL 1.1, but only if we go bankrupt." And on and on.
Considering GitHub created their own implementation of git to dance around the gray areas of the GPL, it doesn't really come as a surprise that the new product from the same people are also shying away from copyleft or permissible licensing.
Obviously that's likely a pretty uncharitable interpretation of something a lot more nuanced, but it's really frustrating to watch companies increasingly benefit from GPL'd software while simultaneously taking their ball and going home when it's convenient.
Many business models are entirely dependent on FOSS. It's not really an argument either way. If it weren't for those businesses, a lot of FOSS work would not happen...
> I admire the desire to make source code transparently available, and let people use it for free, but I think strict open source is the best net good for the world we live in.
Genuinely open source is also a better defense against lawsuits.
If the code is open source, some big company can sue, but the end users have rights as well as the code copyright holder. They're going to have to prove what code is being used and someone is likely to write code around the issue immediately. Sure, lots of people could get sued, but it's either not going to be worth it or someone with a big wallet is going to get involved which puts an immediate stop to things.
If the code isn't completely open source, then a lawsuit from a big company to a small one demanding a pulldown has a LOT more force since end users have no rights in that case at all (see what happened to Our Machinery).
> I think strict open source is the best net good for the world we live in.
I agree BUT we've also seen through decades that this model is not working. While there are plenty of notable exceptions, it is difficult to make a living developing code transparently and making it available to the public. We've seen that large companies will build around these tools and pressure developers but not return compensation. We've seen that many of these projects become integral in our infrastructure (though often hidden several layers deep). We've seen that code quality is degraded as things are rushed and the reality is only a few people work on these projects. We've simply learned that we can't really rely on donations and corporations will find it difficult to justify funding even if they highly depend on it (even when it is in their best interest). Because charity is "charity".
The real best thing would be to ensure we have an economy where we compensate people for work that others find beneficial. As in, work is work. If you're developing tools that others are using and monetarily benefiting from, you should be compensated for that work. The world I want to see is where you can make a living as a full time open source dev. And not just for gigantic projects that are easily recognizable as critical, but anything that is critical. Anything that is useful.
I really want to live in that OSS world, but I think we should also have a serious conversation about the issues we face. That we need to question if the incentives align like we think they align. And consider time, as they might have in the past but no longer do. I'll ask a proxy question: Could you research and invent a (Star Trek style) replicator in this environment? Replace with some other device if you will, but such a thing like this would upend many businesses and likely the cannibalize itself. But such a tool would fundamentally change peoples lives for the better, making post scarcity not only possible, but trivial (there are other easier ways to get post scarcity). Fwiw, when I ask the economists[0] they give a two letter answer.
It is undeniable that the way we've done things has been successful. But past performance is no guarantee of future performance. The burden of advancement is that you have to get more nuanced over time. Essentially, we can do well with a low order approximation, but that only goes so far. As you progress, you need to account for more and more higher order terms. So the question is if we've advanced enough where these matter.
[0] I only explain what the device does. Having the ability to assemble things from the atomic level. Like a 3d printer but for atoms. They are smart enough to figure out the rest and I do confirm this. (My partner is an economist, so I pester them about things like this and they do others in reverse. It's good fun)
This new "functional" license is interesting, in that it converts to MIT or Apache 2.0 automatically after 2 years.
I'm all for open source (and free!) software, however I hope these new licenses move more service-level businesses to follow suit and at least open up their source code in some way or another.
That's the first time I've heard about the fair source license. From what I understand it's slightly more restrictive than FOSS, but it aims to prevent hyperscalers from basically running your software in their cloud while you can't make a dime from it.
Is there anyone who can break down the advantage of something like this over a typical open source model? I read through the page and FAQ for fair source and still don't quite grasp the angle here other than making software less free for a temporary amount of time.
An increasingly common situation for open source projects is:
1. The FooLabs company creates the Foo open source software, which gets popular
2. FooLabs offers FooCloud, a paid, hosted, managed version of Foo for those who don't want to run Foo themselves.
3. AWS sees that Foo is popular and creates a competing paid, hosted, managed version of Foo (say, "AwsFoo").
4. FooLabs' hosted version doesn't really have much advantage over AWS and AWS has a huge base of existing customers, so it outcompetes FooLabs.
5. FooLabs perceives this as unfair. They did all the work creating + maintaining this software, but are unable to reap any rewards.
Different people have different opinions on #5, ranging from "Hell yeah, screw AWS!" to "What did you expect when you made this open source?"
As a result, there have been a wave of not-quite-open-source licenses aimed at preventing #3, often with a clause like "This license doesn't let you run a paid, hosted, managed version". GitButler's license is aimed at doing exactly that. People have been calling that "source available." Some people are trying to rebrand that as the cooler-sounding "Fair Source."
Some of these have caused huge community upsets because Foo is often popular because it's open source, and it feels like a bait-and-switch to suddenly yank that away once Foo reaches a certain point of growth. ElasticSearch is the biggest example that comes to mind: https://www.elastic.co/blog/licensing-change. GitButler, thankfully, is being much more up-front about it!
> 2. FooLabs offers FooCloud, a paid, hosted, managed version of Foo for those who don't want to run Foo themselves.
> 4. FooLabs' hosted version doesn't really have much advantage over AWS and AWS has a huge base of existing customers, so it outcompetes FooLabs.
FooCloud is often run with what is perceived as excessive costs/margins, so 1. they get really poor uptake, and 2. it's really easy for AWS to undercut them.
(I'd rather not discuss the tension described and am going to be vauge on purpose, as I work on SaaS that has multiple completing services from other providers)
Some SaaS, when operated by a vendor also selling IaaS, is sold at so low cost over the IaaS, that it doesn't matter how cheaply other vendors can build on top of that same IaaS, they could never compete on price.
I’m trying to find a clear distinction between “Source Available” and “Fair Source”. Sounds like there isn’t any common definition for source available other than that you are allowed to read the code.
From use, it seems like "Source Available" generally means "it's not open source, but you can go and read the code somewhere." So it's more a definition by contrast, really. "Fair Source" is a new term defined more precisely by https://fair.io/about/ - it seems to refer to be a more specific term referring to this specific license type.
Exactly. The problem with "Source Available" is that it has no real definition and it conveys no user freedoms outside of the (loose) freedom to read the source code, which is why the term has never taken off with anybody. It's wholly inadequate. That's why we needed a new term that does have a concrete definition and does convey user freedoms. Fair Source is meant to sit on the gradient between Open Source and Source Available.
It seems that the only relevant license in context is the Functional Source License (FSL).
What's the point of this new term only encompassing the accompanying new license from the same authors, other than to manipulate our minds to associate "FSL" with "fair"?
FSL is a source-available license. "Fair Source" is the name of an industry lobby group. Uncritically adopting their retaxonomization of software licenses and newspeak is not advisable.
The FSL seems like a valuable contribution and can make sense for companies like GitButler and Sentry. The accompanying lobbying and propaganda (aka "PR") spoils that somewhat.
Not just FSL. There's also the Fair Core License [0], the Business Source License [1], and we're open to adding more given they abide by the Fair Source Definition. We're just getting started.
You forgot 1.1 – FooLabs takes hundreds of millions of dollars in VC funding and these VCs want to see a 10x return on their investment, which is incompatible with keeping the software free and open source.
Sure. Presumably also the developers at FooLabs would like to continue having a job developing Foo, and the broader software community would like to continue benefiting from additional features and improvements to Foo, which probably wouldn't happen if developing Foo was economically unviable.
The main benefit is you get a rolling two years where no one else can use your code to compete with you. It’s a lot like a patent which gives you a window of time where you have an exclusive right to benefit from your creation.
Fair Source licenses place restrictions on how code can be used (for a "limited" time) in order to prevent others from using the code to compete with the corporate sponsors of the Fair Source code.
It isn't clear what restrictions will be allowed and still qualify as a "Fair Source" license. The first Fair Source license is the Functional Source License, which converts to Open Source after 2 years. It places restrictions on using the code to offer any commercial product or service that competes with the corporate sponsor.
If you choose to adopt such software, you will be unable to switch vendors for hosting, technical support or assistance, or any other service which the corporate sponsor offers in any way. The corporate sponsor can raise rates, offer terrible service, or otherwise do a bad job of supporting your business and the only alternative you will have is to adopt a different product (with all of the integration and development efforts that takes) or to self host and self support the product. You will be unable to engage a new vendor, at least for two years from the release of the version you are reliant on.
Also, if you contribute to a Fair Source product you will likely be forced to sign a CLA that grants rights to the corporate sponsor ponsor that go beyond the rights that you recieve under the license.
As you can see, I feel that Open Source is a much better model that better protects users, contributors, and community members of software.
"minimal restrictions to protect the producer’s business model"
That isn't very clear to me. Does every license author or licensor get to decide for themselves whether or not a license is Fair Source, or whether or not a limitation is "minimal"? Honestly, I don't think the limitations in the Functional Source License are "minimal". But others clearly believe they are.
The delayed part is explicit... but could a license that delays release to open source for 1,000 years be considered "fair source"? It is a DOSP as you say?
I understand that the Fair Source branding movement is still young and is likely evolving policies and procedures, but those are some of the questions I already see coming up when discussing whether or not a license is Fair Source. It may take a while for the definition to mature.
And it's important that we have these conversations. I would however like to understand why you believe the limitations on the FSL are too strict and what exactly they prevent which you believe they should not.
Lets say there is an FSL licensed SaaS app. And that the company behind it offers two tiers, a lower monthly fee that is "self service" with no integration assistance, and a higher monthly fee with a long contract term that offers integration assistance.
I decide I want to self host the product. I reach out to the company about integration assistance. They tell me they don't provide any support for the self hosted product and aren't interested in providing me with integration assistance if I don't use their hosted version.
Now, I decide to hire a local contractor I know to help me integrate the self hosted version. They don't touch the code or do anything with it, they just work on integrating it into my existing business stack.
Now, the SaaS company offers a competing product and service- the hosted SaaS with integration assistance. Is my contractor violating the license by offering a a service that substitutes for the service offered by the SaaS company?
I think many such SaaS companies would be fine with it, it wasn't a job they were interested in... but it rides up against the license really closely. And there are many variations of this scenario that could play out that could easily cross the line. (Perhaps SaaS company puts in a bid to do the work, but I decide a local contractor I have used many times in the past and is thus familiar with my stack and what they would be integrating would be better, or maybe the contractor does have to make changes to the FSL licensed code in order to make it work with something I need.
Those things can be negotiated and clarified, but generally only if you know they are an issue up front. If business needs change after you have adopted the software, you are in a tough negotiating spot.
One big benefit to the well worn and simple permissive open source licenses is simply knowing very early what exactly I can and can't do. The FSL is trying to get as close to this as possible, but it is inherently more complicated that "take this code and use it, just credit me and don't expect any warranty from me, oh, and by the way, if you want my help I offer my service for $$$ so reach out" style open source licenses (not all open source licenses are simple like that, though).
No ones saying Fair Source is better than Open Source, but in your analogy one protects the commercialization of a project, and the other does nothing to protect the creators.
The clarity of what is and isnt permitted is something we'll be looking to make sure is enforced via the license, at least in FSL's sake. The intent is that if you're commercializing by say, providing support or integration services, that its totally valid. What's not valid is hosting a competitive offering using the source code. That is, with FSL you cannot spin up the project and sell it as a cloud service, but you can provide professional services to customers using said product.
If you decided to build something that tried to sneaky leverage the business model that funds development, that its so closely related to what the company would do, and then the company does it... well, don't do that? You'd be stuck on the old version. Thats the price you pay for trying to be sneaky. The license is effectively encoding a set of values/ethics in how people should run businesses, particularly when building on top of other peoples businesses. I think this is totally fine, so whenever people bring up these hypotheticals I just shrug them off, as they're an academic edge case that all but a handful of individuals will never need to care about them.
Also generally speaking, the case you're describing sounds more likely to be an integration say between your service and their service, or more specifically, your code and their service (say an integration between Sentry annd MyCoolTicketTracker). You could still sell that integration just fine, as its your code, not the FSL code. What you couldn't do is sell a cloud service that was MyCoolTicketTracker, that funnels to a privately hosted Sentry, and then exposes the functionality of Sentry into MyCoolTicketTracker. At that point you're commercializing Sentry itself, not your services.
> Now, I decide to hire a local contractor I know to help me integrate the self hosted version. They don't touch the code or do anything with it, they just work on integrating it into my existing business stack.
We even specifically call out that case in the license as a permitted purpose:
> Permitted Purposes specifically include using the Software: [...] in connection with professional services that you provide to a licensee using the Software in accordance with these Terms and Conditions.
And yes, Fair Source has limitations over Open Source and by design. We figured the best way to balance this out is to transition it into a full and unquestionable Open Source via a springing license.
There are companies whose business model is to offer professional services around the software they produce. In this case, this clause means that they can't use that license to prevent such competition.
Hmm, though thinking more about it, as long as the licensee is the company using the software, rather than the company providing the professional services to the company using the software, then that might be allowed.
In addition, underneath the definition, we touch on that even more:
> The intention is for the first point to be a bright line, and for the second to invite exploration. We expect Fair Source licenses to emerge and evolve and shake out into a few clear winners over time, as companies apply Fair Source within their own particular business context. The third point is also intended as a bright line, and a key differentiator of Fair Source from Open Core and other approaches.
Thank you for pointing that out, I did a quick read through of that part and missed the intention behind it. I also found the Readme which helps explain the direction things are going. (https://github.com/fairsource/fair.io/blob/main/README.md)
All of the points you raise would be too if the project were simply a proprietary product, too. We're not worse off for having to deal with them for two years instead of forever.
No doubt that Fair Source and other eventually open source products are better than never open source products. Absolutely! And if Fair Source succeeds in getting more developers to release code, even if the code is 2 years old, as open source, I am all for it. I just want a clear understanding of what it is and what it isn't and what makes it different from open source.
> As you can see, I feel that Open Source is a much better model that better protects users, contributors, and community members of software.
Assuming that said vendor was even going to open-source in the first place. I would take Windows, Affinity, macOS, Adobe, literally any major software project under the FSL any day. Realistically, the companies that FSL appeals to, were never going to consider open-sourcing to begin with.
If the vendor doesn't go open source, I will look for an open source alternative. If none is available, I will consider building one. Only after researching those options would I consider a propeietary or "Fair" source product. And I would be very careful with how I integrate such a product into my business.
So yeah, if there are no good open source alternatives and building my own would be cost prohibitive, I might consider a Fair Source product.
It's available to everyone, all of the time. Anyone can do it, which is why you actually see forking and custom tooling quite frequently in businesses at-scale.
It's absolutely bewildering that someone would say "it's not going to make a difference" when half of the market for B2B software is literally predicated on the existence of more permissive tooling. Licensing is practically the only thing that matters besides security and functionality when evaluating software.
I'm not sure what you mean by this? I would guess from my own experience that there are open source alternatives to the majority of software. Often the open source software is just as good or better.
Simple - the standard open source business model sucks. Nobody donates, you’re in competition with the lowest common denominator when offering hosting services, and you might get ElasticSearched.
The entire purpose of Fair Source is to allow companies to open up the code when they would have never considered it an option otherwise. It’s a more open license for companies that would’ve otherwise been proprietary without apology.
Having grappled with this dillemma myself as a founder, interested to see this FS model gain traction towards a middle ground. Knowledge is shared not closed off. And the company that is keeping the tech progressing can stay competitive.
If the intent is to ban any commercial use (without acquiring a separate license), it’s dishonest not to say so outright instead of hiding behind legalese.
I fear that clearly defining what does it mean to compete in the context of this license is going to be a bitch.
Was it Unity recently that they had to do this ridiculous back-and-forth, issuing multiple statements to clarify whether this or that edge case is a violation or not? Or was it Redis? I don’t remember which product it was, but the turmoil I remember quite well.
Does anyone know why companies don’t release under AGPL for everyone and then under a proprietary commercial license to themselves? Essentially dual-license it.
AGPL would dissuade Google and AWS from using it, and the commercial license would allow the licensee (themselves) to commercialize it?
I thought so too and argued it in another thread a while ago. Others commented that apparently AGPL wasn't working to dissuade cloud providers enough for MongoDB and that is why they switched away from the model you described to a source available model.
One big reason we don't use AGPL at Sentry is that we want companies to be able to self-host individually (just not start a competing SaaS), and many have a blanket ban on AGPL.
I expect we will soon start to see blanket bans on fair use licenses also. At least the functional software license referenced here. There is just too much great area and potential legal risk.
Sentry's experience suggests otherwise, as 10,000+ users from hobbyists up to FAANG companies have been using Sentry under Fair Source terms for five years now.
I don’t get the blanket ban on AGPL-am I misunderstanding how attach-y it is?
For example, people seem to have the impression that if you host something like an AGPL email validation service that just has an API to request a check for an email and then connects via SMTP, which another service calls, that you “infect” your product that even uses that API.
I get that if you change the service and/or expose it publicly you have to make the changes available, but it seems misunderstood.
It might be: but as a creator of software one wants to make their users happy. We certainly do we at Sentry.
Even personally, years ago I relicensed all my GPL code to BSD/MIT because I wanted people to use my software. I’m not there to tell them that they are wrong about their license restrictions.
> On the other hand, we are investing heavily in the software, have investors and employees, and want to be able to build a build a profitable business on top of our product.
To clarify, are you trying to protect against those who don't pay (me), or those that compete with you by monetizing your product?
Is Fair Source a super set of Open Source? On other words, is any open source license automatically a fair source.
For every open source project, the source is available, under an open source license after 0 days, and usable and modifiable for anyone who doesn't compete or does.
Fine by me. It never seemed that great to begin with. I hated how it injected its own branded commits into my repos. And it never worked with the submodules I unfortunately have to work with
Got me thinking about FUTO's Source First License. I'm liking these movements in general, but they could use some consolidation and standardization similar to the *GPL family.
Can we please just refer to the license by name ("Functional Source License", or just "FSL"), rather than acknowledging and adopting this new strange (BS) "Fair Source" terminology when talking about licenses? "Source-available" is already recognized and applicable if you feel a need to taxonomize the license.
There is the "Fair Source" industry lobby group closely associated to the license and I suspect the confusable naming may be intentional here, both coming from the same parties.
It was hard to put my finger on why that is. It doesn't smell of marketing (a whiff, maybe), I don't think it's dishonest, it strikes me as a sincere way of trying to explain why the users/authors feel like they need to do anything other than just give the software away.
It's that there's an inevitable comparison baked in to the choice of name: we have open source, and fair source. Fair source is meaningfully less open, but open source is at least equally fair, one can argue that it's more so, but not less. It doesn't really hit at the reason for having these licenses in the first place, and it does have a sort of aura of "see! We're trying, we're doing our best over here", which is accurate, but also, off-putting.
I have a suggestion, not that I expect it to matter: first, drop the [adjective] source pattern completely. You don't need a category of software licenses, you need a software license — and you really, truly, do not need the headache of trying to decide which non-free licenses get to live under the 'fair' umbrella.
Call it the Head Start License. That's what it does: it gives the authors a head start. I consider that fair! As I was saying at the beginning of the post, my objection isn't nearly so simple as "you say it's fair and that's wrong".
If pushed on what "kind of" license that is, you can call it eventually-open source. There's no 'spin' there, because it's literally true: it is, eventually, open source software. Plus you can put your foot down, because the essence of what the license is now lives in the name: "eventually, in this context, means two years. We consider less than two years also eventually open, more than that is, at best, eventually eventually-open source software." That probably sounds funny but it would work, with the right memetic buy in: no, we've established this, your six-year license is not eventually open source, eventually means two years, here, check out this website I'm linking to.
I hope I've made it clear that while I dislike the choice, I don't find it distasteful. Others are going to find it distasteful. I'm not going to speak on behalf of those people, but mind share is critical with an idea like this, and you're going to be doing battle with "if it isn't free it isn't fair". Good slogan actually, you don't have to agree with it (I don't) to recognize that.
Anyway, good luck with the project. I commend you for not succumbing to the temptation to try and slice a bit of salami off the open source definition, although as I write that out, I'm realizing some of my dislike here is in fact that 'fair source' tries to borrow some of the emotional valence of free software, and that's the thing, you don't need to do that: eventually-open source becomes open source, eventually, it's a binding commitment, you just need people to show some patience, because you have a living to earn in the meantime. You wrote it, so you get a head start. Seems fair.
If it was my bikeshed, well, that's the colour I'd paint it.
> I have a suggestion, not that I expect it to matter: first, drop the [adjective] source pattern completely. You don't need a category of software licenses, you need a software license — and you really, truly, do not need the headache of trying to decide which non-free licenses get to live under the 'fair' umbrella.
No, we don't need a single Fair Source License. I originally was on this bandwagon, too, but I was convinced along the way that we need a lot of focused licenses covering the myriad of ways businesses monetize their core products. From SaaS, to on-prem, to open core, etc. All of these monetization strategies require different restrictions e.g. monetizing SaaS is only concerned with other SaaS competition, but monetizing open core is concerned with protecting premium features. Attempting to draft a single license that everybody can use ends up creating a license nobody can understand. (Trust me -- we tried it!)
This is the entire reason I essentially forked the Functional Source License [0] into the Fair Core License [1] -- because the FSL didn't offer a way for me to safely monetize an "open core"-style product [2].
> Call it the Head Start License. That's what it does: it gives the authors a head start. I consider that fair! As I was saying at the beginning of the post, my objection isn't nearly so simple as "you say it's fair and that's wrong".
Right away, Head Start has strong negative connotations and would never see the level of adoption we're looking for. We want companies to be excited about it, and conveying they need a handicap does not do that. It's also not communicative, you can't say "X is now Head Start" or "X was Head Started".
Not to mention, like I touched on above, Fair Source isn't a single license. It's an umbrella covering many licenses, hopefully with more to come as adoption grows. And you even said it -- a "head start" is fair, so "fair" source makes perfect sense.
> If pushed on what "kind of" license that is, you can call it eventually-open source. There's no 'spin' there, because it's literally true: it is, eventually, open source software.
Delayed Open Source publication (DOSP), or "eventually-open-source", is a weak term by itself, since it just means proprietary/closed-source software that is eventually Open Sourced. It has the same problem that "source-available" has -- it doesn't convey any immediate user freedoms. Fair Source however requires that the software be publicly available to read now, with the freedom to be used, modified, and redistributed with minimal restrictions, in addition to undergoing DOSP typically within 2 years.
My $0.02: I think people would complain no matter what it was called. It'll grow on everyone the more it's adopted.
It's also ironic to me that this software is being built on top of git, and thus is a business model entirely dependent upon FOSS, while wanting to differentiate and build a business on top of it with a moat but still sharing the code in a way that protects them. It just seems like an uncomfortable position straddling the fence between two paradigms.
Maybe I'm privileged in the fact that I've always lived comfortably enough in my career to feel like I can write and release OSS under the most permissive terms (whether it's used or not). But that feels like the best way to give back to the movement that effectively led me into this career for free, and lets me pick from offerings that are forced to differentiate on price or other features rather than whether they can license the software.