4 ms·

How refreshing, an open-source company choosing the AGPL instead of some contrived homebrew license! I welcome this change - as I've stated multiple times here

How refreshing, an open-source company choosing the AGPL instead of some contrived homebrew license! I welcome this change - as I've stated multiple times here, we need more AGPL-licensed software!

Macha 3y ago
AGPL+CLA that assigns copyright to them. So element can do anything but others are held to the AGPL. I mean, it's better than SSPL, but considering how heavily they've marketed in the past on matrix being truly open, it's a little disappointing that they've chosen to go to asymmetric openness.
- hedora 3y ago
  The asymmetry only lasts as long as their branch is better than some community fork. That’s approximately as long as we have between now and when they stop investing in improving the end user experience. This is pretty close to ideal IMO.
  - trickstra 3y ago
    The CLA ennsures their monopoly, it increases the asymmetry over time. Forks will have to share all improvements with Element, but Element will be able to provide proprietary improvements, which means more people will chose it. Then they can at any moment relicense and take the whole app proprietary.
    - bb010g 3y ago
      `Apache-2.0` allows Element the same power right now. No organization is maintaining meaningful community forks of Synapse and/or Dendrite with their own proprietary modifications on top. Element hasn't used their power to take the vast majority of their modifications private so far. If Element decides to go proprietary, which they could already decide to do, then the community is now left to fork an `AGPL-3.0` project instead of an `Apache-2.0` project. Oh no, we'll be protected from this happening again in the future, wailing and gnashing of teeth.
      - trickstra 3y ago
        Apache-2.0 gives everyone those rights. The CLA makes Element the only one who can build proprietary modifications on top. Monopolization of the position they gained by advertising as open-source.
- Pannoniae 3y ago
  I don't think SSPL is worse than AGPL in practice, in fact it is better. The SSPL is effectively a stronger AGPL. This makes it non-OSI-approved, but the licence itself is completely fine. The major difference is that the SSPL also mandates that you release everything needed to run the software, not just the software itself. For reference, it's worth to read the OSI's blogpost about this, it's quite illuminating: https://blog.opensource.org/the-sspl-is-not-an-open-source-license/ https://blog.opensource.org/the-sspl-is-not-an-open-source-l... It's also worth mentioning that most of the attacks against the GPL, AGPL and SSPL are done by corporate shills, and OSI is also full of them. They pretend to support "non-discrimination of fields of endeavour" but they are undermining free software to SaaS-ify it. Don't fall for the "SSPL is not open source" propaganda.
  - RobotToaster 3y ago
    >The major difference is that the SSPL also mandates that you release everything needed to run the software Which makes it incompatible with little things like the linux kernel, since you don't have the licence to release it as SSPL
  - fweimer 3y ago
    The additional restrictions in the SSPL apply also to unmodified versions. This is very different from the AGPL, which does not impose any additional over the burdens over the GPL if you use an unmodified version of the software, even if you use that to offer network services. This provides a very clear path to AGPL compliance for most users, certainly those who get their software from a GNU/Linux distribution. (I missed that aspect of the AGPL for quite some time, admittedly.) The SSPL, in contrast, applies to unmodified versions of the software. This means that even if you get SSPL software from someone who publishes the sources, you have to take additional steps for license compliance if you want to use the software. Given that the SSPL requires publishing things like the source code for NIC and network switch firmware (both are obviously required for offering your network service …), I just don't see how this license is useful besides being deceptive. The BSL with its typical field-of-use restrictions achieve the same thing in a much more direct manner.
  - cxr 3y ago
- csdreamer7 3y ago
  And? If they are doing most of the development they need a way to finance that. Selling GPL exceptions is a Stallman approved tactic.
  - cxr 3y ago
    He approves of developers selling GPL exceptions. He doesn't approve of buying GPL exceptions*. It's a subtle point. (The natural corollary to this is that if the Element/Matrix folks—or anyone—were to ask you for a CLA excepting them from the project's own open source license, then you could/should feel comfortable kindly requiring them to pay you for it—a response which should be the default in the open source world, although it unfortunately is not.) * i.e. so you can make proprietary software
    - cvwright 3y ago
      Personally I’m happy to ask them to kindly maintain my new feature along with all of their other code, so I can continue to use an up-to-date version with very little effort.
      - trickstra 3y ago
        How happy would you be when they later move your contribution to a paid tier only?
        cvwright 3y ago
        Almost as unhappy as if the upstream project failed and went away completely. And in reality it depends a lot on my level of contribution. If I have dozens of lines of code in a big project, then who cares, all I really wanted was for my pet bugs to get fixed. If I contributed major features or thousands of lines of code there, then I would be very mad. But I would also be very capable of maintaining an open source fork of the project.
- ladyanita22 3y ago
  Agreed, I am not a fan of AGPL, but I could understand and accept it. Not with the CLA. The CLA means you'll have to pay for whatever you want privately developed.
  - auggierose 3y ago
    No, the CLA means that if you want something privately developed, you have the option to do so by buying a license that allows that. Without the CLA, nobody would be able to do that, at least if there are any community contributions.
- deleted 3y ago
  [deleted]
- Gigachad 3y ago
  Realistically they probably do like 95% of the real work themselves so it makes sense.
  - trickstra 3y ago
    Realistically, if they started as proprietary in the first place, they wouldn't ever grow to this size (just another closed chat app competing with Discord and Messenger), so they still benefited from being open-source. Now they are reaping the benefit and monopolizing it.
    - Gigachad 3y ago
      It’s still open source now. You can pull the repo and do whatever with it. They just won’t merge your changes without a CLA. You are free to fork and contribute there if you want.
    - nani8ot 3y ago
      I understand your point, but there're the independent home server implementations Conduit (Rust) and Construct (C++) so it's not exactly monopolizing. The Matrix spec will continue to be Apache 2.0 licensed.
alwayslikethis 3y ago
As an additional plus, I think many SaaS companies (e.g. Google) ban the use of AGPL software on their company computers. The more advantages we can give to non-big tech developers, the better.

How refreshing, an open-source company choosing the AGPL instead of some contrived homebrew license! I welcome this change - as I've stated multiple times here, we need more AGPL-licensed software!

Macha 3y ago

AGPL+CLA that assigns copyright to them. So element can do anything but others are held to the AGPL. I mean, it's better than SSPL, but considering how heavily they've marketed in the past on matrix being truly open, it's a little disappointing that they've chosen to go to asymmetric openness.

hedora 3y ago
The asymmetry only lasts as long as their branch is better than some community fork. That’s approximately as long as we have between now and when they stop investing in improving the end user experience. This is pretty close to ideal IMO.
- trickstra 3y ago
  The CLA ennsures their monopoly, it increases the asymmetry over time. Forks will have to share all improvements with Element, but Element will be able to provide proprietary improvements, which means more people will chose it. Then they can at any moment relicense and take the whole app proprietary.
  - bb010g 3y ago
    `Apache-2.0` allows Element the same power right now. No organization is maintaining meaningful community forks of Synapse and/or Dendrite with their own proprietary modifications on top. Element hasn't used their power to take the vast majority of their modifications private so far. If Element decides to go proprietary, which they could already decide to do, then the community is now left to fork an `AGPL-3.0` project instead of an `Apache-2.0` project. Oh no, we'll be protected from this happening again in the future, wailing and gnashing of teeth.
    - trickstra 3y ago
      Apache-2.0 gives everyone those rights. The CLA makes Element the only one who can build proprietary modifications on top. Monopolization of the position they gained by advertising as open-source.
Pannoniae 3y ago
I don't think SSPL is worse than AGPL in practice, in fact it is better. The SSPL is effectively a stronger AGPL. This makes it non-OSI-approved, but the licence itself is completely fine. The major difference is that the SSPL also mandates that you release everything needed to run the software, not just the software itself. For reference, it's worth to read the OSI's blogpost about this, it's quite illuminating: https://blog.opensource.org/the-sspl-is-not-an-open-source-license/ https://blog.opensource.org/the-sspl-is-not-an-open-source-l... It's also worth mentioning that most of the attacks against the GPL, AGPL and SSPL are done by corporate shills, and OSI is also full of them. They pretend to support "non-discrimination of fields of endeavour" but they are undermining free software to SaaS-ify it. Don't fall for the "SSPL is not open source" propaganda.
- RobotToaster 3y ago
  >The major difference is that the SSPL also mandates that you release everything needed to run the software Which makes it incompatible with little things like the linux kernel, since you don't have the licence to release it as SSPL
- fweimer 3y ago
  The additional restrictions in the SSPL apply also to unmodified versions. This is very different from the AGPL, which does not impose any additional over the burdens over the GPL if you use an unmodified version of the software, even if you use that to offer network services. This provides a very clear path to AGPL compliance for most users, certainly those who get their software from a GNU/Linux distribution. (I missed that aspect of the AGPL for quite some time, admittedly.) The SSPL, in contrast, applies to unmodified versions of the software. This means that even if you get SSPL software from someone who publishes the sources, you have to take additional steps for license compliance if you want to use the software. Given that the SSPL requires publishing things like the source code for NIC and network switch firmware (both are obviously required for offering your network service …), I just don't see how this license is useful besides being deceptive. The BSL with its typical field-of-use restrictions achieve the same thing in a much more direct manner.
- cxr 3y ago
csdreamer7 3y ago
And? If they are doing most of the development they need a way to finance that. Selling GPL exceptions is a Stallman approved tactic.
- cxr 3y ago
  He approves of developers selling GPL exceptions. He doesn't approve of buying GPL exceptions*. It's a subtle point. (The natural corollary to this is that if the Element/Matrix folks—or anyone—were to ask you for a CLA excepting them from the project's own open source license, then you could/should feel comfortable kindly requiring them to pay you for it—a response which should be the default in the open source world, although it unfortunately is not.) * i.e. so you can make proprietary software
  - cvwright 3y ago
    Personally I’m happy to ask them to kindly maintain my new feature along with all of their other code, so I can continue to use an up-to-date version with very little effort.
    - trickstra 3y ago
      How happy would you be when they later move your contribution to a paid tier only?
      - cvwright 3y ago
        Almost as unhappy as if the upstream project failed and went away completely. And in reality it depends a lot on my level of contribution. If I have dozens of lines of code in a big project, then who cares, all I really wanted was for my pet bugs to get fixed. If I contributed major features or thousands of lines of code there, then I would be very mad. But I would also be very capable of maintaining an open source fork of the project.
ladyanita22 3y ago
Agreed, I am not a fan of AGPL, but I could understand and accept it. Not with the CLA. The CLA means you'll have to pay for whatever you want privately developed.
- auggierose 3y ago
  No, the CLA means that if you want something privately developed, you have the option to do so by buying a license that allows that. Without the CLA, nobody would be able to do that, at least if there are any community contributions.
deleted 3y ago
[deleted]
Gigachad 3y ago
Realistically they probably do like 95% of the real work themselves so it makes sense.
- trickstra 3y ago
  Realistically, if they started as proprietary in the first place, they wouldn't ever grow to this size (just another closed chat app competing with Discord and Messenger), so they still benefited from being open-source. Now they are reaping the benefit and monopolizing it.
  - Gigachad 3y ago
    It’s still open source now. You can pull the repo and do whatever with it. They just won’t merge your changes without a CLA. You are free to fork and contribute there if you want.
  - nani8ot 3y ago
    I understand your point, but there're the independent home server implementations Conduit (Rust) and Construct (C++) so it's not exactly monopolizing. The Matrix spec will continue to be Apache 2.0 licensed.

alwayslikethis 3y ago

As an additional plus, I think many SaaS companies (e.g. Google) ban the use of AGPL software on their company computers. The more advantages we can give to non-big tech developers, the better.