5 ms·

The problem with agpl is that no companies want to touch it. It's too restrictive if you ever want to integrate something with your internal proprietary moneyma

The problem with agpl is that no companies want to touch it. It's too restrictive if you ever want to integrate something with your internal proprietary moneymaking code.

cercatrova 6y ago
Doesn't that accomplish the goal then? Make your project AGPL and with a commercial license, so only you will be able to make it a commercial business as other big cloud companies don't want to touch it.
- tormeh 6y ago
  The problem is that it is not truly impossible to integrate into a commercial company. It's more that the license practically requires a lawyer to look at exactly how it'll be used and approve that use. AWS certainly does not shy away from hosting AGPL software. It does prevent AWS from taking the code and running with it though, at least not without a shim. A more permissive license can lead to the Athena/Presto situation where Athena is, to my knowledge, a proprietary fork of Presto.
  - _msw_ 6y ago
    Disclosure: I work at AWS on infrastructure services I am personally currently unaware of any AGPLv3 licensed software in use in an AWS service. That said, I would be skeptical of advice to use AGPLv3 due to any particular organization's current policy on the license. Regarding Presto, work on the service includes changes that should go upstream. For the changes that are appropriate for upstream (e.g., ones that are generally useful, not only of benefit or interest to AWS), PRs are sent. For example: https://github.com/prestosql/presto/pulls?q=is%3Apr+author%3Apettyjamesm https://github.com/prestosql/presto/pulls?q=is%3Apr+author%3... Practically speaking, it is difficult to maintain a development branch of any software project with sufficient change velocity if you have a goal of continuing to integrate improvements from the upstream version.
    - tormeh 6y ago
      Redis changed from AGPL to Apache 2 with something they called a Commons Clause, then finally to Redis Source Available License because of cloud providers. Don't really know exactly which event triggered the change, though. I suppose it could have been GCP or Azure instead of AWS. Regardless, AGPL is far less restrictive than people claim it is. It is a particularly strict version of the GPL, but given proper legal review it is unproblematic to use commercially, which cuts both ways as Redis found out. I think there's a serious amount of FUD around it. I suppose it's because of how rare it is. With more usage, it would probably bee seen as less dangerous.
      - boogies 6y ago
        I agree that there’s a serious amount of FUD around it. I think it’s at least in part because it proliferating could seriously harm Alphabet’s ability to freely grab people’s code to incorporate in their consumer products (YouTube, G Suite, etc.) without reciprocating, and they’ve been careful to semi-subtly spread the FUD (ie. publish https://opensource.google/docs/using/agpl-policy/ https://opensource.google/docs/using/agpl-policy/). https://drewdevault.com/2020/07/27/Anti-AGPL-propaganda.html https://drewdevault.com/2020/07/27/Anti-AGPL-propaganda.html
        _msw_ 6y ago
        See also https://sfconservancy.org/blog/2020/jan/06/copyleft-equality/ https://sfconservancy.org/blog/2020/jan/06/copyleft-equality...
      - _msw_ 6y ago
        The core Redis code (originally announced on this site in 2009 [1], before Garantia Data started in 2011, or became Redis Labs in 2014) has always been BSD licensed. Only extensions from Redis Labs (e.g., Redis look) were licensed under AGPL, and changed to Commons Clause / Redis Source Available License. Those extensions were never part of an AWS cloud service. See also [2] [1] https://news.ycombinator.com/item?id=494649 https://news.ycombinator.com/item?id=494649 [2] https://redislabs.com/blog/redis-core-team-update/ https://redislabs.com/blog/redis-core-team-update/
- carlhjerpe 6y ago
  The problem is that Amazon could still do it, they're just on that scale, while most common companies would shy away as they don't have the Amazon budget for abusing AGPL right. I hope in the future the Elastic, TimeScale, Confluent and any other "fuck Amazon" license could be merged into one and kind of standardized on as many freedoms as possible, while keeping AWS out of it.

The problem with agpl is that no companies want to touch it. It's too restrictive if you ever want to integrate something with your internal proprietary moneymaking code.

cercatrova 6y ago

Doesn't that accomplish the goal then? Make your project AGPL and with a commercial license, so only you will be able to make it a commercial business as other big cloud companies don't want to touch it.

tormeh 6y ago
The problem is that it is not truly impossible to integrate into a commercial company. It's more that the license practically requires a lawyer to look at exactly how it'll be used and approve that use. AWS certainly does not shy away from hosting AGPL software. It does prevent AWS from taking the code and running with it though, at least not without a shim. A more permissive license can lead to the Athena/Presto situation where Athena is, to my knowledge, a proprietary fork of Presto.
- _msw_ 6y ago
  Disclosure: I work at AWS on infrastructure services I am personally currently unaware of any AGPLv3 licensed software in use in an AWS service. That said, I would be skeptical of advice to use AGPLv3 due to any particular organization's current policy on the license. Regarding Presto, work on the service includes changes that should go upstream. For the changes that are appropriate for upstream (e.g., ones that are generally useful, not only of benefit or interest to AWS), PRs are sent. For example: https://github.com/prestosql/presto/pulls?q=is%3Apr+author%3Apettyjamesm https://github.com/prestosql/presto/pulls?q=is%3Apr+author%3... Practically speaking, it is difficult to maintain a development branch of any software project with sufficient change velocity if you have a goal of continuing to integrate improvements from the upstream version.
  - tormeh 6y ago
    Redis changed from AGPL to Apache 2 with something they called a Commons Clause, then finally to Redis Source Available License because of cloud providers. Don't really know exactly which event triggered the change, though. I suppose it could have been GCP or Azure instead of AWS. Regardless, AGPL is far less restrictive than people claim it is. It is a particularly strict version of the GPL, but given proper legal review it is unproblematic to use commercially, which cuts both ways as Redis found out. I think there's a serious amount of FUD around it. I suppose it's because of how rare it is. With more usage, it would probably bee seen as less dangerous.
    - boogies 6y ago
      I agree that there’s a serious amount of FUD around it. I think it’s at least in part because it proliferating could seriously harm Alphabet’s ability to freely grab people’s code to incorporate in their consumer products (YouTube, G Suite, etc.) without reciprocating, and they’ve been careful to semi-subtly spread the FUD (ie. publish https://opensource.google/docs/using/agpl-policy/ https://opensource.google/docs/using/agpl-policy/). https://drewdevault.com/2020/07/27/Anti-AGPL-propaganda.html https://drewdevault.com/2020/07/27/Anti-AGPL-propaganda.html
      - _msw_ 6y ago
        See also https://sfconservancy.org/blog/2020/jan/06/copyleft-equality/ https://sfconservancy.org/blog/2020/jan/06/copyleft-equality...
    - _msw_ 6y ago
      The core Redis code (originally announced on this site in 2009 [1], before Garantia Data started in 2011, or became Redis Labs in 2014) has always been BSD licensed. Only extensions from Redis Labs (e.g., Redis look) were licensed under AGPL, and changed to Commons Clause / Redis Source Available License. Those extensions were never part of an AWS cloud service. See also [2] [1] https://news.ycombinator.com/item?id=494649 https://news.ycombinator.com/item?id=494649 [2] https://redislabs.com/blog/redis-core-team-update/ https://redislabs.com/blog/redis-core-team-update/
carlhjerpe 6y ago
The problem is that Amazon could still do it, they're just on that scale, while most common companies would shy away as they don't have the Amazon budget for abusing AGPL right. I hope in the future the Elastic, TimeScale, Confluent and any other "fuck Amazon" license could be merged into one and kind of standardized on as many freedoms as possible, while keeping AWS out of it.