GitButler is now fair source
blog.gitbutler.com
blog.gitbutler.com
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.
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?
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.
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.
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.
https://openpath.chadwhitacre.com/2024/widespread-use-of-a-f...
Fair Source is working quite well for us. You should try it. :^)
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.
[0]: https://fcl.dev
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.
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%.
The Register has also noted this phenomenon. Copyleft is completely out of fashion. https://www.theregister.com/2020/01/17/mit_apache_versus_gpl...
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.
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.
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.
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.
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.
If the author is no longer improving the product in 2-year cycles, they deserve to be usurped.
[0]: https://fcl.dev
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.
RMS gets a lot of flack, but he's pretty good about defining terms like this precisely.
Free software has no restrictions on USE, the restrictions are on redistribution.
Open source is ambiguous can mean all the way from "you can see the source" to being public domain.
Fair source is not free software. They are restricting how it is used.
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.
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.
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.
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.
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.
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.
[0]: https://fcl.dev
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.
We called that out on the website though:
Fair Source Software (FSS):
* is publicly available to read;
* allows use, modification, and redistribution with minimal restrictions to protect the producer’s business model; and
* undergoes delayed Open Source publication (DOSP).
The delayed open source publication part is explicit.
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.
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).
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.
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.
Does that interpretation sound like the intent?
> 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.
The key line is to "invite exploration."
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.
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 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.
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.
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.
AGPL would dissuade Google and AWS from using it, and the commercial license would allow the licensee (themselves) to commercialize it?
Another possibility is to make it available under several licenses: AGPL + free but restricted licence.
[0] https://openpath.chadwhitacre.com/2024/widespread-use-of-a-f...
https://openpath.chadwhitacre.com/2024/widespread-use-of-a-f...
Sounds like their own self-created problem.
https://opensource.google/documentation/reference/using/agpl...
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.
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.
To clarify, are you trying to protect against those who don't pay (me), or those that compete with you by monetizing your product?
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.
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.
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.
[0]: https://fsl.software
[1]: https://fcl.dev