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.
