@skyfaller @matrix keep in mind that CLAs vary from project to project. Some CLAs (like Fedora's) explicitly tell you that you own your copyright.

But yes, I certainly agree that they shouldn't be using a CLA.

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

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

@catraxx@tech.lgbt @matrix@mastodon.matrix.org

> while encouraging proprietary forks to contribute to the development costs of the underlying project

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

@lambda This is definitely a good time for the rest of the ecosystem to shine!

@lambda @matrix

I think it's what Matrix Foundation would want: pick up all that Shnapse baggage and yeet it out! ...Because we're already getting Rust and other server implementations.

@bbhtt That's a question best directed at Element. The Foundation's position is that we'd prefer for the projects to remain under our auspices and unencumbered by a CLA.

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

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

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

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

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

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

@mirdaki That is a good question that we don't have the answer to!

If Element abuses this privilege, others in the community can fork, and then no-one gets special commercial privileges. In the wildest dreams future when Matrix is a dominant protocol, future clients and servers will emerge anyway, and they could have vastly different approaches to licensing and monetization.

It's more important that in the long run open protocols like Matrix flourish, which strongly benefits from at least one well funded development company.

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

@yuvipanda @matrix frankly, it's an effort to keep the show on the road. it's not remotely intended to be a breach of trust, any more than (say) Apache forking the CERN httpd was.

@allpurposemat We don't have existing resources we can offer on migration, but we do think this is a moment for the rest of the ecosystem to shine!

@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 https://www.apache.org/licenses/contributor-agreements.html

@matrix If this is a breakup with Element, PLEASE go around and ask non-Element-affiliated contributors of the ecosystem as to what's going wrong when you have the time and the capacity.

Sending warm regards and wishing you the best ❤

@matrix Why is it tough? The license changed for the better. I haven't heard anything else besides that, did something else happen?

@hamburghammer The Foundation's stance is that we'd prefer these projects to remain under our auspices and unencumbered by a CLA.

Only Element can answer why they've decided to implement a CLA with their forks.

@hamburghammer @matrix 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 https://www.fsf.org/blogs/rms/selling-exceptions); this is the whole reason for the license shift.

@schmittlauch

Technically correct, but in practice it means you either make your modifications available to your users or you contribute financially. (basically supporting the development)

@schmittlauch @matrix Have edited the blog post to try to clarify: "giving Element the right to license the contribution commercially to third party proprietary forks so we can use it to help fund Matrix core development in future".

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