13 ms·

This is more validation of the threat that cloud providers (mainly AWS) are to businesses built around open source products. Yes, AWS and others are legally per

by dhd415 7y ago

This is more validation of the threat that cloud providers (mainly AWS) are to businesses built around open source products. Yes, AWS and others are legally permitted by existing open source licenses to create SaaS versions of these open source products, but with cloud computing becoming an increasingly winner-take-all market, it leaves little room for the software's authors to generate revenue via hosted offerings of their software. If you think that the Cockroach Labs, Redis Labs, Mongos, Elastics, etc., of the world provide a net benefit to the software world, I think you have to contend with the fact that there is going to be fewer such companies in the future if AWS keeps eating their lunch.

fossuser 7y ago
It'd be interesting if there was a way to specifically require AWS, Azure, Google Cloud (or more generally any cloud hosting reseller) to pay if they use the open source software or any derivative of it (or if they create any company which then uses it) for the purposes of reselling it to others. Basically give the open source project a 30% cut if you're going to resell it (or fork and resell it). It might be hard to do now since with AWS since with ES Amazon just forked whatever version was already permissively licensed, but it may be interesting to create a new license to protect against this for new OSS projects.
- nradov 7y ago
  You can put any license on your software that you want, but a license that required revenue sharing wouldn't really count as "open source".
  - alfonsodev 7y ago
    I understand what you mean and totally agree with you, I just feel the need to remind (not to you) the term free software, as many things are open source but not free software [1] [1] https://www.gnu.org/philosophy/open-source-misses-the-point.en.html https://www.gnu.org/philosophy/open-source-misses-the-point....
    - elcritch 7y ago
      Unless the AGPL becomes the new GNU default, "free" software is largely moot as well in the age of SaaS.
      - AsyncAwait 7y ago
        Most software I use daily is (luckily) not SaaS and as for AGPL being the default, for SaaS free software that's already pretty much the case today.
    - dragonwriter 7y ago
      > I understand what you mean and totally agree with you, I just feel the need to remind (not to you) the term free software, as many things are open source but not free software [ Open Source and Free Software are, as your link points out from the latter side, divergent ideologies, but they aren't substantively different in terms of concrete meaning when it comes to licensing. It is absolutely not the case that “many things” are Open Source but not Free Software, though many projects producing software which is both Free and Open Source adhere to only one of those ideologies, at least as the projects dominant ideology.
  - erikpukinskis 7y ago
    Deleted
    - RcouF1uZ4gsC 7y ago
      >Secondly, there are many open source licenses which are not GPL, including licenses with no redistribution rights at all. I believe the correct term for those licenses is "shared source" not open source.
- jasode 7y ago
  >, but it may be interesting to create a new license to protect against this for new OSS projects. Well, you also have to take the game theory of incentives into account. Let's say you develop a new database called NextGenCockroachDB with a required 30% royalty license. That type of license will alter the behavior of people evaluating it and may very well prevent it from being adopted at all. If there's no critical mass of the market using it, the 30% royalty becomes a moot point. The whole market of choices available to economic participants has to be analyzed. If potential buyers have an option to substitute a db with 30% fee with another open source db with $0 license, they will be incentivized to avoid paying 30%. If an open source db requires royalty payments from cloud platforms, it will need to have amazing technology that nobody else can duplicate.
  - ivalm 7y ago
    And even if you have some tech advantage, it still needs to compete with 0 cost license + increased infrastructure (since licensing dollars can now be spent on more hardware; 30% more hardware is hard to beat).
- batbomb 7y ago
  The $100MM Revenue License... Once your company surpasses $100MM in revenue you have to negotiate licensing terms.
  - sangnoir 7y ago
    How many engineers can be paid from $100MM revenue?[0] The *aaS company might be better served by employing engineering team to maintain their fork/API-compatible clean-room implementation a-la Amazon Aurora. 0. If company is profitable and licensing costs > overall salaries + monetary value of controlling roadmap.
    - deleted 7y ago
      [deleted]
- monocularvision 7y ago
  Isn’t that exactly what they are doing and saying in this blog post?
- dantheman 7y ago
  A 30% cut of what? The core costs are in the deployment of the servers, network, security, management, etc.
  - ForHackernews 7y ago
    Most developers would prefer a 30% cut of profits, not a 30% liability of costs, I'd assume.
- dragonwriter 7y ago
  > It'd be interesting if there was a way to specifically require AWS, Azure, Google Cloud (or more generally any cloud hosting reseller) to pay if they use the open source software or any derivative of it No, such a requirement makes it not OSS.
DannyBee 7y ago
The problem with this argument is that there has always been a before and after. IE This is not the first business model issue OSS has dealt with. For example: It seems ridiculous now, but at one point authors were significantly squeezed by commercial distros offering support and feature work directly to customers for their packages. (And this was even a similar kind of disintermediation applied to authors as you see now - people only cared what they got from redhat, not from the original author) One interesting constant is that most of the projects that felt a need to change licensing to react to business model issues over the years are dead ;) . Not all of them, mind you. But the failure rate seems really really high. The underlying issue here in this one is that people (apparently so far!) want to use AWS/GCP/etc more than they want to use mongo, redis, cockroach, or any particular technology. No license change will fix that. In that case, AWS actually controls your customer more than you do. Unless something comes along that is "better enough" that people are willing to buck AWS to use it, this approach of relicensing fails. (and the customers certainly don't care about your licensing scheme)
- OJFord 7y ago
  > The underlying issue here in this one is that people (apparently so far!) want to use AWS/GCP/etc more than they want to use mongo, redis, cockroach, or any particular technology. > No license change will fix that. Well, perhaps not a licence change, but if it's good enough that it's The One the provider wants, but it can't offer it under the terms of the licence, then paying for it under a separate licence could be a win for both parties.
  - sangnoir 7y ago
    Depending on the licensing cost and the effort required to integrate the project with their infrastructure, it might be cheaper for the provider to fork the last version before the relicense and support it going forward. Maintaining API/wire-protocol compatibility isn't that hard for large tech companies these licenses are trying to battle. I don't think these open source companies are not aware of the risk of forking, but they are between a rock (AWS/GCP) and a hard place (VC returns demands).
tdb7893 7y ago
I think from a practical perspective this makes sense but having to change their licenses makes me sad. I don't want to see licenses change from "you can do whatever you want with this" to "you can do whatever you want with this unless you are competing with us".
- dhd415 7y ago
  To be fair, they're forbidding only one specific form of competition- managed hosting. Forking, embedding, etc., are all still permitted.
StreamBright 7y ago
>> If you think that the Cockroach Labs, Redis Labs, Mongos, Elastics, etc., of the world provide a net benefit to the software world Elastic is an exception though, I think Lucene would be a better addition to that list.
manigandham 7y ago
I disagree. Services are worth far more than software. That's what cloud/SaaS is all about. AWS is rising to meet the demand by customers paying lots of money to have their problems solved, not worry about software licenses and operations. I trust the creator to run a hosted service better than a generic cloud provider, but most don't which is a failure of their own making. A few companies like Redis Labs and MongoDB have figured this out but most are still stuck writing code when customers are asking for managed services. I don't know why they don't adapt.
- anderspitman 7y ago
  The article specifically mentioned that the integrations AWS can offer between services simply cannot be competed with by any single company, no matter how good that company makes their own hosted product.
  - manigandham 7y ago
    Yea, that sounds like an excuse. The APIs are all public. The company can build whatever integrations they want to offer. For example, many already use EC2, VPCs, S3, Lambda, Kinesis, etc. to extend their databases into a client's architecture, and it's no different than what AWS provides.
    - anderspitman 7y ago
      But you're essentially saying if you want to compete with AWS, you have to offer every feature and integration they offer. Good luck to any startup attempting that.
      - no_wizard 7y ago
        I wonder if a startup opportunity exists to be a B2B only provider that has all the infrastructure trappings of an AWS or Google Cloud, but never selling directly your services on the open market, but instead selling your services contractually to other businesses (in a sense, not sure if my terms are lining up here). If this is a million dollar idea, I'm just going to give it away I guess, so here goes nothing in explaining it! Imagine an AWS/Google Cloud like company that only sells B2B, so Cockroach for instance, could pay this company to host their own cloud offerings, plus sell through other cloud offerings of the said B2B service but under their marketing umbrella. The B2B service gets a nice chunk for administration et. el plus some fixed percentage of gross (maybe? i dunno what it'd look like). I think if you contractually obligate yourself as a business to never sell cloud services directly (only via partners like, in this instance of theory, cockroachDB, but it could redis, mongo, whatever), it'd be a fairly stable and comfortable arrangement. Could also be a way for other SAAS companies to buy into infrastructure without indirectly funding a potential competitor too. Maybe its too complicated to achieve, though.
dragonwriter 7y ago
> but with cloud computing becoming an increasingly winner-take-all market, it leaves little room for the software's authors to generate revenue via hosted offerings of their software. There simply has been no time where a startup doing SaaS of open source software (whether it's own or someone else's) had a strong route to profitability; this isn't an emergent property of evolving market conditions. It's perhaps being acutely recognized because there was a particular time when companies started around open source software and, either initially or after a period with no clear business model, adopted “we’ll do SaaS of our core open source offering” as the whole, or a central piece, of their business model, and pretty quickly realized why, despite hosted SaaS being a commercial reality longer than cloud computing has even been an idea, SaaS of a particular open source software product—while sometimes part of the business of a broader SaaS provider—has never been a common successful standalone business model supporting companies centered around the open source offering, and certainly not for company is looking for the kind of growth modern VC-backed startups hope for. They like to spin stories about AWS being predatory, evolving conditions in the cloud market, and attacking open source, but the real issue isn't with AWS, or cloud computing except insofar as that happens to the modern place where hosted SaaS is found, but that they've adopted a combination of SaaS-centric business model and growth expectations that would never have been realistic with open source software (and which I suspect they will next discover isn't much more realistic with their new relatively liberal proprietary license model either.) > If you think that the Cockroach Labs, Redis Labs, Mongos, Elastics, etc., of the world provide a net benefit to the software world, I think you have to contend with the fact that there is going to be fewer such companies in the future if AWS keeps eating their lunch. Software that serves as underlying infrastructure for other software has value to end-users that is with reduced by risks associated with being proprietary, and but also has value to it't is reduced by the non-exclusivity that exists when it is not. That's fairly obvious, and an intrinsic problem for such software being efficiently provided in a basically capitalist system, but unless one’s ideological preconceptions make it difficult to accept that capitalism may not always be as perfectly efficient as it would seem to be in theory under the kind of ideal assumptions sometimes encountered in Econ 101 classes, or unless one has invested in firms without business models which ignore this dilemma, I don't see how that is anything to “contend” lwith.

by dhd415 7y ago

fossuser 7y ago

It'd be interesting if there was a way to specifically require AWS, Azure, Google Cloud (or more generally any cloud hosting reseller) to pay if they use the open source software or any derivative of it (or if they create any company which then uses it) for the purposes of reselling it to others. Basically give the open source project a 30% cut if you're going to resell it (or fork and resell it). It might be hard to do now since with AWS since with ES Amazon just forked whatever version was already permissively licensed, but it may be interesting to create a new license to protect against this for new OSS projects.

nradov 7y ago
You can put any license on your software that you want, but a license that required revenue sharing wouldn't really count as "open source".
- alfonsodev 7y ago
  I understand what you mean and totally agree with you, I just feel the need to remind (not to you) the term free software, as many things are open source but not free software [1] [1] https://www.gnu.org/philosophy/open-source-misses-the-point.en.html https://www.gnu.org/philosophy/open-source-misses-the-point....
  - elcritch 7y ago
    Unless the AGPL becomes the new GNU default, "free" software is largely moot as well in the age of SaaS.
    - AsyncAwait 7y ago
      Most software I use daily is (luckily) not SaaS and as for AGPL being the default, for SaaS free software that's already pretty much the case today.
  - dragonwriter 7y ago
    > I understand what you mean and totally agree with you, I just feel the need to remind (not to you) the term free software, as many things are open source but not free software [ Open Source and Free Software are, as your link points out from the latter side, divergent ideologies, but they aren't substantively different in terms of concrete meaning when it comes to licensing. It is absolutely not the case that “many things” are Open Source but not Free Software, though many projects producing software which is both Free and Open Source adhere to only one of those ideologies, at least as the projects dominant ideology.
- erikpukinskis 7y ago
  Deleted
  - RcouF1uZ4gsC 7y ago
    >Secondly, there are many open source licenses which are not GPL, including licenses with no redistribution rights at all. I believe the correct term for those licenses is "shared source" not open source.
jasode 7y ago
>, but it may be interesting to create a new license to protect against this for new OSS projects. Well, you also have to take the game theory of incentives into account. Let's say you develop a new database called NextGenCockroachDB with a required 30% royalty license. That type of license will alter the behavior of people evaluating it and may very well prevent it from being adopted at all. If there's no critical mass of the market using it, the 30% royalty becomes a moot point. The whole market of choices available to economic participants has to be analyzed. If potential buyers have an option to substitute a db with 30% fee with another open source db with $0 license, they will be incentivized to avoid paying 30%. If an open source db requires royalty payments from cloud platforms, it will need to have amazing technology that nobody else can duplicate.
- ivalm 7y ago
  And even if you have some tech advantage, it still needs to compete with 0 cost license + increased infrastructure (since licensing dollars can now be spent on more hardware; 30% more hardware is hard to beat).
batbomb 7y ago
The $100MM Revenue License... Once your company surpasses $100MM in revenue you have to negotiate licensing terms.
- sangnoir 7y ago
  How many engineers can be paid from $100MM revenue?[0] The *aaS company might be better served by employing engineering team to maintain their fork/API-compatible clean-room implementation a-la Amazon Aurora. 0. If company is profitable and licensing costs > overall salaries + monetary value of controlling roadmap.
  - deleted 7y ago
    [deleted]
monocularvision 7y ago
Isn’t that exactly what they are doing and saying in this blog post?
dantheman 7y ago
A 30% cut of what? The core costs are in the deployment of the servers, network, security, management, etc.
- ForHackernews 7y ago
  Most developers would prefer a 30% cut of profits, not a 30% liability of costs, I'd assume.
dragonwriter 7y ago
> It'd be interesting if there was a way to specifically require AWS, Azure, Google Cloud (or more generally any cloud hosting reseller) to pay if they use the open source software or any derivative of it No, such a requirement makes it not OSS.

DannyBee 7y ago

The problem with this argument is that there has always been a before and after. IE This is not the first business model issue OSS has dealt with. For example: It seems ridiculous now, but at one point authors were significantly squeezed by commercial distros offering support and feature work directly to customers for their packages. (And this was even a similar kind of disintermediation applied to authors as you see now - people only cared what they got from redhat, not from the original author) One interesting constant is that most of the projects that felt a need to change licensing to react to business model issues over the years are dead ;) . Not all of them, mind you. But the failure rate seems really really high. The underlying issue here in this one is that people (apparently so far!) want to use AWS/GCP/etc more than they want to use mongo, redis, cockroach, or any particular technology. No license change will fix that. In that case, AWS actually controls your customer more than you do. Unless something comes along that is "better enough" that people are willing to buck AWS to use it, this approach of relicensing fails. (and the customers certainly don't care about your licensing scheme)

OJFord 7y ago
> The underlying issue here in this one is that people (apparently so far!) want to use AWS/GCP/etc more than they want to use mongo, redis, cockroach, or any particular technology. > No license change will fix that. Well, perhaps not a licence change, but if it's good enough that it's The One the provider wants, but it can't offer it under the terms of the licence, then paying for it under a separate licence could be a win for both parties.
- sangnoir 7y ago
  Depending on the licensing cost and the effort required to integrate the project with their infrastructure, it might be cheaper for the provider to fork the last version before the relicense and support it going forward. Maintaining API/wire-protocol compatibility isn't that hard for large tech companies these licenses are trying to battle. I don't think these open source companies are not aware of the risk of forking, but they are between a rock (AWS/GCP) and a hard place (VC returns demands).

tdb7893 7y ago

I think from a practical perspective this makes sense but having to change their licenses makes me sad. I don't want to see licenses change from "you can do whatever you want with this" to "you can do whatever you want with this unless you are competing with us".

dhd415 7y ago
To be fair, they're forbidding only one specific form of competition- managed hosting. Forking, embedding, etc., are all still permitted.

StreamBright 7y ago

>> If you think that the Cockroach Labs, Redis Labs, Mongos, Elastics, etc., of the world provide a net benefit to the software world Elastic is an exception though, I think Lucene would be a better addition to that list.

manigandham 7y ago

I disagree. Services are worth far more than software. That's what cloud/SaaS is all about. AWS is rising to meet the demand by customers paying lots of money to have their problems solved, not worry about software licenses and operations. I trust the creator to run a hosted service better than a generic cloud provider, but most don't which is a failure of their own making. A few companies like Redis Labs and MongoDB have figured this out but most are still stuck writing code when customers are asking for managed services. I don't know why they don't adapt.

anderspitman 7y ago
The article specifically mentioned that the integrations AWS can offer between services simply cannot be competed with by any single company, no matter how good that company makes their own hosted product.
- manigandham 7y ago
  Yea, that sounds like an excuse. The APIs are all public. The company can build whatever integrations they want to offer. For example, many already use EC2, VPCs, S3, Lambda, Kinesis, etc. to extend their databases into a client's architecture, and it's no different than what AWS provides.
  - anderspitman 7y ago
    But you're essentially saying if you want to compete with AWS, you have to offer every feature and integration they offer. Good luck to any startup attempting that.
    - no_wizard 7y ago
      I wonder if a startup opportunity exists to be a B2B only provider that has all the infrastructure trappings of an AWS or Google Cloud, but never selling directly your services on the open market, but instead selling your services contractually to other businesses (in a sense, not sure if my terms are lining up here). If this is a million dollar idea, I'm just going to give it away I guess, so here goes nothing in explaining it! Imagine an AWS/Google Cloud like company that only sells B2B, so Cockroach for instance, could pay this company to host their own cloud offerings, plus sell through other cloud offerings of the said B2B service but under their marketing umbrella. The B2B service gets a nice chunk for administration et. el plus some fixed percentage of gross (maybe? i dunno what it'd look like). I think if you contractually obligate yourself as a business to never sell cloud services directly (only via partners like, in this instance of theory, cockroachDB, but it could redis, mongo, whatever), it'd be a fairly stable and comfortable arrangement. Could also be a way for other SAAS companies to buy into infrastructure without indirectly funding a potential competitor too. Maybe its too complicated to achieve, though.

dragonwriter 7y ago

> but with cloud computing becoming an increasingly winner-take-all market, it leaves little room for the software's authors to generate revenue via hosted offerings of their software. There simply has been no time where a startup doing SaaS of open source software (whether it's own or someone else's) had a strong route to profitability; this isn't an emergent property of evolving market conditions. It's perhaps being acutely recognized because there was a particular time when companies started around open source software and, either initially or after a period with no clear business model, adopted “we’ll do SaaS of our core open source offering” as the whole, or a central piece, of their business model, and pretty quickly realized why, despite hosted SaaS being a commercial reality longer than cloud computing has even been an idea, SaaS of a particular open source software product—while sometimes part of the business of a broader SaaS provider—has never been a common successful standalone business model supporting companies centered around the open source offering, and certainly not for company is looking for the kind of growth modern VC-backed startups hope for. They like to spin stories about AWS being predatory, evolving conditions in the cloud market, and attacking open source, but the real issue isn't with AWS, or cloud computing except insofar as that happens to the modern place where hosted SaaS is found, but that they've adopted a combination of SaaS-centric business model and growth expectations that would never have been realistic with open source software (and which I suspect they will next discover isn't much more realistic with their new relatively liberal proprietary license model either.) > If you think that the Cockroach Labs, Redis Labs, Mongos, Elastics, etc., of the world provide a net benefit to the software world, I think you have to contend with the fact that there is going to be fewer such companies in the future if AWS keeps eating their lunch. Software that serves as underlying infrastructure for other software has value to end-users that is with reduced by risks associated with being proprietary, and but also has value to it't is reduced by the non-exclusivity that exists when it is not. That's fairly obvious, and an intrinsic problem for such software being efficiently provided in a basically capitalist system, but unless one’s ideological preconceptions make it difficult to accept that capitalism may not always be as perfectly efficient as it would seem to be in theory under the kind of ideal assumptions sometimes encountered in Econ 101 classes, or unless one has invested in firms without business models which ignore this dilemma, I don't see how that is anything to “contend” lwith.