8 ms·

This is why I don't want to put any free testing into a copylefted copyright like Element, let alone code or docs contributions. I realize I'm testing Discord f

This is why I don't want to put any free testing into a copylefted copyright like Element, let alone code or docs contributions. I realize I'm testing Discord for free, but it's different with Element, because for years I perceived it as being a vendor-neutral open source project. The copyleft is so it isn't vendor neutral. OTOH there are projects like Forgejo which are copyleft but are still vendor neutral. Even though it's vendor neutral, I wouldn't be too thrilled if it were AGPL, but it's just GPL. So I am still a happy Codeberg user. (Element is AGPL) Zulip is my favorite open source chat now. It's used by some stuff that's relevant to me right now including Bytecode Alliance and Julia.

palata 2y ago
What's the deal with Element? Is it AGPL, but exclusively developed by one company? Or does it take contributions but with a CLA giving the copyright to the company? I'm not aware of the situation there. Not sure I follow why AGPL is a problem, though.
- benatkin 2y ago
  It's bait and switch, they built the community of Matrix and Element around a promise of openness but specifically chose a license to make it another Discord or Slack. You can read between the lines here: https://element.io/blog/element-to-adopt-agplv3/ https://element.io/blog/element-to-adopt-agplv3/ HN thread to help with the context: https://news.ycombinator.com/item?id=38162275 https://news.ycombinator.com/item?id=38162275
  - ValentineC 2y ago
    To be precise, I'm guessing the problem is more of the CLA, and not AGPL itself.
    - palata 2y ago
      Yes, CLAs are abusive, IMO. If I do work for free, I own the copyright (unless my company does, but that's another story). There is no way I give it for free to the organisation that manages the upstream project. Developers should not sign CLAs. But that has nothing to do with the licence itself (be it AGPL or something else).
    - benatkin 2y ago
      It's more that vendor neutral is a sweet spot for me. AGPL, as well as GPL for a library rather than something that works well as a standalone application, brings it closer into what feels to me like no software vendor territory - one where you find something else to sell (vend) other than software, like Stallman musing about choosing to be a waiter rather than have any non-free software: > Well, the most simple alternative was to leave the software field, do something else. Now a lot of programmers say to me, 'the employers hiring programmers demand that I do this -- if I don't do this I will starve.' Now, that's silly. Anybody can leave the field of programming. Even in the US, there are millions of people who make a living not by writing software. I have no other special skills, nothing else that I'm particularly good at. But I'm sure I could have become a waiter. (Now, maybe I couldn't be a waiter at one of the fanciest restaurants.) There is nothing unethical about being a waiter. And there is one thing -- you are not going to starve. http://mikro-berlin.org/Events/OS/ref-texte/stallman.html http://mikro-berlin.org/Events/OS/ref-texte/stallman.html
      - palata 2y ago
        I am still not sure what you are saying. Are you saying that Forgejo being GPL allows e.g. Codeberg to modify it without releasing their changes, and with AGPL they couldn't build a valid business model?
        benatkin 2y ago
        > with AGPL they couldn't build a valid business model It's not so clear cut. There are differences between the GPL and AGPL, and they can have an effect on how well a business or non-profit (which Codeberg is) that uses it or is based on it (which Codeberg is) functions. Forgejo uses the GPL, which is meant for a balance between having it remain open source (a reason for Copyleft) and it being convenient (compared to the AGPL). When a code change is pushed to the servers of someone using Forgejo, they don't need to worry about releasing the changes - only when distributing it. It may take time to prepare the changes to be released publicly, or it may reveal details about a client who is using it. Forgejo is vendor-neutral because Forgejo itself and their flagship user, Forgejo, use it under the same license as everyone else, and is pretty vendor-friendly because it's under the GPL rather than the AGPL. Element isn't vendor-neutral because they don't use it under the same license as everyone else. They have the copyright and they don't have to abide by the AGPL. It isn't so vendor-friendly as an open source product to other vendors besides them because people outside have to use it under the AGPL, and might have a situation where a client needs something and the release is held up because the customizations are going to have to be made public as source code as soon as they're accessible over the network. Both of these are products that are integration-heavy. The AGPL can be a lot more vendor-friendly for products that aren't so integration-heavy.
  - Arathorn 2y ago
    > they built the community of Matrix and Element around a promise of openness but specifically chose a license to make it another Discord or Slack This is really unhelpfully inaccurate. Matrix is as open as ever - and run by the vendor-neutral non-profit Matrix.org Foundation these days. Code published by matrix.org is all Apache licensed. Element shifted the development of most of the stuff it implements as a Matrix vendor to AGPL+CLA in order to fund FOSS Matrix dev by selling AGPL exceptions to organisations which are allergic to AGPL. We also explicitly put a clause on the CLA spelling out that any contributions under CLA will remain OSI-licensed FOSS for as long as Element is around to release them. Speaking as Element's CEO, if we hadn't switched to AGPL+CLA, we would not have been able to make Element a sustainable organisation (i.e. able to pay the salaries of its developers) - and even then Element isn't quite at break-even yet. If you can't tell the difference between a proprietary, non-standard-based stack like Discord or Slack and a FOSS, open-standard-based system like Element+Matrix, then I'm not sure you are arguing in good faith here (and it's incredibly depressing to see disinformation spread against Element, given the 10 years we've spent trying to build a good open-standard FOSS solution).
    - benatkin 2y ago
      There was clear deprioritization of the community, which to me doesn’t sound like good faith, by Matrix Foundation in closing the ecosystem. Element, which has the stuff that matters, is technically FOSS. And the 10 years just shows how long the rugpull scheme went on, whether the misappropriation of Synapse was planned far in advance I don’t know. > Matrix is as open as ever - and run by the vendor-neutral non-profit Matrix.org Foundation these days. Code published by matrix.org is all Apache licensed. Matrix.org was gutted through the transfer of Synapse. With the same leadership as before it’s ready to relicense anything else at anytime.
      - Arathorn 2y ago
        > There was clear deprioritization of the community, which to me doesn’t sound like good faith, by Matrix Foundation in closing the ecosystem. The Matrix Foundation has not “closed the ecosystem”! The ecosystem is healthier than ever - just look at all the independent folks building away at https://2024.matrix.org/watch https://2024.matrix.org/watch etc. You seem to be conflating Element switching its development to AGPL+CLA with Matrix itself, which is categorically not the case. > Element, which has the stuff that matters, is technically FOSS No, Element is not “the stuff that matters”. The Matrix protocol and foundation is. There are loads of Matrix stacks independent of Element now - whether that’s clients for KMP, RN, Flutter, Qt, GTK etc which don’t use a line of code written by Element employees, or alternative servers like Conduit/Conduwuit/Grapevine. > And the 10 years just shows how long the rugpull scheme went on, whether the misappropriation of Synapse was planned far in advance I don’t know. Wow. Just Wow. So you’re saying that the 8.5 years spent frantically trying to keep Element sustainable as completely permissive FOSS was actually a long con rugpull - and the longer we managed to extend that to everyone’s benefit, the more malicious we were being? And you would rather Element had gone bust than switched its Synapse dev to AGPL+CLA? > Matrix.org was gutted through the transfer of Synapse. Nobody “transferred Synapse”. Element effectively forked it in order to continue working on it as AGPL+CLA, purely so it could sell AGPL exceptions to fund the dev. > With the same leadership as before it’s ready to relicense anything else at anytime. Nobody relicensed anything. It is not in the hands of the leadership of the Matrix.org Foundation to somehow force a contributor (Element) to keep contributing as Apache if that contributor can’t financially afford to do so, and choses to release as a new repo instead. The Foundation doesn’t remotely have the $ to maintain its own Apache fork of Synapse. It has however spelt out which projects it will continue to release as Apache ($ allowing): https://matrix.org/blog/2024/08/heart-of-matrix/ https://matrix.org/blog/2024/08/heart-of-matrix/ To be clear: the only reason I’m responding here is to try to give a view based on reality to anyone unfortunate enough to read this thread. It’s incredibly depressing to see how you have misrepresented the situation. Fwiw, if there had been any way to keep Synapse Apache and keep the team alive to develop it, I would have taken it.

palata 2y ago

What's the deal with Element? Is it AGPL, but exclusively developed by one company? Or does it take contributions but with a CLA giving the copyright to the company? I'm not aware of the situation there. Not sure I follow why AGPL is a problem, though.

benatkin 2y ago
It's bait and switch, they built the community of Matrix and Element around a promise of openness but specifically chose a license to make it another Discord or Slack. You can read between the lines here: https://element.io/blog/element-to-adopt-agplv3/ https://element.io/blog/element-to-adopt-agplv3/ HN thread to help with the context: https://news.ycombinator.com/item?id=38162275 https://news.ycombinator.com/item?id=38162275
- ValentineC 2y ago
  To be precise, I'm guessing the problem is more of the CLA, and not AGPL itself.
  - palata 2y ago
    Yes, CLAs are abusive, IMO. If I do work for free, I own the copyright (unless my company does, but that's another story). There is no way I give it for free to the organisation that manages the upstream project. Developers should not sign CLAs. But that has nothing to do with the licence itself (be it AGPL or something else).
  - benatkin 2y ago
    It's more that vendor neutral is a sweet spot for me. AGPL, as well as GPL for a library rather than something that works well as a standalone application, brings it closer into what feels to me like no software vendor territory - one where you find something else to sell (vend) other than software, like Stallman musing about choosing to be a waiter rather than have any non-free software: > Well, the most simple alternative was to leave the software field, do something else. Now a lot of programmers say to me, 'the employers hiring programmers demand that I do this -- if I don't do this I will starve.' Now, that's silly. Anybody can leave the field of programming. Even in the US, there are millions of people who make a living not by writing software. I have no other special skills, nothing else that I'm particularly good at. But I'm sure I could have become a waiter. (Now, maybe I couldn't be a waiter at one of the fanciest restaurants.) There is nothing unethical about being a waiter. And there is one thing -- you are not going to starve. http://mikro-berlin.org/Events/OS/ref-texte/stallman.html http://mikro-berlin.org/Events/OS/ref-texte/stallman.html
    - palata 2y ago
      I am still not sure what you are saying. Are you saying that Forgejo being GPL allows e.g. Codeberg to modify it without releasing their changes, and with AGPL they couldn't build a valid business model?
      - benatkin 2y ago
        > with AGPL they couldn't build a valid business model It's not so clear cut. There are differences between the GPL and AGPL, and they can have an effect on how well a business or non-profit (which Codeberg is) that uses it or is based on it (which Codeberg is) functions. Forgejo uses the GPL, which is meant for a balance between having it remain open source (a reason for Copyleft) and it being convenient (compared to the AGPL). When a code change is pushed to the servers of someone using Forgejo, they don't need to worry about releasing the changes - only when distributing it. It may take time to prepare the changes to be released publicly, or it may reveal details about a client who is using it. Forgejo is vendor-neutral because Forgejo itself and their flagship user, Forgejo, use it under the same license as everyone else, and is pretty vendor-friendly because it's under the GPL rather than the AGPL. Element isn't vendor-neutral because they don't use it under the same license as everyone else. They have the copyright and they don't have to abide by the AGPL. It isn't so vendor-friendly as an open source product to other vendors besides them because people outside have to use it under the AGPL, and might have a situation where a client needs something and the release is held up because the customizations are going to have to be made public as source code as soon as they're accessible over the network. Both of these are products that are integration-heavy. The AGPL can be a lot more vendor-friendly for products that aren't so integration-heavy.
- Arathorn 2y ago
  > they built the community of Matrix and Element around a promise of openness but specifically chose a license to make it another Discord or Slack This is really unhelpfully inaccurate. Matrix is as open as ever - and run by the vendor-neutral non-profit Matrix.org Foundation these days. Code published by matrix.org is all Apache licensed. Element shifted the development of most of the stuff it implements as a Matrix vendor to AGPL+CLA in order to fund FOSS Matrix dev by selling AGPL exceptions to organisations which are allergic to AGPL. We also explicitly put a clause on the CLA spelling out that any contributions under CLA will remain OSI-licensed FOSS for as long as Element is around to release them. Speaking as Element's CEO, if we hadn't switched to AGPL+CLA, we would not have been able to make Element a sustainable organisation (i.e. able to pay the salaries of its developers) - and even then Element isn't quite at break-even yet. If you can't tell the difference between a proprietary, non-standard-based stack like Discord or Slack and a FOSS, open-standard-based system like Element+Matrix, then I'm not sure you are arguing in good faith here (and it's incredibly depressing to see disinformation spread against Element, given the 10 years we've spent trying to build a good open-standard FOSS solution).
  - benatkin 2y ago
    There was clear deprioritization of the community, which to me doesn’t sound like good faith, by Matrix Foundation in closing the ecosystem. Element, which has the stuff that matters, is technically FOSS. And the 10 years just shows how long the rugpull scheme went on, whether the misappropriation of Synapse was planned far in advance I don’t know. > Matrix is as open as ever - and run by the vendor-neutral non-profit Matrix.org Foundation these days. Code published by matrix.org is all Apache licensed. Matrix.org was gutted through the transfer of Synapse. With the same leadership as before it’s ready to relicense anything else at anytime.
    - Arathorn 2y ago
      > There was clear deprioritization of the community, which to me doesn’t sound like good faith, by Matrix Foundation in closing the ecosystem. The Matrix Foundation has not “closed the ecosystem”! The ecosystem is healthier than ever - just look at all the independent folks building away at https://2024.matrix.org/watch https://2024.matrix.org/watch etc. You seem to be conflating Element switching its development to AGPL+CLA with Matrix itself, which is categorically not the case. > Element, which has the stuff that matters, is technically FOSS No, Element is not “the stuff that matters”. The Matrix protocol and foundation is. There are loads of Matrix stacks independent of Element now - whether that’s clients for KMP, RN, Flutter, Qt, GTK etc which don’t use a line of code written by Element employees, or alternative servers like Conduit/Conduwuit/Grapevine. > And the 10 years just shows how long the rugpull scheme went on, whether the misappropriation of Synapse was planned far in advance I don’t know. Wow. Just Wow. So you’re saying that the 8.5 years spent frantically trying to keep Element sustainable as completely permissive FOSS was actually a long con rugpull - and the longer we managed to extend that to everyone’s benefit, the more malicious we were being? And you would rather Element had gone bust than switched its Synapse dev to AGPL+CLA? > Matrix.org was gutted through the transfer of Synapse. Nobody “transferred Synapse”. Element effectively forked it in order to continue working on it as AGPL+CLA, purely so it could sell AGPL exceptions to fund the dev. > With the same leadership as before it’s ready to relicense anything else at anytime. Nobody relicensed anything. It is not in the hands of the leadership of the Matrix.org Foundation to somehow force a contributor (Element) to keep contributing as Apache if that contributor can’t financially afford to do so, and choses to release as a new repo instead. The Foundation doesn’t remotely have the $ to maintain its own Apache fork of Synapse. It has however spelt out which projects it will continue to release as Apache ($ allowing): https://matrix.org/blog/2024/08/heart-of-matrix/ https://matrix.org/blog/2024/08/heart-of-matrix/ To be clear: the only reason I’m responding here is to try to give a view based on reality to anyone unfortunate enough to read this thread. It’s incredibly depressing to see how you have misrepresented the situation. Fwiw, if there had been any way to keep Synapse Apache and keep the team alive to develop it, I would have taken it.