4 ms·

Element requiring a CLA has only 1 practical effect: Element are effectively saying that in their repo of Synapse/Dendrite, they won't integrate any copyleft co

Element requiring a CLA has only 1 practical effect: Element are effectively saying that in their repo of Synapse/Dendrite, they won't integrate any copyleft code they can't relicense. Other organisations could still choose to maintain a repo of Synapse/Dendrite that integrates any AGPL code, including all code released by Element. That might be a better upstream than Element! — but it would take work. For it to happen, someone would need to do and/or fund that work.

alohapersona3 3y ago
If next there is "Synapse Pro" that is proprietary and sold by Element and includes features not present in the open source version of Synapse but relevant to company or government use of Matrix, the AGPL-only version of Synapse will lack those features. This will hinder companies that (potentially) require "Synapse Pro"-features from contributing to the AGPL-only version of Synapse. We have seen this happen before.
- feanaro 3y ago
  This situation is no different than it was when Synapse was licensed under Apache, though.
  - danShumway 3y ago
    Agreed (mostly). Apache is not a defense against proprietary relicensing regardless of who owns the code (and it's why Matrix is able to make this change even though it didn't have a CLA before). It's a shame though because this change feels like it's weaponizing the AGPL to make the code harder to use rather than relying on the AGPL to preserve software freedom, and it's a shame because I think a more nuanced and limited contributor agreement with narrower permissions could potentially have the opposite effect and be a highly positive change and a highly credible commitment to keeping the project Open, without closing off any of the revenue opportunities that Element seems to be chasing. I will push back a little though on the idea that nothing is different at all. This change also has the side-effect of giving contributors fewer rights over the code they write themselves. It's not clear to me whether the copyright assignment here means that the contributor is also bound by the AGPL for the code they themselves submit. If that's the case, then this is a meaningful reduction of contributor rights. I think the GPL works best when it is a universal mutual agreement by all parties to keep the code Open to everyone under the same terms; not when it is used selectively to close off specific rights of only specific parties. But as it stands, without a CLA I could write the same code for both Element and a more permissive fork of Element and I could choose to relicense the code I offer Element to allow for the more permissive use. With a CLA, I don't know that I can do that.
  - alohapersona3 3y ago
    Not entirely. Under the Apache license, everyone can contribute to the Apache-licensed code and mix that code with proprietary code as they wish. Under AGPL-only that's not possible, only code that was contributed under Element's CLA can be relicensed by them and then mixed with the proprietary code. That makes contributing code under AGPL-only less attractive if you need to use the proprietary code.
    - feanaro 3y ago
      Well definitely, but as a net benefit, we'll have less proprietary Matrix code than before. Or the people needing to use Synapse in a proprietary setting can contact Element for a proprietary licence, in which case Element will be able to pay its salaries and keep developing Matrix. It really seems like a net win, except for the people that were planning to build proprietary services on top of Synapse without contributing back.
danShumway 3y ago
> they won't integrate any copyleft code they can't relicense. Right, that's exactly the controversy, people are scared of the code being relicensed. Rather than a CLA, a limited license grant from contributors to allow dual licensing but not the transition away from AGPL might potentially be a way to provide that kind of funding and to close off companies building proprietary products on top of Element without contributing back, while simultaneously decreasing the danger of the code being relicensed entirely; which the company is claiming they have no plans to do anyway. The inclusion of copyleft code into Element that isn't owned by the company is the safety measure, accepting contributor-owned GPL code is a way for companies to credibly signal that they will not move to a source available model in the future. Sure, a separate upstream could be maintained, but unless Element is planning to pull from that upstream repo then a separate upstream is indistinguishable from a hostile fork and an abandonment of Element as the primary contributor. It's not about the repository, it's about whether the flagship implementation of the Matrix server code has the possibility of being turned into a proprietary product. If we're going to go with a different upstream, what we're saying is that Element is not going to be providing the flagship implementations -- and I don't think people are eager to make that kind of decision.
- grey_earthling 3y ago
  Yeah, that seems fair. Though I suppose a limited licence grant is slightly more complex of an arrangement. If it's any consolation, compared to a month ago when everything was permissively-licensed, Element is no more or less able to make a proprietary fork, and everyone else is now less able.

alohapersona3 3y ago

If next there is "Synapse Pro" that is proprietary and sold by Element and includes features not present in the open source version of Synapse but relevant to company or government use of Matrix, the AGPL-only version of Synapse will lack those features. This will hinder companies that (potentially) require "Synapse Pro"-features from contributing to the AGPL-only version of Synapse. We have seen this happen before.

feanaro 3y ago
This situation is no different than it was when Synapse was licensed under Apache, though.
- danShumway 3y ago
  Agreed (mostly). Apache is not a defense against proprietary relicensing regardless of who owns the code (and it's why Matrix is able to make this change even though it didn't have a CLA before). It's a shame though because this change feels like it's weaponizing the AGPL to make the code harder to use rather than relying on the AGPL to preserve software freedom, and it's a shame because I think a more nuanced and limited contributor agreement with narrower permissions could potentially have the opposite effect and be a highly positive change and a highly credible commitment to keeping the project Open, without closing off any of the revenue opportunities that Element seems to be chasing. I will push back a little though on the idea that nothing is different at all. This change also has the side-effect of giving contributors fewer rights over the code they write themselves. It's not clear to me whether the copyright assignment here means that the contributor is also bound by the AGPL for the code they themselves submit. If that's the case, then this is a meaningful reduction of contributor rights. I think the GPL works best when it is a universal mutual agreement by all parties to keep the code Open to everyone under the same terms; not when it is used selectively to close off specific rights of only specific parties. But as it stands, without a CLA I could write the same code for both Element and a more permissive fork of Element and I could choose to relicense the code I offer Element to allow for the more permissive use. With a CLA, I don't know that I can do that.
- alohapersona3 3y ago
  Not entirely. Under the Apache license, everyone can contribute to the Apache-licensed code and mix that code with proprietary code as they wish. Under AGPL-only that's not possible, only code that was contributed under Element's CLA can be relicensed by them and then mixed with the proprietary code. That makes contributing code under AGPL-only less attractive if you need to use the proprietary code.
  - feanaro 3y ago
    Well definitely, but as a net benefit, we'll have less proprietary Matrix code than before. Or the people needing to use Synapse in a proprietary setting can contact Element for a proprietary licence, in which case Element will be able to pay its salaries and keep developing Matrix. It really seems like a net win, except for the people that were planning to build proprietary services on top of Synapse without contributing back.

danShumway 3y ago

> they won't integrate any copyleft code they can't relicense. Right, that's exactly the controversy, people are scared of the code being relicensed. Rather than a CLA, a limited license grant from contributors to allow dual licensing but not the transition away from AGPL might potentially be a way to provide that kind of funding and to close off companies building proprietary products on top of Element without contributing back, while simultaneously decreasing the danger of the code being relicensed entirely; which the company is claiming they have no plans to do anyway. The inclusion of copyleft code into Element that isn't owned by the company is the safety measure, accepting contributor-owned GPL code is a way for companies to credibly signal that they will not move to a source available model in the future. Sure, a separate upstream could be maintained, but unless Element is planning to pull from that upstream repo then a separate upstream is indistinguishable from a hostile fork and an abandonment of Element as the primary contributor. It's not about the repository, it's about whether the flagship implementation of the Matrix server code has the possibility of being turned into a proprietary product. If we're going to go with a different upstream, what we're saying is that Element is not going to be providing the flagship implementations -- and I don't think people are eager to make that kind of decision.

grey_earthling 3y ago
Yeah, that seems fair. Though I suppose a limited licence grant is slightly more complex of an arrangement. If it's any consolation, compared to a month ago when everything was permissively-licensed, Element is no more or less able to make a proprietary fork, and everyone else is now less able.