These companies take software usage and contributions for granted. "Fair source" software will lose out in usage and in contributions to open source software. It's a vain attempt at getting contributions without giving back. They might as well stop the pretense and keep it private. As I see it, if your startup's business model relies on your core code being proprietary, you don't have a business model.
Permissive licenses give mega-corps (AWS,GCP,Azure) the ability to use software projects without contributing to it. This mechanic in the market is going to dramatically shorten the runway for open source projects turning into mature companies like redis and elasticsearch. Once they hit a certain marketshare, cloud companies can take away one of the primary revenue streams large enough to support teams of developers improving the project. I know big corps contribute developer time to projects, but it doesn't hurt to have more competition.
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.
> Permissive licenses give mega-corps (AWS,GCP,Azure) the ability to use software projects without contributing to it.
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.
Copyleft licensing doesn't protect against cloud hosting competition. It mostly applies to modifications to the source code, but not hosting for revenue. As long as their contributions are also open source, the license is satisfied.
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
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.
I even consider a new Issue a contribution. It helps me identify the most common issues so they can be addressed, making the software better. Issues are a function of adoption which is a function of open source.
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.
> It's a vain attempt at getting contributions without giving back.
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.
I don't know, do these the majority of these companies actually rely heavily on free contributions?
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.
People can still contribute in other ways, such as by identifying snippets of code that lead to reproducible bugs. Every valid bug report or feature request has the opportunity to make a software better. If something was not open source, I would not bother because I would not use it at all.
> As I see it, if your startup's business model relies on your core code being proprietary, you don't have a business model.
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.
I'm torn because as a user, the best license is a pure open source license. But I know that many companies that start out offering an open source product aren't going to be able to make that work. It's really frustrating when a product like Redis or Elasticsearch churns their license around. It would have been better for everyone if they had a clear "semi-open" license to pick in the first place, that gave them a business model while being "open enough" for my purposes.
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.
I feel like fair source exists as a concept mainly because of fearmongering about free software and copyleft licenses. There is little reason projects can't dual license a copyleft license like the GPLv3 or AGPLv3 with a proprietary license.
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.
That’s what I think as well. They are beating around the bush, everyone inventing their own license types. If I see some unknown license, I will assume it’s a trap and stay away. I don’t have lawyers on retainer to interpret new license types for me.
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.
AGPL or other copyleft licences don't stop amazon taking "your" product and hosting it for less than your own hosted offering as they don't have to pay the developers.
"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?
> AGPL or other copyleft licences don't stop amazon taking "your" product and hosting it for less than your own hosted offering as they don't have to pay the developers.
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.
> Competing on hosting price or on maintenance/support contracts against Amazon generally is going to favor the smaller party because of the AWS tax.
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.
For the purposes of the point I was making and this discussion it doesn't really matter if it's market dominance or cost.
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.
Of course that can be problematic still but I don't see how they can extinguish the founding company when you are working with a license like the AGPL (with proprietary dual licensing). They are still the upstream and "parasitic downstreams" have very limited opportunities to build trenches with such a strong copyleft in play.
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.
> Why would you need Hosting, Deployment help, LTS release When you are buying a "one click" aws managed service?
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.
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?
It would be nice to see a standardised set of proprietary licenses that you can easily dual license a copyleft project with.
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.
Yeah you could definitely do smaller royalty rates or a step up fee schedule but I know SPDX isn't too keen on people dumping a thousand licenses at their feet to include and until you can easily plug in custom license parameters, I'm not sure if there is a better approach without absolutely blowing up the SBOM with custom licensure.
I think there is a whole world between going all in on an open source license and allowing funded companies to simply competing with you vs not releasing source at all.
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.
There is already a term for this type of software licence: Proprietary.
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.
These companies take software usage and contributions for granted. "Fair source" software will lose out in usage and in contributions to open source software. It's a vain attempt at getting contributions without giving back. They might as well stop the pretense and keep it private. As I see it, if your startup's business model relies on your core code being proprietary, you don't have a business model.
Permissive licenses give mega-corps (AWS,GCP,Azure) the ability to use software projects without contributing to it. This mechanic in the market is going to dramatically shorten the runway for open source projects turning into mature companies like redis and elasticsearch. Once they hit a certain marketshare, cloud companies can take away one of the primary revenue streams large enough to support teams of developers improving the project. I know big corps contribute developer time to projects, but it doesn't hurt to have more competition.
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.
> Permissive licenses give mega-corps (AWS,GCP,Azure) the ability to use software projects without contributing to it.
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.
Copyleft licensing doesn't protect against cloud hosting competition. It mostly applies to modifications to the source code, but not hosting for revenue. As long as their contributions are also open source, the license is satisfied.
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
> and in contributions to open source software
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.
I even consider a new Issue a contribution. It helps me identify the most common issues so they can be addressed, making the software better. Issues are a function of adoption which is a function of open source.
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.
Is any Google business apart from selling ads profitable yet?
> It's a vain attempt at getting contributions without giving back.
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.
I don't know, do these the majority of these companies actually rely heavily on free contributions?
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.
Yaac and other open source tools are less than enthusiastic about receiving fixes from outside.
People can still contribute in other ways, such as by identifying snippets of code that lead to reproducible bugs. Every valid bug report or feature request has the opportunity to make a software better. If something was not open source, I would not bother because I would not use it at all.
> As I see it, if your startup's business model relies on your core code being proprietary, you don't have a business model.
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.
I'm torn because as a user, the best license is a pure open source license. But I know that many companies that start out offering an open source product aren't going to be able to make that work. It's really frustrating when a product like Redis or Elasticsearch churns their license around. It would have been better for everyone if they had a clear "semi-open" license to pick in the first place, that gave them a business model while being "open enough" for my purposes.
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.
If the license changes you can still use the most recent build with the license that suits you. If you need to update it then fork it.
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.
I feel like fair source exists as a concept mainly because of fearmongering about free software and copyleft licenses. There is little reason projects can't dual license a copyleft license like the GPLv3 or AGPLv3 with a proprietary license.
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.
That’s what I think as well. They are beating around the bush, everyone inventing their own license types. If I see some unknown license, I will assume it’s a trap and stay away. I don’t have lawyers on retainer to interpret new license types for me.
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.
AGPL or other copyleft licences don't stop amazon taking "your" product and hosting it for less than your own hosted offering as they don't have to pay the developers.
"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?
> AGPL or other copyleft licences don't stop amazon taking "your" product and hosting it for less than your own hosted offering as they don't have to pay the developers.
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.
> Competing on hosting price or on maintenance/support contracts against Amazon generally is going to favor the smaller party because of the AWS tax.
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.
That may be true but that's a very different discussion than discussion on competing over cost.
Larger companies are willing to eat a higher cost for the sake of bureaucratic and logistic simplicity.
For the purposes of the point I was making and this discussion it doesn't really matter if it's market dominance or cost.
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.
Of course that can be problematic still but I don't see how they can extinguish the founding company when you are working with a license like the AGPL (with proprietary dual licensing). They are still the upstream and "parasitic downstreams" have very limited opportunities to build trenches with such a strong copyleft in play.
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.
Why would you need
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.
> Why would you need Hosting, Deployment help, LTS release When you are buying a "one click" aws managed service?
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.
They are indeed beating around the bush.
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?
Couldn't agree more, I'd love to see a range of standard licences for this business model, in a similar way to what we have with MIT, GPL etc.
This business model is still massively preferable to fully closed source in my view.
It would be nice to see a standardised set of proprietary licenses that you can easily dual license a copyleft project with.
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.
Love the idea, but for unreal engine 1% royalty is fair, you've built your entire product on it.
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.
Yeah you could definitely do smaller royalty rates or a step up fee schedule but I know SPDX isn't too keen on people dumping a thousand licenses at their feet to include and until you can easily plug in custom license parameters, I'm not sure if there is a better approach without absolutely blowing up the SBOM with custom licensure.
i mean, surely you can have tweak the license (i.e., have the wording be a "variable" which is set at the point of agreement).
It doesn't have to always be at 1%.
Ehh that's kind of the problem with using a SPDX license tag.
You could have a "negotiable" license as well but it becomes quickly non-trivial to document what the negotiated terms are in your SBOM.
I think there is a whole world between going all in on an open source license and allowing funded companies to simply competing with you vs not releasing source at all.
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.
[flagged]
There is already a term for this type of software licence: Proprietary.
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.