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.
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.
A new home and license (AGPL) for Synapse and friends
251–260 of 304 posts
Re: A new home and license (AGPL) for Synapse and friends
#252> 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 unfitti…
> 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…
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".)
Re: A new home and license (AGPL) for Synapse and friends
#253Earlier quoted context omitted.
He approves of developers selling GPL exceptions. He doesn't approve of buying GPL exceptions*. It's a subtle point. (The natural corollary to this is that if the Element/Matrix folks—or anyone—were to ask you for a CLA excepting them from the project's own open source license, then you could/should feel comfortable kindly requiring them to pay you for it—a response which should be the default in the open source worl…
Personally I’m happy to ask them to kindly maintain my new feature along with all of their other code, so I can continue to use an up-to-date version with very little effort.
Re: A new home and license (AGPL) for Synapse and friends
#254Earlier 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.
Realistically they probably do like 95% of the real work themselves so it makes sense.
Re: A new home and license (AGPL) for Synapse and friends
#255Well, 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.
>Going off their behavior on certain github issues, I won't hold my breath and will continue to use briar instead. link?
Re: A new home and license (AGPL) for Synapse and friends
#256Earlier quoted context omitted.
Something I don't understand is: how is other companies making money an existential threat for Element? It seems rather that Element's hopes of making enough money (to fund development) by selling hosted/managed services was misplaced.
In a market, you're always competing on cost/return. Competitors can just take the open source parts of the matrix projects without contributing code or funding back. As result, in a bid between Element and competitors, Element will lose because Element actually pays for maintaining these open source projects.
So I don’t see how someone acting in a different market had any bearing on their business at all. Unless they were indeed in that market, but that doesn’t seem clear to me at all from their messaging.
Re: A new home and license (AGPL) for Synapse and friends
#257Earlier quoted context omitted.
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…
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/ ), though they seem to have added CLA to it. If so, the protocol doesn't have the problem you pointed out. You coul…
Re: A new home and license (AGPL) for Synapse and friends
#258Earlier quoted context omitted.
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.
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.
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.
Re: A new home and license (AGPL) for Synapse and friends
#259So 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 s…
I generally agree, however a cla in this case might make sense:
1. Allow for dual licensing, helping make the project sustainable
2. Help with copyright assignment, keeping stuff free: it makes possible to switch to agpl v4 if it’ll ever come out.
Point 2 is particularly important and is why linux will be forever stuck on gplv2
Re: A new home and license (AGPL) for Synapse and friends
#260Dropping Synapse because I can't remix it for commercial uses.