Some startups going 'fair source' to avoid the pitfalls of open source licensing
techcrunch.com
techcrunch.com
This will lead to more market consolidation and less innovation in the cloud space. Taking advantage of licensing to stifle companies has turned out great for the mobile phone landscape. I love having essentially two choices for a phone.
Open source is amazing, but this is one of the weaknesses that have been exploited in recent years that medium sized and newer companies are combating with server-side public license. Linux is not just kernel, but its backed by a foundation that can protect it's revenue streams with GPL licensing.
Use a copyleft license like (A)GPL then?
Look, if you want to license your software as "fair source" or whatever other non-free license that's your right, I just won't use your software. But don't pretend about the reasons for doing so - companies licensing their software this way are doing so to prevent competition, not because they want contributions.
Young companies protecting their revenue against established competitors is an entirely valid use of open source license. These licenses won't affect you unless you are an exec level employee at a unicorn
Personally I would rather buy a product where there is "fair source" available but premium features were paid for than a completely closed source product. That's my perspective. I do think it's tough when amazon comes and takes a code base that consists of mostly (say) elastic co employee code but is open source and then competes with elastic on the basis that they don't have to pay the software developers. It's really rubbish capitalism, and something needs to be available to protect any company that pays developers to build an open source product/business.
Otherwise we end up back at open source developers not getting paid, and that's not good for anyone.
It seems like you took the marketing on the tin for open-source seriously. Have you had "the pleasure" of maintaining an open-source project?
Contributions are rare. They are almost always self-interested. "Giving back" isn't a factor as you often are helping the rare contributor by main-lining their code so they don't have to maintain a fork.
> As I see it, if your startup's business model relies on your core code being proprietary, you don't have a business model.
Reality begs to differ. Google, Meta, Instagram, Uber, Microsoft... seem to have business models.
Google, Meta, and Microsoft are not startups. They are lobbying firms that are protected from above.
Uber was once a startup. It is no longer a startup. Once you IPO, you are no longer a startup. In any event, Uber has always had a strong open source presence. Their core competency is available to everyone via cadence, h3, RIBs, etc.
I run a fair source business, and I'm quite heavily involved in FSS. I don't rely on free work, and afaik neither do any of the other companies currently a part of fair source. Regardless, the problem of "free work" is in no way unique to fair source -- single-vendor commercial open source could have the same problem. Fair source offers a lot of other benefits that interest companies outside of "free" contributions, the main one imo, being wider distribution.
That’s an odd statement. Most software companies have their core product as closed source. Microsoft and Google built an empire on closed software.
The only ones that use open source have a business reason to do so, usually because they make tools that depend on widespread adoption.
E.g., there’s no need for Jira, Salesforce, Notion, or Facebook to be open source because they don’t directly integrate with their customer’s software development or IT process. Their products have almost nothing to do with software so the code inside doesn’t matter to the customer.
This is orthogonal to what I said. Which of these companies strongly rely on their core code being proprietary? In other words, which of these companies would perish if they adopted open source? In any case, at least Meta has a strong open source presence.
> The only ones that use open source have a business reason to do so, usually because they make tools that depend on widespread adoption.
The reason you noted is just one of many reasons for open sourcing software. Other reasons include the belief that open source is good for the world and for hiring developers too. This goodness usually comes back in kind. Not everything in this world is about immediate corporate greed, but with your mentality, you will never understand it.
They benefit from their tools and frameworks being open source because they receive free labor from outside contributors, and they give away very little in dollar value by keeping those tools open source. There is no way to sell React and make even a noticeable fraction of the profit that Facebook does. Their value is orders of magnitude apart.
For-profit companies struggle to actually make a real profit off of those types of tools and frameworks because there’s so much benefit to having them be open source. That’s not where the money is.
React isn’t a money-generating product and likely wouldn’t be a strong business on its own.
Jira, Salesforce, and Notion would all sacrifice a dramatic amount of revenue if their core product was open source. Why would anyone pay for those products if you could self-host them for free?
Open source may be good for the world but we are talking about for-profit businesses. Corporate greed is literally how they run. The only time a business makes something open source is when it directly benefits them. You can say whatever you want about good karma but that is not how businesses make decisions about how they generate revenue. The goodness does not usually come back in kind in the world of business.
Again, the example is Meta. React having outside contributors benefits Meta more than keeping the library closed source. Other companies who use React don’t generally compete with Meta’s bread and butter revenue product, and even if they do, it’s not giving them any specific business advantage over Facebook/Instagram/WhatsApp.
What concerns me about these semi-open licenses is, am I held hostage if the developer raises prices on me? If once I commit to the software I have no alternative to paying them for their managed service, it doesn't really help me that I have some access to the source code.
A semi-open license like Llama uses is less troublesome. It isn't open source, but it's pretty clear that you just can't use it for certain activities. If I don't plan on using it for any of those activities, it's fine. I'm not committing to paying Facebook X dollars a month and if their companies struggles maybe they'll start charging me 2X or 3X or 10X dollars a month.
Choose your dependencies wisely. 99.9999% of these projects will be archived one day anyways. Best you can find is a 5 year guarantee or something.
Software is always changing. Everyone has the same problem.
The problem clearly isn't that the source is available but rather that companies don't feel like they can monetize their products in an open source ecosystem.
However frustratingly these same companies avoid copyleft licenses that would give them that exact ability to effectively monetize (via a dual license) without unduly limiting users rights to use the main version of the product.
GPL and AGPL are already there, I know what they are and the intention is clear. And like you said, if they want to dual license it, they still can.
What the end goal of these so-called opensource companies want is to have you use their "free" demo, but when you get slightly big and is somewhat locked in, or need some feature considered enterprise (coz you got bigger or have revenue), they extract a partial income stream off you.
This revenue model isn't bad per se, but why not just be upfront about it?
Look at unreal engine - their license explicitly states this. You give them some % of your revenue if it reaches $1 million or something like that. Why can't this be more normalized?
This business model is still massively preferable to fully closed source in my view.
Given the way that SPDX is set up, I imagine the ideal way to do it would be to create some standard proprietary licenses and then add exceptions for "small" users that don't want to use the copyleft license and would eventually like to get big.
i.e.
- Commercial-Royalties-1pct
- Commercial-Royalties-5pct
- Commercial-Royalties-10pct
- Commercial-Royalties-Negotiable
- Commercial-Seats-Negotiable
with the following optional exceptions
- Under-100k-USD-Revenue
- Under-1M-USD-Revenue
- Under-5M-USD-Revenue
- Under-10M-USD-Revenue
There's a certain amount of inflexibility that comes from trying to standardise license terms in a way that's compatible with SPDX but maybe an extension to SPDX in the future might improve that and allow you to specify certain terms on licenses more than just basic exceptions.
But what about 1% of revenue for a UX libary or database product from uber?
I'd say that the old elastic licence is great to standardise and so is the 0.5%, 1%, 1.5% or 2%; over a Million, 5 Million or 10 Million.
It doesn't have to always be at 1%.
You could have a "negotiable" license as well but it becomes quickly non-trivial to document what the negotiated terms are in your SBOM.
"Then it shouldn't be open source" - Yes, true and I agree. But source available, with a bit of a community in github/discord and opportunity to host the code yourself free for small use cases, read the code and raise PRs is WAY BETTER than a fully closed source product. How do we standardise that in a similar way we have done with open source licenses?
It doesn't but I don't think I've seen Amazon being cheaper than other hosting options, especially after IO costs.
What AGPL does stop is Amazon writing improvements, extensions, and integrations for your product and then refusing to make them public in a way they can be upstreamed. That's the bigger issue.
Competing on hosting price or on maintenance/support contracts against Amazon generally is going to favor the smaller party because of the AWS tax. Competing against a city's worth of engineers improving a closed source downstream of your product however is going to be a losing battle. AGPL fixes that.
This is exactly backwards, because of how corporate procurement works.
Large companies--the ones with money--have a whole process around working with new vendors. It can take months to setup. A security review, audit, and legal are likely to be involved.
Or, they all already have a contract with amazon and can start using the Amazon service providing X immediately.
From CTO to audit, risk, accounting, and compliance, everyone's life is easier if they use one vendor for everything, rather than 10.
Larger companies are willing to eat a higher cost for the sake of bureaucratic and logistic simplicity.
The point is big established vendor free-riding on the work a smaller company has done, potentially extinguishing or significantly damaging it and by extention the future of the project.
The upstream can provide:
- Hosting (as mentioned before) or assisting in managing colocated infra.
- Proprietary Licensure for more permissive uses (as mentioned before).
- Support/Security contracts for LTS/Enterprise releases.
- Bug & Feature Bounties for priority changes (or a "hire our engineer" type system).
- Contracting and consulting services for companies building on top of their product.
That's just naming a few but there are plenty of ways to build out a reliable income base for a popular open source product as long as you pick the right licensing early on.
Hosting, Deployment help, LTS release
When you are buying a "one click" aws managed service?
Are feature or bug bounties even applicable if you have to wait an unknown amount of time for it to reach you via AWS?
I'm merely suggesting THAT copyleft doesn't provide you any protection here and WHY that is potentially problematic.
You wouldn't however I was listing them for completeness-sake because they are common strategies employed by FOSS maintainer companies and there's still a market for them outside of the AWS world.
> Are feature or bug bounties even applicable if you have to wait an unknown amount of time for it to reach you via AWS?
That can actually end up being a selling point for moving off the AWS version. If you can effectively "advertise" that and a company really needs a specific feature for their product, that might give them the justification to jump ship to the non-AWS version of the product.
> I'm merely suggesting THAT copyleft doesn't provide you any protection here and WHY that is potentially problematic.
Oh for sure. However I would maybe say that it offers limited protection here (mainly offering protection in other ways) rather than none at all. And that can definitely be problematic no doubt but nowadays I think companies are a lot more hesitant on blindly lumping everything onto AWS compared to 5 or 10 years ago so I'd like to believe that AWS' authority in deciding what is and isn't a viable product is declining in the space.
We need a "fair source", or whatever we call it. We need a way for people to contribute, many ideas to gain a community of contributors, without a funded agent to simply focus on how to monetize the software.
Open source or "fair source" are all distribution models. For people to see, try, adapt and maybe even contribute to your software ideas. It enables everyone to build and share. And if someone wants to compete with the stated software, they can buy a license. That is a fair business model, IMHO.
I don't think we need a new class of licence that tries to extract the goodwill generated by the free and open source community, without adhering to the moral underpinnings of that community.