21 ms·

A new home and license (AGPL) for Synapse and friends

178 points by regularjack 3y ago

MR4D 3y ago
I’m confused. Synapse and Dendrite projects are forked. Ok. But then they say they won’t be continuing to fund development and “They’ll need to get their upstream releases from Element’s repositories going forward.” that seems to mean that future downloads should come from Element? That sounds more like a handoff than a fork. Can someone clarify this a bit?
- cobertos 3y ago
  They say the original repositories predate Element. But no idea on who owns them or who's being forked _from_?
  - dbrgn 3y ago
    If I'm not mistaken: The two projects were started by the people that founded Element. When they founded Element, they transferred the projects to the Foundation, to make them more independent. Now, they're taking them back and relicensing them with a reciprocal license (AGPLv3 + CLA) instead of a permissive one (ALv2). I assume this is about other companies using Synapse and Dendrite without contributing back, so now Element wants to be able to sell licenses for the projects, or get contributions. See https://element.io/blog/element-to-adopt-agplv3/ https://element.io/blog/element-to-adopt-agplv3/ for more details.
    - ensignavenger 3y ago
      The CLA isn't reciprocal. Reciprocicity is only one way when you require a CLA.
      - freedomben 3y ago
        I don't think they're saying the CLA is reciprocal, that's a reference to the AGPL which requires you to share any changes you make.
- dbrgn 3y ago
  From how I understand this: Synapse and Dendrite were Foundation projects, but the contributions came almost exclusively from Element. Element is forking the two projects, and is redirecting their maintenance efforts towards their own forks. This means that the Foundation versions of the projects will not receive active maintenance anymore, and the Foundation does not have the funding to invest in the development themselves. It's a de-facto handoff, unless someone wants to invest significant resources in development of the pre-fork versions of the projects.
- themoonisachees 3y ago
  The old repos "belong" to the matrix foundation, but the work on them was mostly done by the element team. This is them officializing that synapse and dendrite are element branded projects, not matrix (so yes, it is indeed a handoff), except they are branding this as a fork because the license is changing. They also are changing licences to require downstream forkers to also open-source their changes, ensuring corporate users of matrix contribute back upstream if they modify their implementation (beeper might be in some hot water, though they can very well continue using and maintaining their own fork from the matrix foundation repos with the old licence).
  - ensignavenger 3y ago
    It requires all users, whether corporate or not, to release all changes under AGPLv3... the whole point of the Matrix protocol is to talk to other users... so basically everyone triggers the AGPLv3s "network" clause. However, releaseing your code under the AGPLv3 is not the same as upstreaming it. In order to do that, you additionaly have to sign a CLA granting the Element corporation broad and expansive rights to do whatever they please with your code... but you don't get the same rights to their code.
    - goku12 3y ago
      I agree with your assessment of the AGPL-CLA combination. But the initial part seems to be about the Matrix protocol. The projects that were forked and re-licensed are the servers - Synapse, Dendrite, Sygnal, Sydent and MAS. The protocol itself is still under Apache 2.0 (https://spec.matrix.org/latest/ https://spec.matrix.org/latest/), though they seem to have added CLA to it. If so, the protocol doesn't have the problem you pointed out. You could use another server - like Conduit.
      - progval 3y ago
        Where do you see they added a CLA to the protocol? If you are referring to the sign-off, it has always been there and isn't a CLA.
      - 3y ago
huggingmouth 3y ago
Well, the best of luck to them. All I'm really interested in is whether the new (read, old) overloards at Element have serious plans to revive p2p efforts or not. Going off their behavior on certain github issues, I won't hold my breath and will continue to use briar instead.
- Spunkie 3y ago
  I contacted the foundation funding channel, multiple times,specifically about becoming a member to support p2p development and they don't even have the decency to respond. Honestly this whole thing feels like a bait n switch. Get the community based matrix popular and cozied up with the public sector and then lock that shit down under the element Corp. The foundation, who's job it is apparently to protect/guide matrix outlook and development, now has no ability to actually govern said project.
- COGlory 3y ago
  >Going off their behavior on certain github issues, I won't hold my breath and will continue to use briar instead. link?
  - ycnews 3y ago
    https://code.briarproject.org/briar https://code.briarproject.org/briar
UltimateEdge 3y ago
So does this pretty much boil down to "we are re-licensing Synapse and Dendrite from Apache to AGPL"? In what way is the "owner" of the code significant, in this case, other than being a proxy for the maintainer of the most popular fork? These projects are open source, so the only thing this code is really attached to is the license. Whatever entity controls the majority of developer effort effectively controls the future of the project. So far, that entity has been Element, and the features being worked on in the client and server applications have been and will be influenced by the customers of Element and the sponsors of the Foundation (for an example of this influence, see the biometric/PIN lock introduced in the Element X mobile applications).
- freedomben 3y ago
  > Whatever entity controls the majority of developer effort effectively controls the future of the project. Yes, but that doesn't preclude others from stepping up with developer effort on the originals, should they want to. Given the widespread use of matrix, this does seem like a possibility.
- runiq 3y ago
  The point of contention here is not really the license change, but the CLA attached to it. Basically, if you write code for Synapse/Dendrite, submit it to the project, and sign the CLA, the (for-profit) Element Foundation may relicense your code under a proprietary license. It's intended to keep contributions from proprietary clients coming without them fleeing the ship because they see the four letter word AGPL.
Spunkie 3y ago
Such a casual blog post for what is essentially the announcement of the death of the matrix project.
- nerdponx 3y ago
  Is it the death? I definitely felt like something was wrong, given that the protocol seems to have lots of problems and Dendrite has been in 0.x beta since basically forever. But I don't know what this means practically for Matrix.
  - bzmrgonz 3y ago
    Too many people riding their coat-tails and not paying royalties for the hard-work they did and continue to do. I think they should go the CE & paid versioning that other projects have chosen. Let people continue to experiment with CE and once they are in a corporation, "we" can steer our bosses to the paid version. Alternatively, they should move up the stack and offer a clean deployment/hosting option (remove the container ops with a ci/cd direct to their hosting company). The argument is, we have to host this somewhere, why should we give peter that which rightfully belongs to John? So if John Matrix get into the hosting business, problem solved.
    - lannisterstark 3y ago
      >not paying royalties It's an open source project. What royalties? >continue to do and are 100% allowed to. > I think they should go the CE & paid versioning that other projects have chosen. I don't think that'd be the best idea, it works for other projects because they're not essentially acting as defacto communication protocols.
- freedomben 3y ago
  This seems a little premature. It reminds me of Monty Python and the Holy Grail where the "bring out your dead" cart[1] is coming and a guy tries to dump a body, and the body says "I'm not dead." It's definitely not a good look, but when taken in context this ironically might be the thing that saves the project from death.[2] [1]: https://youtu.be/Jdf5EXo6I68?si=CGv7j8J5H1XnW3i1&t=55 https://youtu.be/Jdf5EXo6I68?si=CGv7j8J5H1XnW3i1&t=55 [2]: https://news.ycombinator.com/item?id=38162275 https://news.ycombinator.com/item?id=38162275
candiddevmike 3y ago
So, what's the next best alternative to Matrix?
- ensignavenger 3y ago
  Depends on what you want.. XMPP as a protocol is somewhat comparable, but I like the Matrix model better. You can still use the Matrix protocol without adopting this new corporate fork, though.
- KirillPanov 3y ago
  tox
ensignavenger 3y ago
This really sucks. I have always had great hope for the Matrix protocol. The AGPL isn't my favorite open source license, but it has its place... but a CLA? That is a complete nonstarter. No one should ever sign a CLA that gives a company more rights to your contributions than you get from theirs.
- appplication 3y ago
  What’s the deal with CLAs? I’m not familiar with them.
  - jraph 3y ago
    they allow the company making you sign the CLA change the license the entire project with your contribution in it to what they like, including making it proprietary.
  - ensignavenger 3y ago
    When you try to contribute code back upstream, the company will require you to grant them broad rights to do whatever they want with it, including to relicense the code you are contributing under a proprietary license. You do not get the same rights in return to the upstream code. So the company can yake your contributions and go proprietary and you have no recourse.
    - gary_0 3y ago
      I'm surprised it's not more of a thing to have a CLA that allows relicensing only to another OSI-approved license. I don't see many examples along those lines[0]. And the "OSI-approved" wording would allow a project to freely switch between MIT/BSD/GPL/etc or even create their own license (as long as they get it OSI-approved) without having to hunt down past contributors for permission. I would never sign an open-ended CLA, though. For all I know, the project (with my code in it) could end up being bought by Oracle, proprietized, and used by Larry Ellison to construct the Torment Nexus. [0] https://en.wikipedia.org/wiki/Contributor_License_Agreement#CLAs_which_restrict_relicensing https://en.wikipedia.org/wiki/Contributor_License_Agreement#...
Andrew018 3y ago
[dead]
vbezhenar 3y ago
They keep open source license, so why not. If money's involved, it's gotta be messy either way and matrix is too convoluted and complex to be developed without money envolved.
- ensignavenger 3y ago
  The biggest problem isn't the new license... not a fan of it at all... but the biggest problem is the CLA.
  - vbezhenar 3y ago
    They want to sell sources with alternative license, it's part of their business plan, so CLA is unavoidable.
    - jraph 3y ago
      If I understand correctly: Synapse and Dendrite have been under Apache 2.0 so far, which would allow anyone to turn them into proprietary products. Including Element. With this change, the situation is: Element can make them proprietary but no one else.
      - runiq 3y ago
        Not exactly, but close. The CLA gives them the ability to relicense, which affects proprietary products built on top of Synapse/Dendrite. Without the CLA, all code written against the AGPL-licensed Synapse/Dendrite would have to be licensed AGPL as well, even if it interacts with Synapse/Dendrite over network boundaries as part of a SAAS offering or somesuch. I believe that's why 'AGPL' is a four letter word in certain circles. Disclaimer: I am not a lawyer.
        ryukafalz 3y ago
        No, that's a common misconception. The relevant section of the license is: > Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This does not state that you must license any of your software that interacts with the AGPL code over the network as AGPL, merely that you make modified versions of the AGPL code available to users who interact with it over the network licensed as AGPL. The rest of the license generally behaves as the GPL would.
WhatIsDukkha 3y ago
Reminder - https://conduit.rs/ https://conduit.rs/ Rust implementation of the matrix server stack
- COGlory 3y ago
  If I were starting today, I'd be using conduit, but as it stands, I'm on Synapse and have no migration path for my server.
- koito17 3y ago
  I've been using Conduit as my matrix server with the help of a few programs I wrote myself to ensure admin user exists etc. I am really impressed with how little resources Conduit uses. A fresh install with a few rooms was only consuming about 32 MiB of RAM. Compared to both Synapse and Dendrite, this is nothing! I haven't stress tested the server by federating with a gigantic channel like the official matrix channel, but for a select few channels on libera.chat with hundreds of people, I am still yet to break over half a gigabyte of memory used. It's also refreshing seeing RocksDB being used as opposed to Postgres, at least for ease of deployment. I run Conduit in a single container and have all of its data in a single volume. I think a large reason why memory consumption is very low compared to Synapse is because I don't have to deploy Postgres. (Yes, I am aware Synapse also supports SQLite, but you quickly migrate to Postgres the moment you need to run any popular app service). The only downsides I can think of at the moment are - Lack of SSO support, which means my friends and I have to maintain dedicated accounts for Matrix even though all of my other self-hosted services use OpenID Connect a single IdP. - Conduit does not send read receipts in federated rooms, though you can see read receipts from others.
- Arkanosis 3y ago
  It's great. I've been using it as a single-user Matrix homeserver for a little more than one year now and haven't had any issue with it whatsoever. It's taking around 100 MiB of resident memory and consuming 0% of the CPU on my small server; I've used chat /clients/ that use ten times more than that.
fallat 3y ago
Lol.
the_common_man 3y ago
Link to the new repos?
freedomben 3y ago
There are two related but separate issues here that need to be considered: 1. Relicense to AGPLv3 2. New CLA in place for contributions. For a project like Matrix, the move to AGPLv3 seems clearly a good one. This is not just a library that you add to your app, it's a product in and of itself, and it's been getting abused by proprietary companies who are robbing the ecosystem. From the blog post from Element[1][2]: > Today we have arrived at a crossroads. We have succeeded in making Matrix wildly successful, but Element is losing its ability to compete in the very ecosystem it has created. It is hard for Element to innovate and adapt as quickly as companies whose business model is developing proprietary Matrix-based products and services without the responsibility and costs of maintaining the bulk of Matrix. In order to be fair to our customers, we need to be able to put more focus on them and their specific requirements. This is a major and legitimate problem that could undermine the future of the project, and lead to a world where proprietary versions are king and open source lags behind. The AGPL is a good solution to this problem IMHO. When a project gets to a certain scale, GPL-style protections become important to ensure contributions are being returned instead of hoarded. The Linux kernel being a class case study. The CLA however, I'm not a fan of generally speaking. It appears to exist so that Element can sell proprietary licenses/versions of Matrix, which I'm less sympathetic too. However, without Element, Matrix would not exist and generally they have been good stewards and provide 95% of the contributions (per their claim in the blog post). To me, they deserve benefit of the doubt here. [1]: https://element.io/blog/element-to-adopt-agplv3/ https://element.io/blog/element-to-adopt-agplv3/ [2]: HN thread: https://news.ycombinator.com/item?id=38162275 https://news.ycombinator.com/item?id=38162275
- ensignavenger 3y ago
  I think the AGPLv3 is a poor choice for what is essentially the reference implementation of the Matrix Protocol. The whole point of a protocol is to allow different implementations. Having a base implementation that others can freely fork and develop into whatever they want with whatever license model they want is a good thing for the protocol. I can understand if the Foundation were to maintain a very basic reference implementation- maybe even just a library or set of libraries with no real UI. And then corporations could develop an AGPLv3 (or whatever license they want) Project on top of it. The CLA is an absolute atrocity, though. It is a bright line of perdition. No one should sign it.
twicetwice 3y ago
Oh wow, this is laudably frank in my opinion. They are quite up front about the motivation behind this change. Two relevant excerpts: > Over the last year or two Matrix has evolved from ‘explosive growth’ to being a ‘category’ in its own right. In other words, ‘Matrix-based’ is now specified as a requirement in massive public and private sector tenders - in which multinationals compete to provide Matrix-based products and services. and > Today we have arrived at a crossroads. We have succeeded in making Matrix wildly successful, but Element is losing its ability to compete in the very ecosystem it has created. It is hard for Element to innovate and adapt as quickly as companies whose business model is developing proprietary Matrix-based products and services without the responsibility and costs of maintaining the bulk of Matrix. In order to be fair to our customers, we need to be able to put more focus on them and their specific requirements. So basically, Element can't compete with other companies for the contracts that only exists because of Element's work, because the other companies can focus just on making proprietary extensions for code that Element has more or less the sole burden of maintaining. So Element is saying to those companies, hey, either AGPL your modifications and extensions (AGPL is relevant since if you're running eg sidecar services with Synapse or Dendrite, this will still hit those sidecar services), or pay for a license for our code. This seems fair to me, to be honest. And yeah, I understand people's moral objections to the CLA, but it's necessary for Element's strategy to work. And maybe I'm naive but I do believe Element and the team have Matrix's best interests at heart, they're just also grappling with making money and being self-sustaining, and so I hope that they succeed in that for the sake of the broader Matrix project and ecosystem. This change also does not seem likely to me to affect open-source work or the broader Matrix community for the most part. If you want to self-host a Matrix server this shouldn't change anything for you. All the code you're running is already open-source, you don't need to do anything. Matrix as a protocol and an ecosystem of servers and clients and users won't be affected by this, just companies selling services that are based on Element's open-source code. And protocol governance hasn't changed, it's still in the hands of the Matrix Foundation, and this won't change that. And you can say, hey, Matrix protocol development has always been driven by Element and its priorities and interests—yes, that's absolutely true. But this change won't affect that either! And in fact, if the CLA pushes pushes community development efforts away from Synapse/Dendrite and toward other projects like Conduit[0], then this might even be good for the ecosystem and community governance by decreasing Element/Synapse's influence over the direction protocol, which I'd be happy to see. So yeah, as someone who is self-hosting Synapse and really rooting for an open, free, community-centric Matrix protocol to succeed, I'm not heartbroken over this change. I'm actually even a bit hopeful about what it means for Element and Matrix going forward. [0] https://conduit.rs/ https://conduit.rs/
lifty 3y ago
I welcome this change, with the hope that they will be able to release higher quality server implementations resulting from this change. Question to @Arathorn: is there a plan to consolidate and have a single server implementation? I would love if Dendrite would become the reference implementation and have something works both for self-hosters and big deployments.
- Arathorn 3y ago
  no plan to consolidate; current plan is to keep improving Synapse as a mature & stable server, and use Dendrite as a test bed for new ideas (eg account portability)
phoronixrly 3y ago
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.
ChrisArchitect 3y ago
[dupe] More discussion on the blog post over here: https://news.ycombinator.com/item?id=38162514 https://news.ycombinator.com/item?id=38162514
tommiegannert 3y ago
> We believe in open source because it encourages innovation Sorry, but I was not amused when Dendrite decided to stop accepting PRs because they are a small team. That is far from encouraging innovation. To me, it seemed like lacking in sustainable FOSS management. PRs I sent were rewritten, squashed and merged by the Dendrite team, instead of them just doing reviews and asking me to fix what they considered unfitting(substandard/wrong. I never thought I'd say that a FOSS team is doing too much work, but it seems to me they burned out for some reason. I can only speculate as to the cause. Changing the license is not going to fix that problem. Anyway, I'm still an active Matrix user, and am grateful for all the work they do put into the projects. I just thought it was more fun to be able to contribute.
- zzzeek 3y ago
  > PRs I sent were rewritten, squashed and merged by the Dendrite team, instead of them just doing reviews and asking me to fix what they considered unfitting(substandard/wrong. Core devs rewriting and fixing up PRs typically saves a ton of development effort. We field lots of PRs and while I make my best effort to hold their hand to get tests written and such, at some point it's intensely wasteful of everyone's time to have five, six back and forths trying to get the person to write the test case you are telling them to, which you could write yourself in 90 seconds. never mind then getting contributors to write good docs, good changelog notes in the format your project uses, etc. I'll give them one shot for that stuff then I just do it, I really don't have time to "train a new employee" (who doesnt even want to be trained, they just want their one-line fix) for every single one line change.
  - pabs3 3y ago
    A lot of folks will just walk away from the project after such an experience. Its in the long term interests of a community to bring new contributors up to speed rather than alienating them.
  - YoshiRulz 3y ago
    I second this. As a maintainer, I have a very good understanding of how long it would take (someone familiar with the codebase) to make certain changes. It's far from disrespectful to push before merging when the alternative is to waste both the contributor's time and my own on at least 1 round of purely code style feedback. As a drive-by contributor, I always leave the box checked—the parent commenter seems to be unaware that GitHub gives you this option—in case I wasn't able to match the project's code style, or there's some other reason for the maintainer(s) to make minor changes. Keep in mind that the maintainers could always just squash and clean up afterwards if you were to uncheck it. The idea of maintainers doing what they want to your changeset is really inseparable from PRs as a concept; while I'm in favour of teaching/knowledge-sharing via code reviews, it's not expected and certainly not owed. (Tangentially, I'm finding that with Nix it's now feasible to apply fixes and customisations to packages even if they have "hostile maintainers".)
exabrial 3y ago
I do appreciate _not_ using some home made license, thank you. Personally though, I find the AGPL too restrictive for projects. The [OSI Certified] EUPL I think is perfect: * If you don't modify the code: Behaves like the ASL2.0 * If you do modify the code: * Behaves like the LGPL in that your private codebase remains private, but changes to the library must be submitted back during a 'distribution' event * Behaves like the AGPL: Offering a service that uses the library counts as a 'distribution'
- tristan957 3y ago
  I've never heard of this license before. Thanks for pointing it out.
- robertlagrant 3y ago
  The last point I never understand. E.g. take Redis if it were licenced in that way: where is the line where it counts as a service? Directly exposing a Redis port? Putting a REST API over the top of it and selling a cache as a service? Making a paid for JWT invalidation service that's basically a small application layer of Redis? Or something else?
  - exabrial 3y ago
    I suggest reading the license as IANAL... but my understanding is all three of those would count as a "distribution" event. Keep in mind, you would only need to "make source available" if and only if you modified Redis. And even in that case, you only have to submit the modifications to Redis. So even though a "distribution event" is happening, if there are no changes to the Redis server or client library itself, you're compliant without doing anything else. So yeah, all things considered, it'd be a great license for Redis in my opinion.
    - robertlagrant 3y ago
      I'm referring to the second bullet point, though.
- 3y ago
jordigh 3y ago
> or by contacting Element for an alternative license Ah, selling exceptions. Even Stallman thinks this is legit. https://www.gnu.org/philosophy/selling-exceptions.html https://www.gnu.org/philosophy/selling-exceptions.html
- mgbmtl 3y ago
  A long time ago, I remember a MySQL talk where they explained dual-license as "if you make money, then we make money", while keeping the product FOSS. I think it's a reasonable simplification. And if the company changes the licence, then a A/GPL fork can survive (c.f. Hashicorp, which could have probably avoided their issues with a better licence from the start, but at the time no one expected to be eclipsed by big cloud providers with infinite resources).
- Cu3PO42 3y ago
  While I don't agree with everything Stallman says and does, I really do appreciate that his position on this issue is not just another axiom, but follows purely from other positions he had already established.
jordigh 3y ago
> or by contacting Element for an alternative license Ah, selling exceptions. Even Stallman thinks this is legit. https://www.gnu.org/philosophy/selling-exceptions.html https://www.gnu.org/philosophy/selling-exceptions.html
- thomastjeffery 3y ago
  This is a case where I personally disagree with RMS. Exceptions effectively nullify copyleft. Even so, I appreciate what his position adds to this discussion.
WhyNotHugo 3y ago
So AGPL+CLA: > The benefit of switching to AGPLv3 is that it obliges downstream developers to contribute back to the core project - either by releasing their modifications as open source for the benefit of the whole Matrix ecosystem, or by contacting Element for an alternative license. Future code contributors to Synapse will need to sign a contributor license agreement (CLA) This makes it clear that they intent to ship under some alternative license, for a fee. They’re making others sign an agreement to ensure that they have privilege to ship the project (or forks of it) under a proprietary license. I wouldn’t consider any of this open source any more. These are step that a organisation takes when they want to move to an open core model and screw over the community. What they are doing is a required step to pull the same stunt as terraform. It’s technically still open source today, but this consolidates them into a position to change this at will. Don’t be fooled by the tricky wording that makes this sound like a good thing. These folks are very unambiguously screwing over the community and making it sound otherwise. As usual, remember to never sign a CLA.
- progval 3y ago
  > This makes it clear that they intent to ship under some alternative license, for a fee They already did, as the Apache License allows them to.
  - pgeorgi 3y ago
    The difference is that so far, everybody was allowed to do that. With that change, only they can do that (with new code going forward). And ask developers to jump through hoops for the privilege. That _might_ be the best option for Synapse etc, but it should be clear what they're offering.
- dm319 3y ago
  Isn't this the case for any GPL-like license? Anyone wanting to build commercial software based on GPL-licensed code has a choice - either publish the full source code, or try to negotiate a closed source license with the copyright holder.
- emersion 3y ago
lol768 3y ago
Nice to see AGPL instead of something like the increasingly-popular (non-FOSS) BSL. Copyleft licenses are great, I've seen too many examples of permissively-licensed libraries being taken, worked on by corporations and profited from without any bug fixes/improvements being upstreamed.
ralmidani 3y ago
It’s awkward to ask people to assign everything to you in a way that makes you the only entity that can sell AGPL exceptions. If contributors are paid for their contributions that would be awesome, but it’s not clear that they are.
- hgs3 3y ago
  Nothing awkward about it. Even the FSF requires copyright assignment [1] and is A-okay with selling exceptions [2]. [1] https://www.gnu.org/licenses/why-assign.en.html https://www.gnu.org/licenses/why-assign.en.html [2] https://www.gnu.org/philosophy/selling.en.html https://www.gnu.org/philosophy/selling.en.html
benatkin 3y ago
[flagged]
- jenadine 3y ago
  Have you ever contributed anyway ? If not it was already assymetric since you were just an user and they were providing the software. Anyway, nobody forced you to use their software. Your loss.
  - benatkin 3y ago
    I'm vindicated by not contributing :)
- lrvick 3y ago
  And now they are -more- open. Did you misread their post? AGPL is just forced open source.
  - proto_lambda 3y ago
    Forced open source for everyone but them. They retain copyright and will continue to sell proprietary adaptions, while forbidding everyone else to do the same.
    - lrvick 3y ago
      I will only pay for chat servers with all public code. If they go proprietary they lose my money and support. I would find/fork a LibreMatrix and direct myself and all my clients to use that instead. Openness and accountability is why I use matrix, and expect many others feel the same. It is in the best interest of Element to stay open. After all, end to end encryption is impossible to trust if a central party controls both ends.
      - Arathorn 3y ago
        The reason for the CLA is so we can sell AGPL exceptions to those who are allergic to AGPL, not so we can further relicense down the road.
regularjack 3y ago
Why move the repos from the matrix-org GitHub org to Element's? Feels like that's a step back in what concerns Matrix Foundation assets being untangled from Element.
jpeeler 3y ago
"Element is losing its ability to compete in the very ecosystem it has created" - anybody know what proprietary companies/projects are possibly being referred to here?
- _lvbh 3y ago
  Possibly Beeper? It’s partially proprietary and offers hosted bridges with Discord/Whatsapp/etc. Disclaimer: working part time for them
alphanullmeric 3y ago
AGPL, on the spectrum of “I’m allowed to do whatever I want” to “they heavily restrict what I can do” sits firmly on the right side, alongside patents and other forms of heavy handed government intervention. It sucks how free as in freedom came to mean freedom to make rules about others.
- lannisterstark 3y ago
  >free as in freedom came to mean freedom to make rules about others. Sadly that usually ends up being the end result.
dpc_01234 3y ago
I'm a big fan of AGPL + CLAs. It's a perfect balance where Free Software community gets what it wants (actively maintained, quality, free software that humanity at large can benefit from), while propriety community gets what it wants too (pay and get paid). People who complain about it are naive and entitled thinking that someone can build and maintain something non-trivial for them indefinitely by just pure altruistic sacrifice and just give it away for free. With AGPL + CLAs you get all the benefits of fully free software, while the copyright holders get something in return for their work: a competitive advantage and being able charge someone other than free software community. As a developer signing a CLAs it doesn't bother me at all - my work is freely available to everyone with a license that preserves that freedom for everyone, which is what I cared about. The fact that it can make money to the copyright holder doesn't cost me anything, and is a reward for value they shared. You don't get people bitching nearly as much about MIT, BSD, etc. where ones making most money on it are the usual big tech players in a position to resell it as a service or an appliance. Why does it bother anyone so much that company providing all that FOSS value will be in position to make money?
- oddevan 3y ago
  Thanks for this perspective; I'm arriving at the same point (AGPL + CLA) for a project I'm hoping to launch soon.
gorgoiler 3y ago
Probably a silly question but I’ve always avoided looking at the source code for anything which I think might later want to implement myself. If I avoid others’ IP I can claim I wrote mine in a clean-room and license my code on my own terms. The reason is that I believe if there’s even a whiff of me having seen someone else’s code then I can’t make any claim to the copyright and, in fact, they will claim it instead. So then imagine if I put up a pull request to synapse with a feature or bug fix but — crucially — I do so without signing a CLA. Do orgs like Matrix employ PR reviewers who work in dirty rooms (opposite of clean room) to review these, shielding their core devs from the accusation that they are reading others code without a CLA to transfer the copyright? An attack from a kind of Doctorow-esque scifi story: you publicly fix your competitors bugs for them without assigning copyright, tainting their dev pools’ ability to claim their own code was a clean room implementation.
iFire 3y ago
Dropping Synapse because I can't remix it for commercial uses.
- kweingar 3y ago
  What were you using it for before?
- bb010g 3y ago
  You can remix it for commercial uses going forward. Provide your source code when requested, as required by `AGPL-3.0`, or pay for a commercial license.
ftyers 3y ago
Drew Devault: https://drewdevault.com/2018/10/05/Dont-sign-a-CLA.html https://drewdevault.com/2018/10/05/Dont-sign-a-CLA.html
lucasyvas 3y ago
AGPL is the way. Every time I see BSL I just laugh - the AGPL is enough to scare away people that don't want to contribute back. And the enforced contribution means the original author can incorporate changes they put no effort into back into their own product. IMO the only options for a cloud hosted service are: 1. Closed source 2. AGPL Anything else is a half measure that disproportionately puts users or the business at risk. If they want a CLA, fine. It still enables a fork later. GPL and its derivatives are the only licenses that will stand the test of time for open source products for sale.
COGlory 3y ago
I have never seen as much negativity for an open source project on Hacker News as I have seen in every single Matrix thread. It is unbelievable. The only thing that might come even close is FlatPak. It's been going on for years and years. If anyone doesn't believe me, just click Arathorn's post history and start browsing. I've never understood what Matrix did to deserve this. It's a fantastic project - I've been using it every day since ~2017. It has its problems but it's head and above every other project like it and provides real value. Better still, the Matrix folks seem to really be thinking things through and making, even if not the best (subjective), a well thought out and well explained decision every time they make a decision. I have seen every. single. possible. attack. thrown at Matrix OVER AND OVER again. Every single one. So many quite obviously not in good faith. Matrix is owned by the Jews. Matrix is owned by the CIA. Matrix is owned by Germany. Matrix violates privacy laws. Matrix tricks you into thinking your messages are deleted when they aren't. Matrix (this one's hilarious), BROKE SIGNALS ENCRYPTION (lol). Matrix is scraping all the rooms to sell to Google (lol). XMPP was perfectly fine and we didn't need Matrix. Matrix collects too much metadata. Matrix federates by default. Matrix is too slow (ok fair). Matrix is going to sell out. This has been going on for the 5+ years I've been using Matrix. People have been sounding the alarm for a half decade about how awful and evil Matrix is. Yet it keeps plugging along, solving truly hard problems, getting better and better, and being released openly (I have no idea why, if I were on the Matrix team I'd have ragequit by now). It is absurd the level of criticism that is thrown at a project that has asked no one for anything, and has truly made the world a better place.
- kuschku 3y ago
  You're right, it's absolutely ridiculous. While there are things worthy of criticism (e.g., the protocol based on HTTP polling isn't exactly realtime, decryption errors are mostly just a UI bug in Element, Element in general having many UI bugs, etc) these aren't even close to worth the outright hate Matrix gets here. HN is usually a hypefest for any new technology, but as soon as the topic turns to Matrix the threads immediately become a Mad Max-style wasteland. It makes no sense whatsoever. Especially this thread – a move to AGPL with a dual-licensed option for corporate customers is absolutely fine, Stallman and the FSF support it, and it's the most sustainable way to run a truly free software project. The only reason I can think of why HN would be so hateful towards a license change is that many people here actually used Matrix to build proprietary products and don't want to contribute to upstream (be it with code or money).
lyu07282 3y ago
The problem I have with the AGPL is some companies interpretation of the AGPL. And the FSF or the license itself doesn't help to clarify these issues. For example MinIO had this text on their compliance page: > To "modify" MinIO means to copy from or adapt all or any part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting derivative work is sometimes referred to as a "modified version" or we say that it is "based on" the earlier work. > Passing configuration parameters to a MinIO binary instance constitutes making a modified version, as it does not produce an exact binary copy. > Combining MinIO software as part of a larger software stack triggers your GNU AGPL v3 obligations. > The method of combining does not matter. When MinIO is linked to a larger software stack in any form, including statically, dynamically, pipes, or containerized and invoked remotely, the AGPL v3 applies to your use. What triggers the AGPL v3 obligations is the exchanging data between the larger stack and MinIO. https://web.archive.org/web/20230320134618/https://min.io/compliance https://web.archive.org/web/20230320134618/https://min.io/co... They changed this language now, perhaps understanding now how insane that made them look (or a lawsuit forced them to, no idea): https://min.io/compliance https://min.io/compliance But still, I like the AGPL too in theory, but I understand why many companies don't touch anything AGPL, its a very fuzzy, complicated license that leads to a legitimate uncertainty. For the license to be useful it actually needs to be used by companies in order for them to contribute anything back to begin with, but many are avoiding it like the plague. /edit MinIO also still has this text on their page: "Designed for developers who are building open source applications in compliance with the GNU AGPL v3 license and are able to support themselves. It is fully featured. If you distribute, host or create derivative works of the MinIO software over the network, the GNU AGPL v3 license requires that you also distribute the complete, corresponding source code of the combined work under the same GNU AGPL v3 license. This requirement applies whether or not you modified MinIO." So AGPL (at least in some peoples twisted minds) goes far beyond protecting something from AWS&Co.

178 points by regularjack 3y ago

MR4D 3y ago

I’m confused. Synapse and Dendrite projects are forked. Ok. But then they say they won’t be continuing to fund development and “They’ll need to get their upstream releases from Element’s repositories going forward.” that seems to mean that future downloads should come from Element? That sounds more like a handoff than a fork. Can someone clarify this a bit?

cobertos 3y ago
They say the original repositories predate Element. But no idea on who owns them or who's being forked _from_?
- dbrgn 3y ago
  If I'm not mistaken: The two projects were started by the people that founded Element. When they founded Element, they transferred the projects to the Foundation, to make them more independent. Now, they're taking them back and relicensing them with a reciprocal license (AGPLv3 + CLA) instead of a permissive one (ALv2). I assume this is about other companies using Synapse and Dendrite without contributing back, so now Element wants to be able to sell licenses for the projects, or get contributions. See https://element.io/blog/element-to-adopt-agplv3/ https://element.io/blog/element-to-adopt-agplv3/ for more details.
  - ensignavenger 3y ago
    The CLA isn't reciprocal. Reciprocicity is only one way when you require a CLA.
    - freedomben 3y ago
      I don't think they're saying the CLA is reciprocal, that's a reference to the AGPL which requires you to share any changes you make.
dbrgn 3y ago
From how I understand this: Synapse and Dendrite were Foundation projects, but the contributions came almost exclusively from Element. Element is forking the two projects, and is redirecting their maintenance efforts towards their own forks. This means that the Foundation versions of the projects will not receive active maintenance anymore, and the Foundation does not have the funding to invest in the development themselves. It's a de-facto handoff, unless someone wants to invest significant resources in development of the pre-fork versions of the projects.
themoonisachees 3y ago
The old repos "belong" to the matrix foundation, but the work on them was mostly done by the element team. This is them officializing that synapse and dendrite are element branded projects, not matrix (so yes, it is indeed a handoff), except they are branding this as a fork because the license is changing. They also are changing licences to require downstream forkers to also open-source their changes, ensuring corporate users of matrix contribute back upstream if they modify their implementation (beeper might be in some hot water, though they can very well continue using and maintaining their own fork from the matrix foundation repos with the old licence).
- ensignavenger 3y ago
  It requires all users, whether corporate or not, to release all changes under AGPLv3... the whole point of the Matrix protocol is to talk to other users... so basically everyone triggers the AGPLv3s "network" clause. However, releaseing your code under the AGPLv3 is not the same as upstreaming it. In order to do that, you additionaly have to sign a CLA granting the Element corporation broad and expansive rights to do whatever they please with your code... but you don't get the same rights to their code.
  - goku12 3y ago
    I agree with your assessment of the AGPL-CLA combination. But the initial part seems to be about the Matrix protocol. The projects that were forked and re-licensed are the servers - Synapse, Dendrite, Sygnal, Sydent and MAS. The protocol itself is still under Apache 2.0 (https://spec.matrix.org/latest/ https://spec.matrix.org/latest/), though they seem to have added CLA to it. If so, the protocol doesn't have the problem you pointed out. You could use another server - like Conduit.
    - progval 3y ago
      Where do you see they added a CLA to the protocol? If you are referring to the sign-off, it has always been there and isn't a CLA.
    - 3y ago

huggingmouth 3y ago

Well, the best of luck to them. All I'm really interested in is whether the new (read, old) overloards at Element have serious plans to revive p2p efforts or not. Going off their behavior on certain github issues, I won't hold my breath and will continue to use briar instead.

Spunkie 3y ago
I contacted the foundation funding channel, multiple times,specifically about becoming a member to support p2p development and they don't even have the decency to respond. Honestly this whole thing feels like a bait n switch. Get the community based matrix popular and cozied up with the public sector and then lock that shit down under the element Corp. The foundation, who's job it is apparently to protect/guide matrix outlook and development, now has no ability to actually govern said project.
COGlory 3y ago
>Going off their behavior on certain github issues, I won't hold my breath and will continue to use briar instead. link?
- ycnews 3y ago
  https://code.briarproject.org/briar https://code.briarproject.org/briar

UltimateEdge 3y ago

So does this pretty much boil down to "we are re-licensing Synapse and Dendrite from Apache to AGPL"? In what way is the "owner" of the code significant, in this case, other than being a proxy for the maintainer of the most popular fork? These projects are open source, so the only thing this code is really attached to is the license. Whatever entity controls the majority of developer effort effectively controls the future of the project. So far, that entity has been Element, and the features being worked on in the client and server applications have been and will be influenced by the customers of Element and the sponsors of the Foundation (for an example of this influence, see the biometric/PIN lock introduced in the Element X mobile applications).

freedomben 3y ago
> Whatever entity controls the majority of developer effort effectively controls the future of the project. Yes, but that doesn't preclude others from stepping up with developer effort on the originals, should they want to. Given the widespread use of matrix, this does seem like a possibility.
runiq 3y ago
The point of contention here is not really the license change, but the CLA attached to it. Basically, if you write code for Synapse/Dendrite, submit it to the project, and sign the CLA, the (for-profit) Element Foundation may relicense your code under a proprietary license. It's intended to keep contributions from proprietary clients coming without them fleeing the ship because they see the four letter word AGPL.

Spunkie 3y ago

Such a casual blog post for what is essentially the announcement of the death of the matrix project.

nerdponx 3y ago
Is it the death? I definitely felt like something was wrong, given that the protocol seems to have lots of problems and Dendrite has been in 0.x beta since basically forever. But I don't know what this means practically for Matrix.
- bzmrgonz 3y ago
  Too many people riding their coat-tails and not paying royalties for the hard-work they did and continue to do. I think they should go the CE & paid versioning that other projects have chosen. Let people continue to experiment with CE and once they are in a corporation, "we" can steer our bosses to the paid version. Alternatively, they should move up the stack and offer a clean deployment/hosting option (remove the container ops with a ci/cd direct to their hosting company). The argument is, we have to host this somewhere, why should we give peter that which rightfully belongs to John? So if John Matrix get into the hosting business, problem solved.
  - lannisterstark 3y ago
    >not paying royalties It's an open source project. What royalties? >continue to do and are 100% allowed to. > I think they should go the CE & paid versioning that other projects have chosen. I don't think that'd be the best idea, it works for other projects because they're not essentially acting as defacto communication protocols.
freedomben 3y ago
This seems a little premature. It reminds me of Monty Python and the Holy Grail where the "bring out your dead" cart[1] is coming and a guy tries to dump a body, and the body says "I'm not dead." It's definitely not a good look, but when taken in context this ironically might be the thing that saves the project from death.[2] [1]: https://youtu.be/Jdf5EXo6I68?si=CGv7j8J5H1XnW3i1&t=55 https://youtu.be/Jdf5EXo6I68?si=CGv7j8J5H1XnW3i1&t=55 [2]: https://news.ycombinator.com/item?id=38162275 https://news.ycombinator.com/item?id=38162275

candiddevmike 3y ago

So, what's the next best alternative to Matrix?

ensignavenger 3y ago
Depends on what you want.. XMPP as a protocol is somewhat comparable, but I like the Matrix model better. You can still use the Matrix protocol without adopting this new corporate fork, though.
KirillPanov 3y ago
tox

ensignavenger 3y ago

This really sucks. I have always had great hope for the Matrix protocol. The AGPL isn't my favorite open source license, but it has its place... but a CLA? That is a complete nonstarter. No one should ever sign a CLA that gives a company more rights to your contributions than you get from theirs.

appplication 3y ago
What’s the deal with CLAs? I’m not familiar with them.
- jraph 3y ago
  they allow the company making you sign the CLA change the license the entire project with your contribution in it to what they like, including making it proprietary.
- ensignavenger 3y ago
  When you try to contribute code back upstream, the company will require you to grant them broad rights to do whatever they want with it, including to relicense the code you are contributing under a proprietary license. You do not get the same rights in return to the upstream code. So the company can yake your contributions and go proprietary and you have no recourse.
  - gary_0 3y ago
    I'm surprised it's not more of a thing to have a CLA that allows relicensing only to another OSI-approved license. I don't see many examples along those lines[0]. And the "OSI-approved" wording would allow a project to freely switch between MIT/BSD/GPL/etc or even create their own license (as long as they get it OSI-approved) without having to hunt down past contributors for permission. I would never sign an open-ended CLA, though. For all I know, the project (with my code in it) could end up being bought by Oracle, proprietized, and used by Larry Ellison to construct the Torment Nexus. [0] https://en.wikipedia.org/wiki/Contributor_License_Agreement#CLAs_which_restrict_relicensing https://en.wikipedia.org/wiki/Contributor_License_Agreement#...

Andrew018 3y ago

[dead]

vbezhenar 3y ago

They keep open source license, so why not. If money's involved, it's gotta be messy either way and matrix is too convoluted and complex to be developed without money envolved.

ensignavenger 3y ago
The biggest problem isn't the new license... not a fan of it at all... but the biggest problem is the CLA.
- vbezhenar 3y ago
  They want to sell sources with alternative license, it's part of their business plan, so CLA is unavoidable.
  - jraph 3y ago
    If I understand correctly: Synapse and Dendrite have been under Apache 2.0 so far, which would allow anyone to turn them into proprietary products. Including Element. With this change, the situation is: Element can make them proprietary but no one else.
    - runiq 3y ago
      Not exactly, but close. The CLA gives them the ability to relicense, which affects proprietary products built on top of Synapse/Dendrite. Without the CLA, all code written against the AGPL-licensed Synapse/Dendrite would have to be licensed AGPL as well, even if it interacts with Synapse/Dendrite over network boundaries as part of a SAAS offering or somesuch. I believe that's why 'AGPL' is a four letter word in certain circles. Disclaimer: I am not a lawyer.
      - ryukafalz 3y ago
        No, that's a common misconception. The relevant section of the license is: > Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This does not state that you must license any of your software that interacts with the AGPL code over the network as AGPL, merely that you make modified versions of the AGPL code available to users who interact with it over the network licensed as AGPL. The rest of the license generally behaves as the GPL would.

WhatIsDukkha 3y ago

Reminder - https://conduit.rs/ https://conduit.rs/ Rust implementation of the matrix server stack

COGlory 3y ago
If I were starting today, I'd be using conduit, but as it stands, I'm on Synapse and have no migration path for my server.
koito17 3y ago
I've been using Conduit as my matrix server with the help of a few programs I wrote myself to ensure admin user exists etc. I am really impressed with how little resources Conduit uses. A fresh install with a few rooms was only consuming about 32 MiB of RAM. Compared to both Synapse and Dendrite, this is nothing! I haven't stress tested the server by federating with a gigantic channel like the official matrix channel, but for a select few channels on libera.chat with hundreds of people, I am still yet to break over half a gigabyte of memory used. It's also refreshing seeing RocksDB being used as opposed to Postgres, at least for ease of deployment. I run Conduit in a single container and have all of its data in a single volume. I think a large reason why memory consumption is very low compared to Synapse is because I don't have to deploy Postgres. (Yes, I am aware Synapse also supports SQLite, but you quickly migrate to Postgres the moment you need to run any popular app service). The only downsides I can think of at the moment are - Lack of SSO support, which means my friends and I have to maintain dedicated accounts for Matrix even though all of my other self-hosted services use OpenID Connect a single IdP. - Conduit does not send read receipts in federated rooms, though you can see read receipts from others.
Arkanosis 3y ago
It's great. I've been using it as a single-user Matrix homeserver for a little more than one year now and haven't had any issue with it whatsoever. It's taking around 100 MiB of resident memory and consuming 0% of the CPU on my small server; I've used chat /clients/ that use ten times more than that.

fallat 3y ago

Lol.

the_common_man 3y ago

Link to the new repos?

freedomben 3y ago

There are two related but separate issues here that need to be considered: 1. Relicense to AGPLv3 2. New CLA in place for contributions. For a project like Matrix, the move to AGPLv3 seems clearly a good one. This is not just a library that you add to your app, it's a product in and of itself, and it's been getting abused by proprietary companies who are robbing the ecosystem. From the blog post from Element[1][2]: > Today we have arrived at a crossroads. We have succeeded in making Matrix wildly successful, but Element is losing its ability to compete in the very ecosystem it has created. It is hard for Element to innovate and adapt as quickly as companies whose business model is developing proprietary Matrix-based products and services without the responsibility and costs of maintaining the bulk of Matrix. In order to be fair to our customers, we need to be able to put more focus on them and their specific requirements. This is a major and legitimate problem that could undermine the future of the project, and lead to a world where proprietary versions are king and open source lags behind. The AGPL is a good solution to this problem IMHO. When a project gets to a certain scale, GPL-style protections become important to ensure contributions are being returned instead of hoarded. The Linux kernel being a class case study. The CLA however, I'm not a fan of generally speaking. It appears to exist so that Element can sell proprietary licenses/versions of Matrix, which I'm less sympathetic too. However, without Element, Matrix would not exist and generally they have been good stewards and provide 95% of the contributions (per their claim in the blog post). To me, they deserve benefit of the doubt here. [1]: https://element.io/blog/element-to-adopt-agplv3/ https://element.io/blog/element-to-adopt-agplv3/ [2]: HN thread: https://news.ycombinator.com/item?id=38162275 https://news.ycombinator.com/item?id=38162275

ensignavenger 3y ago
I think the AGPLv3 is a poor choice for what is essentially the reference implementation of the Matrix Protocol. The whole point of a protocol is to allow different implementations. Having a base implementation that others can freely fork and develop into whatever they want with whatever license model they want is a good thing for the protocol. I can understand if the Foundation were to maintain a very basic reference implementation- maybe even just a library or set of libraries with no real UI. And then corporations could develop an AGPLv3 (or whatever license they want) Project on top of it. The CLA is an absolute atrocity, though. It is a bright line of perdition. No one should sign it.

twicetwice 3y ago

Oh wow, this is laudably frank in my opinion. They are quite up front about the motivation behind this change. Two relevant excerpts: > Over the last year or two Matrix has evolved from ‘explosive growth’ to being a ‘category’ in its own right. In other words, ‘Matrix-based’ is now specified as a requirement in massive public and private sector tenders - in which multinationals compete to provide Matrix-based products and services. and > Today we have arrived at a crossroads. We have succeeded in making Matrix wildly successful, but Element is losing its ability to compete in the very ecosystem it has created. It is hard for Element to innovate and adapt as quickly as companies whose business model is developing proprietary Matrix-based products and services without the responsibility and costs of maintaining the bulk of Matrix. In order to be fair to our customers, we need to be able to put more focus on them and their specific requirements. So basically, Element can't compete with other companies for the contracts that only exists because of Element's work, because the other companies can focus just on making proprietary extensions for code that Element has more or less the sole burden of maintaining. So Element is saying to those companies, hey, either AGPL your modifications and extensions (AGPL is relevant since if you're running eg sidecar services with Synapse or Dendrite, this will still hit those sidecar services), or pay for a license for our code. This seems fair to me, to be honest. And yeah, I understand people's moral objections to the CLA, but it's necessary for Element's strategy to work. And maybe I'm naive but I do believe Element and the team have Matrix's best interests at heart, they're just also grappling with making money and being self-sustaining, and so I hope that they succeed in that for the sake of the broader Matrix project and ecosystem. This change also does not seem likely to me to affect open-source work or the broader Matrix community for the most part. If you want to self-host a Matrix server this shouldn't change anything for you. All the code you're running is already open-source, you don't need to do anything. Matrix as a protocol and an ecosystem of servers and clients and users won't be affected by this, just companies selling services that are based on Element's open-source code. And protocol governance hasn't changed, it's still in the hands of the Matrix Foundation, and this won't change that. And you can say, hey, Matrix protocol development has always been driven by Element and its priorities and interests—yes, that's absolutely true. But this change won't affect that either! And in fact, if the CLA pushes pushes community development efforts away from Synapse/Dendrite and toward other projects like Conduit[0], then this might even be good for the ecosystem and community governance by decreasing Element/Synapse's influence over the direction protocol, which I'd be happy to see. So yeah, as someone who is self-hosting Synapse and really rooting for an open, free, community-centric Matrix protocol to succeed, I'm not heartbroken over this change. I'm actually even a bit hopeful about what it means for Element and Matrix going forward. [0] https://conduit.rs/ https://conduit.rs/

lifty 3y ago

I welcome this change, with the hope that they will be able to release higher quality server implementations resulting from this change. Question to @Arathorn: is there a plan to consolidate and have a single server implementation? I would love if Dendrite would become the reference implementation and have something works both for self-hosters and big deployments.

Arathorn 3y ago
no plan to consolidate; current plan is to keep improving Synapse as a mature & stable server, and use Dendrite as a test bed for new ideas (eg account portability)

phoronixrly 3y ago

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.

ChrisArchitect 3y ago

[dupe] More discussion on the blog post over here: https://news.ycombinator.com/item?id=38162514 https://news.ycombinator.com/item?id=38162514

tommiegannert 3y ago

> We believe in open source because it encourages innovation Sorry, but I was not amused when Dendrite decided to stop accepting PRs because they are a small team. That is far from encouraging innovation. To me, it seemed like lacking in sustainable FOSS management. PRs I sent were rewritten, squashed and merged by the Dendrite team, instead of them just doing reviews and asking me to fix what they considered unfitting(substandard/wrong. I never thought I'd say that a FOSS team is doing too much work, but it seems to me they burned out for some reason. I can only speculate as to the cause. Changing the license is not going to fix that problem. Anyway, I'm still an active Matrix user, and am grateful for all the work they do put into the projects. I just thought it was more fun to be able to contribute.

zzzeek 3y ago
> PRs I sent were rewritten, squashed and merged by the Dendrite team, instead of them just doing reviews and asking me to fix what they considered unfitting(substandard/wrong. Core devs rewriting and fixing up PRs typically saves a ton of development effort. We field lots of PRs and while I make my best effort to hold their hand to get tests written and such, at some point it's intensely wasteful of everyone's time to have five, six back and forths trying to get the person to write the test case you are telling them to, which you could write yourself in 90 seconds. never mind then getting contributors to write good docs, good changelog notes in the format your project uses, etc. I'll give them one shot for that stuff then I just do it, I really don't have time to "train a new employee" (who doesnt even want to be trained, they just want their one-line fix) for every single one line change.
- pabs3 3y ago
  A lot of folks will just walk away from the project after such an experience. Its in the long term interests of a community to bring new contributors up to speed rather than alienating them.
- YoshiRulz 3y ago
  I second this. As a maintainer, I have a very good understanding of how long it would take (someone familiar with the codebase) to make certain changes. It's far from disrespectful to push before merging when the alternative is to waste both the contributor's time and my own on at least 1 round of purely code style feedback. As a drive-by contributor, I always leave the box checked—the parent commenter seems to be unaware that GitHub gives you this option—in case I wasn't able to match the project's code style, or there's some other reason for the maintainer(s) to make minor changes. Keep in mind that the maintainers could always just squash and clean up afterwards if you were to uncheck it. The idea of maintainers doing what they want to your changeset is really inseparable from PRs as a concept; while I'm in favour of teaching/knowledge-sharing via code reviews, it's not expected and certainly not owed. (Tangentially, I'm finding that with Nix it's now feasible to apply fixes and customisations to packages even if they have "hostile maintainers".)

exabrial 3y ago

I do appreciate _not_ using some home made license, thank you. Personally though, I find the AGPL too restrictive for projects. The [OSI Certified] EUPL I think is perfect: * If you don't modify the code: Behaves like the ASL2.0 * If you do modify the code: * Behaves like the LGPL in that your private codebase remains private, but changes to the library must be submitted back during a 'distribution' event * Behaves like the AGPL: Offering a service that uses the library counts as a 'distribution'

tristan957 3y ago
I've never heard of this license before. Thanks for pointing it out.
robertlagrant 3y ago
The last point I never understand. E.g. take Redis if it were licenced in that way: where is the line where it counts as a service? Directly exposing a Redis port? Putting a REST API over the top of it and selling a cache as a service? Making a paid for JWT invalidation service that's basically a small application layer of Redis? Or something else?
- exabrial 3y ago
  I suggest reading the license as IANAL... but my understanding is all three of those would count as a "distribution" event. Keep in mind, you would only need to "make source available" if and only if you modified Redis. And even in that case, you only have to submit the modifications to Redis. So even though a "distribution event" is happening, if there are no changes to the Redis server or client library itself, you're compliant without doing anything else. So yeah, all things considered, it'd be a great license for Redis in my opinion.
  - robertlagrant 3y ago
    I'm referring to the second bullet point, though.
3y ago

jordigh 3y ago

> or by contacting Element for an alternative license Ah, selling exceptions. Even Stallman thinks this is legit. https://www.gnu.org/philosophy/selling-exceptions.html https://www.gnu.org/philosophy/selling-exceptions.html

mgbmtl 3y ago
A long time ago, I remember a MySQL talk where they explained dual-license as "if you make money, then we make money", while keeping the product FOSS. I think it's a reasonable simplification. And if the company changes the licence, then a A/GPL fork can survive (c.f. Hashicorp, which could have probably avoided their issues with a better licence from the start, but at the time no one expected to be eclipsed by big cloud providers with infinite resources).
Cu3PO42 3y ago
While I don't agree with everything Stallman says and does, I really do appreciate that his position on this issue is not just another axiom, but follows purely from other positions he had already established.

jordigh 3y ago

thomastjeffery 3y ago
This is a case where I personally disagree with RMS. Exceptions effectively nullify copyleft. Even so, I appreciate what his position adds to this discussion.

WhyNotHugo 3y ago

So AGPL+CLA: > The benefit of switching to AGPLv3 is that it obliges downstream developers to contribute back to the core project - either by releasing their modifications as open source for the benefit of the whole Matrix ecosystem, or by contacting Element for an alternative license. Future code contributors to Synapse will need to sign a contributor license agreement (CLA) This makes it clear that they intent to ship under some alternative license, for a fee. They’re making others sign an agreement to ensure that they have privilege to ship the project (or forks of it) under a proprietary license. I wouldn’t consider any of this open source any more. These are step that a organisation takes when they want to move to an open core model and screw over the community. What they are doing is a required step to pull the same stunt as terraform. It’s technically still open source today, but this consolidates them into a position to change this at will. Don’t be fooled by the tricky wording that makes this sound like a good thing. These folks are very unambiguously screwing over the community and making it sound otherwise. As usual, remember to never sign a CLA.

progval 3y ago
> This makes it clear that they intent to ship under some alternative license, for a fee They already did, as the Apache License allows them to.
- pgeorgi 3y ago
  The difference is that so far, everybody was allowed to do that. With that change, only they can do that (with new code going forward). And ask developers to jump through hoops for the privilege. That _might_ be the best option for Synapse etc, but it should be clear what they're offering.
dm319 3y ago
Isn't this the case for any GPL-like license? Anyone wanting to build commercial software based on GPL-licensed code has a choice - either publish the full source code, or try to negotiate a closed source license with the copyright holder.
emersion 3y ago

lol768 3y ago

Nice to see AGPL instead of something like the increasingly-popular (non-FOSS) BSL. Copyleft licenses are great, I've seen too many examples of permissively-licensed libraries being taken, worked on by corporations and profited from without any bug fixes/improvements being upstreamed.

ralmidani 3y ago

It’s awkward to ask people to assign everything to you in a way that makes you the only entity that can sell AGPL exceptions. If contributors are paid for their contributions that would be awesome, but it’s not clear that they are.

hgs3 3y ago
Nothing awkward about it. Even the FSF requires copyright assignment [1] and is A-okay with selling exceptions [2]. [1] https://www.gnu.org/licenses/why-assign.en.html https://www.gnu.org/licenses/why-assign.en.html [2] https://www.gnu.org/philosophy/selling.en.html https://www.gnu.org/philosophy/selling.en.html

benatkin 3y ago

[flagged]

jenadine 3y ago
Have you ever contributed anyway ? If not it was already assymetric since you were just an user and they were providing the software. Anyway, nobody forced you to use their software. Your loss.
- benatkin 3y ago
  I'm vindicated by not contributing :)
lrvick 3y ago
And now they are -more- open. Did you misread their post? AGPL is just forced open source.
- proto_lambda 3y ago
  Forced open source for everyone but them. They retain copyright and will continue to sell proprietary adaptions, while forbidding everyone else to do the same.
  - lrvick 3y ago
    I will only pay for chat servers with all public code. If they go proprietary they lose my money and support. I would find/fork a LibreMatrix and direct myself and all my clients to use that instead. Openness and accountability is why I use matrix, and expect many others feel the same. It is in the best interest of Element to stay open. After all, end to end encryption is impossible to trust if a central party controls both ends.
    - Arathorn 3y ago
      The reason for the CLA is so we can sell AGPL exceptions to those who are allergic to AGPL, not so we can further relicense down the road.

regularjack 3y ago

Why move the repos from the matrix-org GitHub org to Element's? Feels like that's a step back in what concerns Matrix Foundation assets being untangled from Element.

jpeeler 3y ago

"Element is losing its ability to compete in the very ecosystem it has created" - anybody know what proprietary companies/projects are possibly being referred to here?

_lvbh 3y ago
Possibly Beeper? It’s partially proprietary and offers hosted bridges with Discord/Whatsapp/etc. Disclaimer: working part time for them

alphanullmeric 3y ago

AGPL, on the spectrum of “I’m allowed to do whatever I want” to “they heavily restrict what I can do” sits firmly on the right side, alongside patents and other forms of heavy handed government intervention. It sucks how free as in freedom came to mean freedom to make rules about others.

lannisterstark 3y ago
>free as in freedom came to mean freedom to make rules about others. Sadly that usually ends up being the end result.

dpc_01234 3y ago

I'm a big fan of AGPL + CLAs. It's a perfect balance where Free Software community gets what it wants (actively maintained, quality, free software that humanity at large can benefit from), while propriety community gets what it wants too (pay and get paid). People who complain about it are naive and entitled thinking that someone can build and maintain something non-trivial for them indefinitely by just pure altruistic sacrifice and just give it away for free. With AGPL + CLAs you get all the benefits of fully free software, while the copyright holders get something in return for their work: a competitive advantage and being able charge someone other than free software community. As a developer signing a CLAs it doesn't bother me at all - my work is freely available to everyone with a license that preserves that freedom for everyone, which is what I cared about. The fact that it can make money to the copyright holder doesn't cost me anything, and is a reward for value they shared. You don't get people bitching nearly as much about MIT, BSD, etc. where ones making most money on it are the usual big tech players in a position to resell it as a service or an appliance. Why does it bother anyone so much that company providing all that FOSS value will be in position to make money?

oddevan 3y ago
Thanks for this perspective; I'm arriving at the same point (AGPL + CLA) for a project I'm hoping to launch soon.

gorgoiler 3y ago

Probably a silly question but I’ve always avoided looking at the source code for anything which I think might later want to implement myself. If I avoid others’ IP I can claim I wrote mine in a clean-room and license my code on my own terms. The reason is that I believe if there’s even a whiff of me having seen someone else’s code then I can’t make any claim to the copyright and, in fact, they will claim it instead. So then imagine if I put up a pull request to synapse with a feature or bug fix but — crucially — I do so without signing a CLA. Do orgs like Matrix employ PR reviewers who work in dirty rooms (opposite of clean room) to review these, shielding their core devs from the accusation that they are reading others code without a CLA to transfer the copyright? An attack from a kind of Doctorow-esque scifi story: you publicly fix your competitors bugs for them without assigning copyright, tainting their dev pools’ ability to claim their own code was a clean room implementation.

iFire 3y ago

Dropping Synapse because I can't remix it for commercial uses.

kweingar 3y ago
What were you using it for before?
bb010g 3y ago
You can remix it for commercial uses going forward. Provide your source code when requested, as required by `AGPL-3.0`, or pay for a commercial license.

ftyers 3y ago

Drew Devault: https://drewdevault.com/2018/10/05/Dont-sign-a-CLA.html https://drewdevault.com/2018/10/05/Dont-sign-a-CLA.html

lucasyvas 3y ago

AGPL is the way. Every time I see BSL I just laugh - the AGPL is enough to scare away people that don't want to contribute back. And the enforced contribution means the original author can incorporate changes they put no effort into back into their own product. IMO the only options for a cloud hosted service are: 1. Closed source 2. AGPL Anything else is a half measure that disproportionately puts users or the business at risk. If they want a CLA, fine. It still enables a fork later. GPL and its derivatives are the only licenses that will stand the test of time for open source products for sale.

COGlory 3y ago

I have never seen as much negativity for an open source project on Hacker News as I have seen in every single Matrix thread. It is unbelievable. The only thing that might come even close is FlatPak. It's been going on for years and years. If anyone doesn't believe me, just click Arathorn's post history and start browsing. I've never understood what Matrix did to deserve this. It's a fantastic project - I've been using it every day since ~2017. It has its problems but it's head and above every other project like it and provides real value. Better still, the Matrix folks seem to really be thinking things through and making, even if not the best (subjective), a well thought out and well explained decision every time they make a decision. I have seen every. single. possible. attack. thrown at Matrix OVER AND OVER again. Every single one. So many quite obviously not in good faith. Matrix is owned by the Jews. Matrix is owned by the CIA. Matrix is owned by Germany. Matrix violates privacy laws. Matrix tricks you into thinking your messages are deleted when they aren't. Matrix (this one's hilarious), BROKE SIGNALS ENCRYPTION (lol). Matrix is scraping all the rooms to sell to Google (lol). XMPP was perfectly fine and we didn't need Matrix. Matrix collects too much metadata. Matrix federates by default. Matrix is too slow (ok fair). Matrix is going to sell out. This has been going on for the 5+ years I've been using Matrix. People have been sounding the alarm for a half decade about how awful and evil Matrix is. Yet it keeps plugging along, solving truly hard problems, getting better and better, and being released openly (I have no idea why, if I were on the Matrix team I'd have ragequit by now). It is absurd the level of criticism that is thrown at a project that has asked no one for anything, and has truly made the world a better place.

kuschku 3y ago
You're right, it's absolutely ridiculous. While there are things worthy of criticism (e.g., the protocol based on HTTP polling isn't exactly realtime, decryption errors are mostly just a UI bug in Element, Element in general having many UI bugs, etc) these aren't even close to worth the outright hate Matrix gets here. HN is usually a hypefest for any new technology, but as soon as the topic turns to Matrix the threads immediately become a Mad Max-style wasteland. It makes no sense whatsoever. Especially this thread – a move to AGPL with a dual-licensed option for corporate customers is absolutely fine, Stallman and the FSF support it, and it's the most sustainable way to run a truly free software project. The only reason I can think of why HN would be so hateful towards a license change is that many people here actually used Matrix to build proprietary products and don't want to contribute to upstream (be it with code or money).

lyu07282 3y ago

The problem I have with the AGPL is some companies interpretation of the AGPL. And the FSF or the license itself doesn't help to clarify these issues. For example MinIO had this text on their compliance page: > To "modify" MinIO means to copy from or adapt all or any part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting derivative work is sometimes referred to as a "modified version" or we say that it is "based on" the earlier work. > Passing configuration parameters to a MinIO binary instance constitutes making a modified version, as it does not produce an exact binary copy. > Combining MinIO software as part of a larger software stack triggers your GNU AGPL v3 obligations. > The method of combining does not matter. When MinIO is linked to a larger software stack in any form, including statically, dynamically, pipes, or containerized and invoked remotely, the AGPL v3 applies to your use. What triggers the AGPL v3 obligations is the exchanging data between the larger stack and MinIO. https://web.archive.org/web/20230320134618/https://min.io/compliance https://web.archive.org/web/20230320134618/https://min.io/co... They changed this language now, perhaps understanding now how insane that made them look (or a lawsuit forced them to, no idea): https://min.io/compliance https://min.io/compliance But still, I like the AGPL too in theory, but I understand why many companies don't touch anything AGPL, its a very fuzzy, complicated license that leads to a legitimate uncertainty. For the license to be useful it actually needs to be used by companies in order for them to contribute anything back to begin with, but many are avoiding it like the plague. /edit MinIO also still has this text on their page: "Designed for developers who are building open source applications in compliance with the GNU AGPL v3 license and are able to support themselves. It is fully featured. If you distribute, host or create derivative works of the MinIO software over the network, the GNU AGPL v3 license requires that you also distribute the complete, corresponding source code of the combined work under the same GNU AGPL v3 license. This requirement applies whether or not you modified MinIO." So AGPL (at least in some peoples twisted minds) goes far beyond protecting something from AWS&Co.