8 ms·

Hi, this is Yiftach, CTO and Co-founder of Redis Labs. First, let me assure you that Redis remains and always will remain, open source, BSD license. For avoidin

Hi, this is Yiftach, CTO and Co-founder of Redis Labs. First, let me assure you that Redis remains and always will remain, open source, BSD license. For avoiding any doubt - commons clause (as defined in commonsclause.com) is applied only to add-ons (modules), on top of Redis (e.g. RediSearch, Redis Graph, ReJSON, Redis-ML, Rebloom) that were developed by Redis Labs . We initially released these modules under AGPL license but found two major drawbacks (a) AGPL does not prevent cloud providers (such as AWS) from building managed services from these modules, and (b) we got requests from developers, working at large enterprises to move from AGPL to a more permissive license, because the use of AGPL is against their company’s policy. In addition, a few people here (and other threads) have asked why we didn’t create a new proprietary license, like those offered by Elastic or MaraiaDB? Well, Commons Clause was created by a coalition of several OSS infrastructure companies, some of which use a different OSS licenses. In order to maintain a standard framework we decided to piggyback the restriction (on creating managed services by cloud providers) on any existing OSS license.

dragonwriter 8y ago
> we got requests from developers, working at large enterprises to move from AGPL to a more permissive license ...so you did exactly the opposite, though with naming that makes it sound like you honored that request until you actually read the license terms.
- detaro 8y ago
  it's more permissive for some enterprise use cases if you're worried about AGPL consequences. You now can use it in internal systems. (Assuming you feel comfortable interpreting the vague bits of the "Commons Clause")
  - IshKebab 8y ago
    Yeah the commons clause does not seem like a very well written license. They even mix up i.e. and e.g. Not confidence-inspiring.
zokier 8y ago
First of all, I do appreciate your reply here. > we got requests from developers, working at large enterprises to move from AGPL to a more permissive license, because the use of AGPL is against their company’s policy. It's not clear how Commons Clause will help here. I can't imagine many corporations liking Commons Clause if they have decided against AGPL.
- Yiftach 8y ago
  Well, we already have positive responses from few large enterprises.
- antirez 8y ago
  I think that what happens here is that enterprises don't like a license where there is this concept of open sourcing internal changes. They are happier with limiting the kind of use you can do with the code instead, like doing SaaS, that most of them don't plan to do at all.
  - pritambaral 8y ago
    AGPL doesn't require releasing internal changes unless the changed code is served (like in SaaS) externally. Organizations are free to internally modify, run, and distribute changes to AGPL code as long as the modified code is made available on the internal network.
    - ecnahc515 8y ago
      Im generally curious, what's the definition of "externally"? It's a bit more vague compared to "operating as a service", since you may expose your service externally, but only allow access to internal users.
      - pritambaral 8y ago
        The license itself doesn't treat "externally" different from "internally". Its terms are simple: any one who uses it should have a way to get the source. If you let someone "external" to the company use the software over a network, then, during their use, they should have a way to get the source. If you don't let any one "external" connect to the service, then there's no need for you to provide them a way to get the source. ----- For example, if there were a software like redis, but one that were licensed under the GNU AGPLv3 — say 'gredis' — and you let someone connect to it — say, using 'gredis-cli' — then you must make the source available to them. But if you run this 'gredis' software in your stack and make use of it in your stack but don't let anyone except your ops team connect to the running 'gredis' instances, then you need make your source available only to your ops team.
rectang 8y ago
Thank you for the explanation. I see no problem with this approach in principle and wish your business the best of luck. However, you have made a big mistake with how the "Commons Clause" confuses Open Source under the OSD with "source available". You were not well served by those who advised you to do so.
- XiZhao 8y ago
  The Commons Clause clearly acknowledges this in the FAQ: https://commonsclause.com/ https://commonsclause.com/
  - nailer 8y ago
    From that page: > The Commons Clause is a license condition drafted by Heather Meeker that applies a minimal-form commercial restriction on top of an existing open source license Making it proprietary and failing the Open Source Definition. You cannot have Commons Clause 'on top' of an existing Open Source license. This is impossible. You can only replace the existing Open Source license with Commons Clause. The page is a bunch of (insert HN-guidelines-appropriate word for 'very incorrect information'). > This Clause is not intended to be applied against at-scale existing open source projects, but incrementally on top of commercial counterparts that need to be transitioned to source-availability to satisfy urgent business or legal requirements. Commercial and Open Source aren't opposites - this a very basic mistake made by people who are new to OSS. There are many Open Source commercial projects (your bank runs on Red Hat Linux, which is entirely OSS, with everything but the Red Hat logos allowed to be reproduced) and many non-commercial proprietary projects. It's scary that a company called 'Fossa' whose specialty is 'Modern open source management_' is confused about this. > The original Open Source Definition represents an immensely important set of ideals that carried many projects to success during the earlier days. However, the open source ecosystem has changed a lot over the past 10 years, and the conditions of the modern landscape has forced change for the sustainability of many projects. The project wants to create a new OSD which isn't Open Source. The 'drafter' of this license seems to have simply re-created Shared Source per Ballmer-era Microsoft.
    - 8y ago
detaro 8y ago
BTW, you should probably change https://redislabs.com/community/oss-projects/ https://redislabs.com/community/oss-projects/ to match the the non-Open-Source-licenses most things have there. (yes, they are listed, but the page pretends everything on it is Open Source)
- lazyloop 8y ago
  You're mixing up Open Source and Free Software, those two are not the same.
  - ramshorns 8y ago
    They have different ideologies behind them, but they refer to almost exactly the same class of software. A license that doesn't allow commercial use is proprietary and closed source.
    - Spivak 8y ago
      Forbidding commercial use doesn't make something closed source but it does make it proprietary. The compliment of Open Source isn't closed source.
      - ramshorns 8y ago
        Can you give an example of something that's neither open source nor closed source, or of something that's both open source and closed source?
        Spivak 8y ago
        Gitlab EE is one. Not closed source since the source is public and freely given [1]. Not open source because the license [2] forbids use based on field of endeavor which is required in the OSD [3]. [1] https://gitlab.com/gitlab-org/gitlab-ee https://gitlab.com/gitlab-org/gitlab-ee [2] https://gitlab.com/gitlab-org/gitlab-ee/blob/master/LICENSE https://gitlab.com/gitlab-org/gitlab-ee/blob/master/LICENSE [3] https://opensource.org/osd-annotated https://opensource.org/osd-annotated Not that Wikipedia is a source of truth but it does corroborate that at least some other people agree with this analysis [4]. [4] https://simple.wikipedia.org/wiki/Closed_source https://simple.wikipedia.org/wiki/Closed_source Edit: As for the other direction, you can't have software be Open Source and closed source simultaneously since being Open Source requires the source to be available. Or in symbols. Free Software ⊆ Open Source ⊆ source-available closed source ∪ source-available = 𝕌 closed source ∩ source-available = ∅
deleted 8y ago
[deleted]
nmjohn 8y ago
> because the use of AGPL is against their company’s policy. Have you confirmed with these same people that the new license is allowed by their company policies?
- Yiftach 8y ago
  Believe it or not - the answer is 'yes'
  - antirez 8y ago
    I don't think this is strange at all btw, https://news.ycombinator.com/item?id=17819769 https://news.ycombinator.com/item?id=17819769
Cursuviam 8y ago
Hmmm, I wonder if you could use a license even more virulent than the AGPL to approach problem (a) and then dual license to solve (b)
baybal2 8y ago
>from AGPL to a more permissive license, because the use of AGPL is against their company’s policy. But to effect, it is the same. The point of them restricting use of AGPL is them not wanting to publish the code while making money of it. To the effect, they still can't make money of it.
mindcrime 8y ago
In order to maintain a standard framework we decided to piggyback the restriction (on creating managed services by cloud providers) on any existing OSS license. And that was a bad decision and it needs to be reverted. What you're doing is dishonest, point blank. If you don't want to write a new license from scratch, take one of the ones off this list, and fork it and make a "Redis Non-Commercial License" or whatever you want to call it. https://en.wikipedia.org/wiki/Source-available_software#Restricted_licenses https://en.wikipedia.org/wiki/Source-available_software#Rest...
ccleve 8y ago
Yiftach (and Antirez), Please talk more about AGPL. MongoDB has a similar problem, and they solved it by making their product dual-licensed, AGPL + commercial. They then clarified the AGPL to say that in their opinion, it did in fact prevent cloud providers from building managed services around the modules. https://www.mongodb.com/community/licensing/faq https://www.mongodb.com/community/licensing/faq The AGPL is lengthy and a bit convoluted, so it's possible they're wrong. Could you talk through your reasoning?
- Yiftach 8y ago
  Well - I can only say that what MongoDB has is not complete. There are still many holes, and we prefer to avoid them. And of course this doesn't solve the other issue, where developers cannot use AGPL in large enterprises.
  - yeahforsureman 8y ago
    The actual wording of the Commons Clause is very general and ambiguous. I'd be surprised if this didn't continue to cause issues within large enterprises.
  - cercatrova 8y ago
    Couldn't you sell them the commercially licensed version then, if you had the AGPL + commercial dual license?
  - ccleve 8y ago
    But that's kind of the point -- those who live in large enterprises who can't use the AGPL must buy a commercial license. The AGPL is toxic in some places, and its use is a deliberate attempt to nudge people toward a commercial license. Did this not work in your case?
  - sqrt17 8y ago
    > where developers cannot use AGPL in large enterprises developers who cannot use AGPL in large enterprises are probably forbidden to use non-open-source software distributed under a shared-source license that allows no commercial use. A non-charitable reading would be "we want mindshare and adoption from developers in large enterprises who will then buy or software rather than admit that they were unable to understand our terms and assumed our software was liberal open source". To make things more concrete - while GPL allows unrestricted internal use, the horror scenario would be the contractor who is brought in to work on software including GPLd code and who may have right to receiving the source of everything (as a "derived work"). How is CommonsClause-licensed shared source dealing with large enterprises employing contractors for working with their software? Is the contractor in breach of CommonsClause but the large enterprise isn't?
JaimeThompson 8y ago
"commons clause (as defined in commonsclause.com) " That is subject to change so without a specific version number / date it is effectively useless as a guide.
danieldk 8y ago
We initially released these modules under AGPL license but found two major drawbacks (a) AGPL does not prevent cloud providers (such as AWS) from building managed services from these modules, Aren't there good solutions within open source licenses? I agree that the AGPL does not solve the stated issue. However, the Apache License version 2.0 has the following text: If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. [...] I typically use the Apache License version 2 and include a NOTICE file with something like This software contains portions of XYZ, which was developed by Daniël de Kok. I do get contacted every once in a while by a company that wants to use my software, but does not want to include this notice in their software/documentation and offer to pay to remove the notice. You could even make it a bit nefarious like: This software uses XYZ, but your software/service vendor is a cheapskate that leaches off XYZ and kills puppies by not contributing back to XYZ. And offer the option to obtain a (proprietary) license that allows use with removal of the notice. IANAL, and I don't know if the Apache License's NOTICE wording also covers use in cloud services (it seems so). If not, it would be an easy extension. And the outcome is much better than the abomination that Commons Clause is: the software stays open source and it puts pressure on downstream users to contribute back.
e12e 8y ago
> AGPL license but found two major drawbacks (a) AGPL does not prevent cloud providers (such as AWS) from building managed services from these modules I'm not sure I understand this formulation. The * gp licenses are generally focused on defending the four freedoms[f] - and freedom zero is the freedom to run the software. How would anyone think that a * gp license would prevent that? Am I correct in my interpretation that Redis Labs' original intention was to charge a fee for these modules, and in the case of various form of re-sales (like SaaS) - to partner with providers so that there was a revenue split? I'm asking, not because I'm against commercial software (although I do prefer to run Free software) - but just to make sure I understand the [ed:"drawbacks"] of the AGPL as Redis Labs sees it? [f] https://www.gnu.org/philosophy/free-sw.en.html https://www.gnu.org/philosophy/free-sw.en.html
- legohead 8y ago
  GNU licenses require sharing code. Bad for business.
  - johannes1234321 8y ago
    For GPL (not talking AGPL as my knowledge there is too limited) Vendors in "classical" environments GPL is a valid business choice - competitors get access to the code, but also have to share their extensions. The original vendor however can be in a stronger position and share their extensions commercially (with dual licensing and CLAs for external contributions) In a cloud environment however the cloud vendor doesn't "redistribute" the software, thus doesn't have to share their extensions, thus taking revenues without any contributions, putting the cloud vendor in an even better position as the original vendor, as the original vendor pays for the maintenance of the core product, which the cloud vendor uses for free.
    - e12e 8y ago
      And the main trust of the AGPL is treating giving access to a running program, as traditional GPL "distribution" - code must be made available to users of a service upon request - along with any changes. With GPL - for example - Amazon could freely customize the Linux kernel with a new software defined networking stack for use by s3 back-end services. And would be free not to share the changes. If the kernel was under AGPL users of s3 would have a legal right to see the changes.
deleted 8y ago
[deleted]
kfogel 8y ago
"...a few people here (and other threads) have asked why we didn't create a new proprietary license..." But, you did create a new proprietary license. That's what ${ANY_OPEN_SOURCE_LICENSE} + COMMONS_CLAUSE is. All this is is a proprietary fork of Redis. It's no different than if someone else -- someone other than Redis Labs -- had done it. What's unusual here is just the reluctance on Redis Labs' part to call it what it is. I think a lot of the surprise and blowback across the Net is simply because of the strange unwillingness on Redis Labs' part to call this by its right name and own it.
- deleted 8y ago
  [deleted]
irabinovitch1 8y ago
I'm not sure I follow here... a) Is there an example of a cloud provider adopting or building on top of your existing AGPL code bases? The big 3 all have fairly well known internal policies that forbid AGPL use. Ever wonder why there isn't there a MongoDB service being offered by any of the major cloud providers? AGPL. All that being said I doubt they would want your modules anyways. Their track record tends to be: * AWS would grab the core BSD licensed project, ignore your management tooling regardless of license, and build their own management tooling that integrates with their ecosystem. Theres a few exceptions to this like [Chef and AWS on OpsWorks](https://twitter.com/adamhjk/status/1032312528196575234 https://twitter.com/adamhjk/status/1032312528196575234). * Google. They wont use your software either. If anything they'll build some wizbang redis like protocol and interface on one of their internal proprietary databases. All the software will work the same, but it'll be "better" because its powered by BigTable/Spanner/whatever. * Microsoft. 50/50 shot they might actually just license your code and partner if they thought customers wanted it. b) I'm not surprised that large customers aren't AGPL fans. Isn't this where they should come in with a dual-license approach and sell commercial licenses to the software you develop? So whats the win here?

dragonwriter 8y ago

> we got requests from developers, working at large enterprises to move from AGPL to a more permissive license ...so you did exactly the opposite, though with naming that makes it sound like you honored that request until you actually read the license terms.

detaro 8y ago
it's more permissive for some enterprise use cases if you're worried about AGPL consequences. You now can use it in internal systems. (Assuming you feel comfortable interpreting the vague bits of the "Commons Clause")
- IshKebab 8y ago
  Yeah the commons clause does not seem like a very well written license. They even mix up i.e. and e.g. Not confidence-inspiring.

zokier 8y ago

First of all, I do appreciate your reply here. > we got requests from developers, working at large enterprises to move from AGPL to a more permissive license, because the use of AGPL is against their company’s policy. It's not clear how Commons Clause will help here. I can't imagine many corporations liking Commons Clause if they have decided against AGPL.

Yiftach 8y ago
Well, we already have positive responses from few large enterprises.
antirez 8y ago
I think that what happens here is that enterprises don't like a license where there is this concept of open sourcing internal changes. They are happier with limiting the kind of use you can do with the code instead, like doing SaaS, that most of them don't plan to do at all.
- pritambaral 8y ago
  AGPL doesn't require releasing internal changes unless the changed code is served (like in SaaS) externally. Organizations are free to internally modify, run, and distribute changes to AGPL code as long as the modified code is made available on the internal network.
  - ecnahc515 8y ago
    Im generally curious, what's the definition of "externally"? It's a bit more vague compared to "operating as a service", since you may expose your service externally, but only allow access to internal users.
    - pritambaral 8y ago
      The license itself doesn't treat "externally" different from "internally". Its terms are simple: any one who uses it should have a way to get the source. If you let someone "external" to the company use the software over a network, then, during their use, they should have a way to get the source. If you don't let any one "external" connect to the service, then there's no need for you to provide them a way to get the source. ----- For example, if there were a software like redis, but one that were licensed under the GNU AGPLv3 — say 'gredis' — and you let someone connect to it — say, using 'gredis-cli' — then you must make the source available to them. But if you run this 'gredis' software in your stack and make use of it in your stack but don't let anyone except your ops team connect to the running 'gredis' instances, then you need make your source available only to your ops team.

rectang 8y ago

Thank you for the explanation. I see no problem with this approach in principle and wish your business the best of luck. However, you have made a big mistake with how the "Commons Clause" confuses Open Source under the OSD with "source available". You were not well served by those who advised you to do so.

XiZhao 8y ago
The Commons Clause clearly acknowledges this in the FAQ: https://commonsclause.com/ https://commonsclause.com/
- nailer 8y ago
  From that page: > The Commons Clause is a license condition drafted by Heather Meeker that applies a minimal-form commercial restriction on top of an existing open source license Making it proprietary and failing the Open Source Definition. You cannot have Commons Clause 'on top' of an existing Open Source license. This is impossible. You can only replace the existing Open Source license with Commons Clause. The page is a bunch of (insert HN-guidelines-appropriate word for 'very incorrect information'). > This Clause is not intended to be applied against at-scale existing open source projects, but incrementally on top of commercial counterparts that need to be transitioned to source-availability to satisfy urgent business or legal requirements. Commercial and Open Source aren't opposites - this a very basic mistake made by people who are new to OSS. There are many Open Source commercial projects (your bank runs on Red Hat Linux, which is entirely OSS, with everything but the Red Hat logos allowed to be reproduced) and many non-commercial proprietary projects. It's scary that a company called 'Fossa' whose specialty is 'Modern open source management_' is confused about this. > The original Open Source Definition represents an immensely important set of ideals that carried many projects to success during the earlier days. However, the open source ecosystem has changed a lot over the past 10 years, and the conditions of the modern landscape has forced change for the sustainability of many projects. The project wants to create a new OSD which isn't Open Source. The 'drafter' of this license seems to have simply re-created Shared Source per Ballmer-era Microsoft.
  - 8y ago

detaro 8y ago

BTW, you should probably change https://redislabs.com/community/oss-projects/ https://redislabs.com/community/oss-projects/ to match the the non-Open-Source-licenses most things have there. (yes, they are listed, but the page pretends everything on it is Open Source)

lazyloop 8y ago
You're mixing up Open Source and Free Software, those two are not the same.
- ramshorns 8y ago
  They have different ideologies behind them, but they refer to almost exactly the same class of software. A license that doesn't allow commercial use is proprietary and closed source.
  - Spivak 8y ago
    Forbidding commercial use doesn't make something closed source but it does make it proprietary. The compliment of Open Source isn't closed source.
    - ramshorns 8y ago
      Can you give an example of something that's neither open source nor closed source, or of something that's both open source and closed source?
      - Spivak 8y ago
        Gitlab EE is one. Not closed source since the source is public and freely given [1]. Not open source because the license [2] forbids use based on field of endeavor which is required in the OSD [3]. [1] https://gitlab.com/gitlab-org/gitlab-ee https://gitlab.com/gitlab-org/gitlab-ee [2] https://gitlab.com/gitlab-org/gitlab-ee/blob/master/LICENSE https://gitlab.com/gitlab-org/gitlab-ee/blob/master/LICENSE [3] https://opensource.org/osd-annotated https://opensource.org/osd-annotated Not that Wikipedia is a source of truth but it does corroborate that at least some other people agree with this analysis [4]. [4] https://simple.wikipedia.org/wiki/Closed_source https://simple.wikipedia.org/wiki/Closed_source Edit: As for the other direction, you can't have software be Open Source and closed source simultaneously since being Open Source requires the source to be available. Or in symbols. Free Software ⊆ Open Source ⊆ source-available closed source ∪ source-available = 𝕌 closed source ∩ source-available = ∅

deleted 8y ago

[deleted]

nmjohn 8y ago

> because the use of AGPL is against their company’s policy. Have you confirmed with these same people that the new license is allowed by their company policies?

Yiftach 8y ago
Believe it or not - the answer is 'yes'
- antirez 8y ago
  I don't think this is strange at all btw, https://news.ycombinator.com/item?id=17819769 https://news.ycombinator.com/item?id=17819769

Cursuviam 8y ago

Hmmm, I wonder if you could use a license even more virulent than the AGPL to approach problem (a) and then dual license to solve (b)

baybal2 8y ago

>from AGPL to a more permissive license, because the use of AGPL is against their company’s policy. But to effect, it is the same. The point of them restricting use of AGPL is them not wanting to publish the code while making money of it. To the effect, they still can't make money of it.

mindcrime 8y ago

In order to maintain a standard framework we decided to piggyback the restriction (on creating managed services by cloud providers) on any existing OSS license. And that was a bad decision and it needs to be reverted. What you're doing is dishonest, point blank. If you don't want to write a new license from scratch, take one of the ones off this list, and fork it and make a "Redis Non-Commercial License" or whatever you want to call it. https://en.wikipedia.org/wiki/Source-available_software#Restricted_licenses https://en.wikipedia.org/wiki/Source-available_software#Rest...

ccleve 8y ago

Yiftach (and Antirez), Please talk more about AGPL. MongoDB has a similar problem, and they solved it by making their product dual-licensed, AGPL + commercial. They then clarified the AGPL to say that in their opinion, it did in fact prevent cloud providers from building managed services around the modules. https://www.mongodb.com/community/licensing/faq https://www.mongodb.com/community/licensing/faq The AGPL is lengthy and a bit convoluted, so it's possible they're wrong. Could you talk through your reasoning?

Yiftach 8y ago
Well - I can only say that what MongoDB has is not complete. There are still many holes, and we prefer to avoid them. And of course this doesn't solve the other issue, where developers cannot use AGPL in large enterprises.
- yeahforsureman 8y ago
  The actual wording of the Commons Clause is very general and ambiguous. I'd be surprised if this didn't continue to cause issues within large enterprises.
- cercatrova 8y ago
  Couldn't you sell them the commercially licensed version then, if you had the AGPL + commercial dual license?
- ccleve 8y ago
  But that's kind of the point -- those who live in large enterprises who can't use the AGPL must buy a commercial license. The AGPL is toxic in some places, and its use is a deliberate attempt to nudge people toward a commercial license. Did this not work in your case?
- sqrt17 8y ago
  > where developers cannot use AGPL in large enterprises developers who cannot use AGPL in large enterprises are probably forbidden to use non-open-source software distributed under a shared-source license that allows no commercial use. A non-charitable reading would be "we want mindshare and adoption from developers in large enterprises who will then buy or software rather than admit that they were unable to understand our terms and assumed our software was liberal open source". To make things more concrete - while GPL allows unrestricted internal use, the horror scenario would be the contractor who is brought in to work on software including GPLd code and who may have right to receiving the source of everything (as a "derived work"). How is CommonsClause-licensed shared source dealing with large enterprises employing contractors for working with their software? Is the contractor in breach of CommonsClause but the large enterprise isn't?

JaimeThompson 8y ago

"commons clause (as defined in commonsclause.com) " That is subject to change so without a specific version number / date it is effectively useless as a guide.

danieldk 8y ago

We initially released these modules under AGPL license but found two major drawbacks (a) AGPL does not prevent cloud providers (such as AWS) from building managed services from these modules, Aren't there good solutions within open source licenses? I agree that the AGPL does not solve the stated issue. However, the Apache License version 2.0 has the following text: If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. [...] I typically use the Apache License version 2 and include a NOTICE file with something like This software contains portions of XYZ, which was developed by Daniël de Kok. I do get contacted every once in a while by a company that wants to use my software, but does not want to include this notice in their software/documentation and offer to pay to remove the notice. You could even make it a bit nefarious like: This software uses XYZ, but your software/service vendor is a cheapskate that leaches off XYZ and kills puppies by not contributing back to XYZ. And offer the option to obtain a (proprietary) license that allows use with removal of the notice. IANAL, and I don't know if the Apache License's NOTICE wording also covers use in cloud services (it seems so). If not, it would be an easy extension. And the outcome is much better than the abomination that Commons Clause is: the software stays open source and it puts pressure on downstream users to contribute back.

e12e 8y ago

> AGPL license but found two major drawbacks (a) AGPL does not prevent cloud providers (such as AWS) from building managed services from these modules I'm not sure I understand this formulation. The * gp licenses are generally focused on defending the four freedoms[f] - and freedom zero is the freedom to run the software. How would anyone think that a * gp license would prevent that? Am I correct in my interpretation that Redis Labs' original intention was to charge a fee for these modules, and in the case of various form of re-sales (like SaaS) - to partner with providers so that there was a revenue split? I'm asking, not because I'm against commercial software (although I do prefer to run Free software) - but just to make sure I understand the [ed:"drawbacks"] of the AGPL as Redis Labs sees it? [f] https://www.gnu.org/philosophy/free-sw.en.html https://www.gnu.org/philosophy/free-sw.en.html

legohead 8y ago
GNU licenses require sharing code. Bad for business.
- johannes1234321 8y ago
  For GPL (not talking AGPL as my knowledge there is too limited) Vendors in "classical" environments GPL is a valid business choice - competitors get access to the code, but also have to share their extensions. The original vendor however can be in a stronger position and share their extensions commercially (with dual licensing and CLAs for external contributions) In a cloud environment however the cloud vendor doesn't "redistribute" the software, thus doesn't have to share their extensions, thus taking revenues without any contributions, putting the cloud vendor in an even better position as the original vendor, as the original vendor pays for the maintenance of the core product, which the cloud vendor uses for free.
  - e12e 8y ago
    And the main trust of the AGPL is treating giving access to a running program, as traditional GPL "distribution" - code must be made available to users of a service upon request - along with any changes. With GPL - for example - Amazon could freely customize the Linux kernel with a new software defined networking stack for use by s3 back-end services. And would be free not to share the changes. If the kernel was under AGPL users of s3 would have a legal right to see the changes.

deleted 8y ago

[deleted]

kfogel 8y ago

"...a few people here (and other threads) have asked why we didn't create a new proprietary license..." But, you did create a new proprietary license. That's what ${ANY_OPEN_SOURCE_LICENSE} + COMMONS_CLAUSE is. All this is is a proprietary fork of Redis. It's no different than if someone else -- someone other than Redis Labs -- had done it. What's unusual here is just the reluctance on Redis Labs' part to call it what it is. I think a lot of the surprise and blowback across the Net is simply because of the strange unwillingness on Redis Labs' part to call this by its right name and own it.

deleted 8y ago
[deleted]

irabinovitch1 8y ago

I'm not sure I follow here... a) Is there an example of a cloud provider adopting or building on top of your existing AGPL code bases? The big 3 all have fairly well known internal policies that forbid AGPL use. Ever wonder why there isn't there a MongoDB service being offered by any of the major cloud providers? AGPL. All that being said I doubt they would want your modules anyways. Their track record tends to be: * AWS would grab the core BSD licensed project, ignore your management tooling regardless of license, and build their own management tooling that integrates with their ecosystem. Theres a few exceptions to this like [Chef and AWS on OpsWorks](https://twitter.com/adamhjk/status/1032312528196575234 https://twitter.com/adamhjk/status/1032312528196575234). * Google. They wont use your software either. If anything they'll build some wizbang redis like protocol and interface on one of their internal proprietary databases. All the software will work the same, but it'll be "better" because its powered by BigTable/Spanner/whatever. * Microsoft. 50/50 shot they might actually just license your code and partner if they thought customers wanted it. b) I'm not surprised that large customers aren't AGPL fans. Isn't this where they should come in with a dual-license approach and sell commercial licenses to the software you develop? So whats the win here?