Element informed the Foundation that it will be forking Synapse and Dendrite: matrix.org/blog/2023/11/06/fut…

We'll do our best to answer your questions, address concerns, and find a path forward together.

reshared this

in reply to The Matrix.org Foundation

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: drewdevault.com/2023/07/04/Don…

reshared this

in reply to Nelson

@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.

in reply to Nelson

@skyfaller 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.

in reply to Jonathan Frederickson

@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!

in reply to The Matrix.org Foundation

@jfred @skyfaller

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 enter the ecosystem? For example, check the discussion full of mistrust and resentment: github.com/vector-im/element-m….

I guess it is a matter which cannot be solved by changing licenses or replacing DCO with CLA, etc.

in reply to networkException

@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.

in reply to The Matrix.org Foundation

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.
  1. 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?
  2. Where would the forks be hosted, given the original projects are already on Github under matrix-org?
in reply to Herz++

@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.

in reply to The Matrix.org Foundation

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?

in reply to Matthew Booe

@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.

in reply to The Matrix.org Foundation

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?
in reply to Matthew Booe

@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.

in reply to yuvipanda

@yuvipanda We're not happy with the changes and our stance is that we'd prefer the projects to remain under our auspices, unencumbered by a CLA.

Given the nature of open source, there's nothing we can do to stop any individual or entity from forking our projects, and that's true of projects at other open source foundations too.

We will be doubling down on our efforts to implement open governance and cultivate a contributor base with a diversity of employers and lived experiences.

in reply to The Matrix.org Foundation

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.

in reply to The Matrix.org Foundation

@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

Unknown parent

mastodon - Link to source

The Matrix.org Foundation

@err931 Absolutely, unequivocally yes.

The spec remains open source and under open governance – noting that Synapse and Dendrite only ever checked one of those boxes. And indeed, the soon-to-be-formed Governing Board will be a significant improvement to current open governance of the spec and the Foundation.

That said, the Governing Board is just the next big step. We intend to continue taking steps to actualize community governance and further enhance the open source commons around Matrix.

in reply to

@csolisr We have every reason to believe the forks will remain interoperable, in part because that is a core selling point for Element.

But should that change, the Foundation's role remains: to act as a neutral custodian and to nurture Matrix as efficiently as possible as a single unfragmented standard, for the greater benefit of the whole ecosystem.

With that in mind, it would absolutely be within our scope to invest in compatibility should we need to.

in reply to Arjen P. de Vries Timmers 🕊️

@arjen @Greg We can't see the reply this was made to so can't respond to original question, but we do want to weigh in on the role of the Foundation:

The Foundation's role is first and foremost to steward the spec under an open source license and open governance.

When it comes to the role of the Foundation in software development, our stance is that our role is to fill gaps that others are not addressing – which is one reason our R&D is currently focused on Trust and Safety.

Unknown parent

mastodon - Link to source

The Matrix.org Foundation

The media in this post is not displayed to visitors. To view it, please go to the original post.

@abbe98 This question is best directed at Element or a legal expert, but we believe the relevant clause will answer your question. Sourced from the ICLA linked from apache.org/licenses/contributo…
in reply to The Matrix.org Foundation

Today is a tough day, and we'd like to thank everyone for the outpouring of support and insightful questions.

We're keeping a log of questions and concerns, will be sharing more answers as we have them.

Keep in mind:

The Matrix spec is the beating heart of the ecosystem. It is under an open source license, and subject to open governance that's slated to become more open when we elect our first Governing Board next year.

#Matrix is bigger than any one or two projects.

in reply to Smol Bean [OLD] (moved to https://evil.social/@shrimple)

@chocolatefossty We definitely like that the new license they chose is still open source! AGPLv3 seems very appropriate, though we'd prefer for the projects to remain with the Foundation and without a CLA.

The net of all this may end up being a boon for Element and/or the ecosystem, that remains to be seen.

In the meantime, it definitely adds to the workload for the Foundation – in navigating the changes, and in building trust in our work.

in reply to The Matrix.org Foundation

I don't fully understand the different licenses in this case. I think I get the overall dilemma. It reminds me of similar license discussions about profit/non-profit and how to keep actors on a competitive commodity market from exploiting commons. I think Dmitry Kleiner did some really important work with the idea of #copyfarleft that perhaps could be built on.
in reply to hamburghammer

@hamburghammer we’re not trying to stab any contributors; the reason for the CLA is that need to be able to provide alternative licenses to commercial forks (as per fsf.org/blogs/rms/selling-exce…); this is the whole reason for the license shift.
in reply to The Matrix.org Foundation

Dear, @element, please be honest:
You write that you want a CLA
> giving Element the right to distribute the contribution commercially
.
When you write "commercially” you mean “proprietary”. Because FLOSS can always be utilised for _all_ cause, including commercial ones and selling it. This is what e.g sets it apart from pretending licenses like the BSL which want to claim all commercial activities just for a single stakeholder.
in reply to Element

@element @schmittlauch You do realize that most open source contributors only contribute because they have a strong belief in open source & want their code to _stay_ FLOSS?

I mean, I get it, Element is struggling to make ends meet, so you're taking a gamble that being the biggest player in the Matrix ecosystem will make people contribute anyway, and that the community doesn't have the resources to maintain Synapse & Dendrite on their own.

You could just ask for donations, you know?

in reply to Campbell Jones

@serebit @schmittlauch the whole blog post is explaining that if we don't find a way to get proprietary forks to contribute back to the core project, either by releasing their code as AGPL, or buying a dual license, then core dev from Element is existentially at risk. It's far from ideal, but it's the least worst solution we can find.
in reply to Element

@element @schmittlauch You may have wrote 90% of Synapse, but it really must hurt to have made open contributions that you couldn't directly profit off of... The language from the Foundation isn't ambiguous, you used your position as leverage to take these projects out from under their steward, ENTIRELY to make money off of them. I don't care how you justify it, it's unacceptable.
in reply to Campbell Jones

@serebit @element To be fair, the maintenance burden of having to refactor downstream changes – even when based on a proprietary relicensed codebase – can be a good motivation to upstream your changes as FLOSS already.

Companies use AGPL differently in that regard. Oracle is more on the "better by a proprietary license, or else…" side, others do encourage the FLOSS route more.

->

in reply to Trolli Schmittlauch 🦥

@schmittlauch @serebit we could have sprouted a proprietary fork of Synapse at any point and stopped developing it as FOSS (due to the Apache license). But we have zero desire to do so. If there's a hack we can use to force us to keep the project FOSS as AGPLv3 then we'll use it. However, we're still going to dual-license in order to try to keep the lights on.
in reply to Element

@element @schmittlauch Sure, until you start making a profit. Then "so we can keep the lights on" turns into "so we can shore up our reserves", then "so we can fund an IPO", then "so we can keep our promises to our shareholders". Have you really not noticed the patterns in the industry? Are you that certain that you're immune to them?
in reply to Element

@element @maxgot @schmittlauch Poison-pill the CLAs, which has worked for keeping Qt open-source. For a given project, if you attempt to take the upstream repository closed source, it immediately transfers ownership back to the Matrix Foundation and you void all prior license agreements. Get a lawyer to make that clause ironclad, codify it in the CLA, and I'd be satisfied.
in reply to Element

@element Thank you. While I am still wary about the incentives this brings for encouraging FLOSS back-contributions vs. selling proprietary licenses (see the OwnCloud-NextCloud story), I guess the biggest concern of most CLA critics is the ability of element pulling a HashiCorp and going proprietary again.
You now mention this concern as well in the blog post; have any countermeasures for the CLA been discussed? Like e.g. github.com/slint-ui/slint/disc…
Unknown parent

mastodon - Link to source

Element

@bbhtt The reason for the shift is so that Element can dual-license the project to commercial forks who currently don't contribute back. This is also the reason for the CLA, to give Element the right to dual-license. The Foundation could have done the same thing, but is not remotely set up for selling licenses, and it'd put the Foundation in competition with Element, which would be nightmarish. Hopefully this is the least worst outcome.
in reply to Campbell Jones

@serebit Indeed, the Foundation's stance is that we'd prefer the projects remain actively maintained under our auspices and unencumbered by a CLA.

We're glad they chose an open source license, and we also think this is a moment for the rest of the ecosystem to shine.

Ultimately, this is a point in favor of protocols, as the spec is the beating heart of Matrix and remains open source *and* under open governance that will only get more open as we seat the first elected Governing Board next year.

in reply to Mendy

@Mendy While the Foundation could reasonably consider using AGPLv3 as its default license going forward, generally or for a specific project, the only proper way for the Foundation to do so would be to do it holistically and in service of the entire ecosystem – conversely, it'd be improper for us to make such a change at the behest of a single service provider.