Live data from Hacker News

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

element.io

71–80 of 304 posts

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

#71
post #57

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!

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.

Agreed, I am not a fan of AGPL, but I could understand and accept it. Not with the CLA. The CLA means you'll have to pay for whatever you want privately developed.

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

#72
post #57

Earlier quoted context omitted.

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.

I don't think SSPL is worse than AGPL in practice, in fact it is better. The SSPL is effectively a stronger AGPL. This makes it non-OSI-approved, but the licence itself is completely fine. The major difference is that the SSPL also mandates that you release everything needed to run the software, not just the software itself. For reference, it's worth to read the OSI's blogpost about this, it's quite illuminating : ht…

>The major difference is that the SSPL also mandates that you release everything needed to run the software

Which makes it incompatible with little things like the linux kernel, since you don't have the licence to release it as SSPL

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

#73

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 l…

I've never heard of this license before. Thanks for pointing it out.

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

#74
post #67

Earlier quoted context omitted.

If it's any consolation, the fundamental asymmetry replaces a previous asymmetry that Element uniquely donated all of its core Matrix code, including ownership, to the Foundation. But yes, I wish that the economics balanced without a CLA. But they don't.

I have high hopes for the future of Matrix in large part because of the Matrix Foundation. But what happens at Element when you and Amandine leave? What stops Element from being bought by a huge corporation that takes the whole thing proprietary and kills it? I'm sympathetic to the position that you find yourself in here (I have a standing recurring donation to the Matrix Foundation). But this seems substantially les…

I think there are a few helpful things in that regard:

- There are already viable and deployed alternatives to Synapse, including Conduit. Making changes that would break compatibility would fragment the network.

- There are already viable and widely-used alternatives to Element on the client side. I myself mostly use Nheko these days.

- The structure of the Matrix protocol is such that breaks in compatibility would look very weird to users, so I think they're incentivized to avoid making such changes for their user experience's sake.

- The primary selling point of Matrix (and thus Element) over other systems is precisely that it's an open protocol for communications. It seems unlikely (though not impossible) that they would do anything to harm that, but if they did, it would not look good for the company. Speaking personally, I would start looking for alternatives if they did.

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

#75

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 l…

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?

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

#76
post #57

Earlier quoted context omitted.

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.

I don't think SSPL is worse than AGPL in practice, in fact it is better. The SSPL is effectively a stronger AGPL. This makes it non-OSI-approved, but the licence itself is completely fine. The major difference is that the SSPL also mandates that you release everything needed to run the software, not just the software itself. For reference, it's worth to read the OSI's blogpost about this, it's quite illuminating : ht…

The additional restrictions in the SSPL apply also to unmodified versions. This is very different from the AGPL, which does not impose any additional over the burdens over the GPL if you use an unmodified version of the software, even if you use that to offer network services. This provides a very clear path to AGPL compliance for most users, certainly those who get their software from a GNU/Linux distribution. (I missed that aspect of the AGPL for quite some time, admittedly.)

The SSPL, in contrast, applies to unmodified versions of the software. This means that even if you get SSPL software from someone who publishes the sources, you have to take additional steps for license compliance if you want to use the software. Given that the SSPL requires publishing things like the source code for NIC and network switch firmware (both are obviously required for offering your network service …), I just don't see how this license is useful besides being deceptive. The BSL with its typical field-of-use restrictions achieve the same thing in a much more direct manner.

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

#77

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]: >…

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 referenc…

[deleted]

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

#78
post #40

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.

I don't have a broad opinion on CLAs, but the Element announcement [0] says it's just the Apache Software Foundation's CLA, which I think most people are fine with [1]. It's more or less just a copyright/patent grant. [0]: https://element.io/blog/element-to-adopt-agplv3/ [1]: https://www.apache.org/licenses/contributor-agreements.html#...

They're ok with it when it goes to the ASF; which is not what's going on here.

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

#79
post #7

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

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.

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.
Post reply on HN