Element informed the Foundation that it will be forking Synapse and Dendrite: https://matrix.org/blog/2023/11/06/future-of-synapse-dendrite/
We'll do our best to answer your questions, address concerns, and find a path forward together.
@matrix Haven't we learned anything from repeated CLA debacles? I welcome the license change to AGPLv3, but making future contributors sign a CLA means Element could change the license again to be no longer open source. Then the community would have to fork it again, like with Terraform and OpenTofu.
I'm with Drew on this: https://drewdevault.com/2023/07/04/Dont-sign-a-CLA-2.html
@skyfaller @matrix keep in mind that CLAs vary from project to project. Some CLAs may not even have any clause to transfer your copyright.
But yes, I certainly agree that they shouldn't be using a CLA.
@TheEvilSkeleton @skyfaller @matrix So does Qt.
If your intention is to commercialise, perhaps consult with them.
@TheEvilSkeleton @skyfaller @matrix for clarity: Fedora doesn't have a CLA. The Fedora Project Contributor Agreement essentially just sets default licenses for contributions: https://docs.fedoraproject.org/en-US/legal/fpca/
@skyfaller @matrix I agree in general, but they could have relicensed right now to a proprietary license too, so the CLA doesn't really give them any new rights that they didn't have before.
That said, the Element team being the primary contributors to the project is itself concerning. I do think that the structure of the Matrix protocol itself limits their ability to do harm thankfully.
@jfred @skyfaller We think this is a great opportunity for the ecosystem to shine, and highlight that the spec remains open source *and* under open governance – though we will also be the first to note that our governance needs improvement.
Broadly speaking, we find it concerning when any major open source project is dominated by a single contributor. We look forward to channeling our resources to help improve the size and diversity of the contributor ecosystem in the months and years ahead!
Have you ever contemplated why the Matrix contributor ecosystem has not grown as much as you expected so far? Don't you think not-so-good communications by those who both contribute to specs and Element might have discouraged possible contributors from even entering the ecosystem? For example, check the discussion full of mistrust and resentment: https://github.com/vector-im/element-meta/issues/339.
I guess it is a matter which cannot be solved by changing licenses or replacing DCO with CLA, etc
@jfred @skyfaller @matrix moving the projects under their wing does permit them to conduct EEE (or even: can be the Embrace step). It's one thing if they relicense their fork now, and another - if they do it after Extending it significantly enough to make the Foundation's version irrelevant.
To be clear: I'm not saying they will, but that's a possibility we need to consider.
@skyfaller Indeed, we'd prefer that these projects remain under our auspices, open source, and unencumbered by a CLA.
For the avoidance of doubt, the Foundation's mission and rules forbid us from acting for the private benefit of any party, and as such we cannot contribute anything that requires us to sign a CLA wherein the assignment is made to a privately-held entity.
We are committed to building up the open source commons around Matrix.
@matrix "while encouraging proprietary forks" 
@[email protected] @[email protected]
while encouraging proprietary forks to contribute to the development costs of the underlying project
I...don't see the problem? The Apache license means they don't have to share sources, but the AGPL does.@privateger @matrix You don't see the problem in there being a proprietary fork of the matrix server software?
@[email protected] @[email protected] That's not what they're saying.
These forks can already be made. APL means they don't have to share anything back.
Switching to AGPL means they're forced to share modified source code. This is a stricter copyleft license.
@privateger @matrix Oh i misread that then. True.
@catraxx @privateger @matrix Note, that (A)GPL does not exclude the option to sell a product. The source code has to be attached.
(The customer could then pass it forward free of charge).
@matrix a very bad sign for the whole ecosystem I fear :/
I hope this benefits independent implementations more in the end, mature homeservers made by the community
@matrix to be fair, the fork in itself reflects reality and is very fair - element has (always) been the main force behind development.
Still taking ownership of the project entirely is pretty bad. It changes synapse (lefts face it, dendrite has been degraded to a playground) from being the forefront of a free, open source messaging ecosystem to an asset of the company, in the hope to get people to pay for developing it further I assume.
@networkexception @matrix good I had the plans to implement a direct messaging feature into iceshrimp and thus activitypub, making us able to just send end to end encrypted chats over here. might be the more mature ecosystem actually than matrix
@aprl @matrix do that, I personally dont believe in ActivityPub based private messaging though. Matrix is a protocol thats pretty much only good at chat, and given that its implemented correctly (something something Matrix bad because all implementations suck in some way; also something something rust-sdk solves all our problems) it is *really* good at that (with tradeoffs, ofc).
1/n
@networkexception @matrix okay so, to understand me correctly, my idea is to implement the matrix principles in activitypub. activitypub is so barebones it doesnt limit you in what you can do. and my plans will need support from both clients and servers. yes, this will be difficult, but it can be done. and when I am done, so my plan is, it will also be intercompatible with current matrix servers like synapse or conduit. but for beginners: i am prototyping matrix encryption using the AP model-
matrix protocol, ramlings, possible (bad) future
@matrix this ecosystem as a whole is way too dependent on element. This might be the wake up call? I really dont want it to die, at least some version meant for interoperability of huge companies will probably survive given the IETFs MIMI efforts but we would loose the tiny bit of free, partly (mostly?) self hosting community driven instant messaging infrastructure
matrix protocol, ramlings, possible (bad) future
@networkexception @matrix Seirdy ( @Seirdy ) touched on this same concern in one of their blog posts a while back, and I share this concern as well. When Matrix was first announced I thought it was a bright spot in the darkness of walled-off IM services; with this move now I'm even less sure about that.
https://seirdy.one/posts/2021/02/23/keeping-platforms-open/#how-open-platforms-become-closed
matrix protocol, ramlings, possible (bad) future
@networkexception Yes, there's broad agreement internally and externally that we want to see an ecosystem that has a more diverse contributor base and fundamentally doesn't hinge so much on a single vendor.
@networkexception @matrix Yes, I think that if there's one takeaway from this, its that the sole focus on Element/Synapse around the ecosystem is quite terrible. The fact that I need to feel worried reading this announcement concerning the continued development of a set of homeserver implementations means that the "protocol" aspect of Matrix clearly isn't embraced sufficiently.
@networkexception While we hope that Element's decision has the intended impacts for them and the broader ecosystem, we do also hope this shines a spotlight on the rest of the ecosystem.
We want to see a world in which the Matrix ecosystem includes multiple stable, popular open source implementations of servers and clients.
@matrix yikes. Ever more reasons to move to conduit on the server side and anything other than Element on the client.
@lambda This is definitely a good time for the rest of the ecosystem to shine!
How about not forking anything and finish what you already got
@a1ba There are several entities in the mix here, and the Foundation isn't the one doing the forking.
@captainepoch Yes, we're hearing a lot about that detail, and understandably so. The Foundation's position is that we'd prefer for the projects to remain under our auspices and unencumbered by a CLA.
@matrix will it be possible to contribute to the foundations repositories after the fork?
@baltakatei @matrix Depends what the CLA states ... they aren't inherently bad.
@baltakatei Indeed, the Foundation's position is that we'd prefer for the projects to remain under our auspices and unencumbered by a CLA.
I have two questions. Given the following:
"Synapse and Dendrite have been under the auspices of the Foundation since 2019. Our role has been to hold the assets and provide some infrastructure."
"The vast majority of maintenance and development on these projects comes from folks working at Element."
I see that both Synapse and Dendrite are under the matrix-org namespace on Github.
Could you elaborate a bit further on how much of current Synapse/Dendrite development is done by the Element/Foundation folks? What is "assets", "maintenance" and "infrastructure" in this case?
Where would the forks be hosted, given the original projects are already on Github under matrix-org?
@herzenschein To your questions:
1) The Foundation itself never did maintenance or development of either project.
2) Assets refers to the copyrights, or at least those which Element was entitled to assign to the Foundation in the first place.
3) Infrastructure here refers to the GitHub org, repo, and communications infrastructure including Matrix rooms and their moderation.
4) Our understanding is that the forks will live under a GH org belonging to Element.
@[email protected] I’m done.
@matrix Hrm. Why is a DCO no longer deemed sufficient?
@larsmb The Foundation's position is that we'd prefer the projects remain under our auspices and unencumbered by a CLA.
As Element is the one implementing a CLA on their forks of the projects, this is a question that only they can answer.
@matrix This post starts off with "Last week, Element informed the Foundation that it will be forking Synapse and Dendrite."
It reads like this was news to The Matrix Foundation, and that the foundation was not prepared for it.
Is that true? If so, it's very distressing -- If Element and The Matrix Foundation are in dispute, it leaves us who are committed to using and promoting #Matrix confused as to what and who to support. I remember the first days of the XFree86/X.org, the OpenOffice/LibreOffice and the Owncloud/Nextcloud forks, and things we're not pleasant.
@eibhear @matrix
#foundation-office:matrix.org join the foundation office room and you'll see discussions on how to improve it and how to stop this from happening in the future with other projects element donate :)
@eibhear There had been rumblings that it was a possibility, but it remained in the abstract and so we at the Foundation kept our limited bandwidth focused elsewhere.
Last week was just when the decision was made, and when it became necessary for us to deploy resources to respond to the change. 1/2
@eibhear Element remains the Foundation's largest supporter. Though there is tension, especially when it comes to matters like this where our positions diverge, we do not expect to be in conflict on more fundamental levels.
A meaningful difference between this situation and the others you mention is that the spec remains open source and under open governance.
While we hope this change has Element's intended results for the ecosystem, this _is_ a time for the rest of the ecosystem to shine. 2/2
@matrix the way this is going, there is no path forward with you...
@matrix I think the Matrix team has done a lot of things right over the years, and think this change should be met with that in mind. I do have a few questions:
1. My reading of the CLA is it's necessary for Element to offer proprietary versions of the software or integration with proprietary changes that would normally violate AGPLv3. Is that correct?
@mirdaki Yes, thank you. We also believe the historical perspective is important in understanding what is happening and what may follow.
With regards to the reasoning for the CLA, our position is that we'd prefer the projects to remain under our auspices and unencumbered by a CLA – and that Element is the only one who can answer the question as to why they're implementing one.
@mirdaki @matrix I'm not affiliated with Element or any company using Matrix, so this is a pure speculation. But I know that some companies still consider hosting AGPL a bit problematic and try to avoid dealing with it. Element being the only company able to provide proprietary licensed builds of Synapse might complicate situation for their competition. (Which could also be one of reasons they do this)
On the bright side, this could bring external financing and devs to Conduit. Even better thing would be if it got public financing, as a lot of public institutions started using Matrix.
@matrix
2. I understand Element is the primary driver of Matrix work and they should be have a sustainable path forward. And that the Foundation isn't funded enough to do development on it's own. I do worry moving the projects back under Element is a bad look for the ecosystem, since it heavily favors Element. Could you describe any circumstances (such as more foundation funding or active contributions for other entities) that would prompt moving the projects back under the foundation?
@mirdaki There are several dimensions to this that are difficult to boil down into a thread. Expect more comms from us soon.
Our view is that the Foundation's role in developing open source software is to fill gaps that others are not addressing.
We would both need to (1) see a gap and (2) have the resources to fund development.
Today, we don't have the funds to even meet current obligations. Fixing that and actualizing open governance are the first big projects of our Managing Director.
@mirdaki @matrix from the Element side: if the Foundation had sufficient funding to pay Element to maintain the projects, then there would be no reason to move them. But instead, this is an attempt to generate enough funding in general (i.e. from dual-licensing to commercial forks) to pay for their development.
Thank you all for your questions!
It's still early on the West Coast of the US where our Managing Director is located, so we're just getting started here.
We'll begin responding to folks shortly.