~sircmpwn/public-inbox

3 3

Element change of license and CLA

Details
Message ID
<8734xb3xb7.fsf@city17.xyz>
DKIM signature
missing
Download raw message
Hey,

I am reading about the fork of the Matrix servers (Synapse and Dendrite)
operated by Element:
https://matrix.org/blog/2023/11/10/this-week-in-matrix-2023-11-10/#synapse-website

The current projects are owned by the Matrix Foundation and licensed as
Apache-2.0.

The new fork by Element will use the AGPLv3 license and will require
contributors to sign the Apache CLA:
https://www.apache.org/licenses/contributor-agreements.html#clas

This CLA waives all contributor copyrights and patents to Element.

I am not clear about the actual differences between these two licensing
setups:
- Matrix Foundation: holds the old codebase Apache-2.0
- Element: forks and licenses as AGPLv3 + a CLA that assigns them contributor copyrights and patents

One can argument that Element is requiring the CLA to possibly close the
source code in the future and make a proprietary product. But wasn't
that already possible using the Apache-2.0 license?

What is the actual difference with a CLA? Making it easier for Element
to make a closed-source fork of a AGPLv3 project without having to ask
all contributors? If yes, why didn't they simply used a more permissive
license like the Apache-2.0 that already allows that?

What am I missing in the reasoning?
Details
Message ID
<r1UogkLFdoWlTtXAlKI4LoUULBuXHNAa4UtSnVMVLISkEx9FRHX1D_7NS8O1m2QDWoraAjdX7iqvitMbFs4NOTHuoy9X_s3BoxLTJi_byIo=@emersion.fr>
In-Reply-To
<8734xb3xb7.fsf@city17.xyz> (view parent)
DKIM signature
missing
Download raw message
I've been told that Element wants to publish closed-source addons for
Element, while forbidding their competitors from doing the same. This
AGPL + copyright assignment allows Element to achieve this goal: since
they own the copyright, they can redistribute closed-source versions of
Element under non-GPL terms.
Details
Message ID
<27qjmr3tcnezj34mlfycwiz5uix2jznm4qmmotyqrrgdttb6wu@rhlrzgft4gfe>
In-Reply-To
<8734xb3xb7.fsf@city17.xyz> (view parent)
DKIM signature
missing
Download raw message
On 2023-11-12 14:21, jman wrote:
> One can argument that Element is requiring the CLA to possibly close the
> source code in the future and make a proprietary product. But wasn't
> that already possible using the Apache-2.0 license?
> 

With the new licence, they are the only ones who can make a proprietary fork;
everyone else must share their changes under the AGPL.

> What is the actual difference with a CLA? Making it easier for Element
> to make a closed-source fork of a AGPLv3 project without having to ask
> all contributors? If yes, why didn't they simply used a more permissive
> license like the Apache-2.0 that already allows that?
> 
> What am I missing in the reasoning?

The new situation forces all others to share their their source code under
AGPL, but allows them to sell closed-source proprietary forks. In other words,
it's a "everyone else must share code under AGPL except us" situation.

By the way, their official announcement indicates that this is exactly what
they intend to do. I quote:

> Future code contributors to Synapse will need to sign a contributor license
> agreement (CLA) based on the Apache Software Foundation’s CLA, giving Element
> the right to license the contribution commercially to third party proprietary
> forks

Source: https://element.io/blog/element-to-adopt-agplv3/

-- 
Hugo
Details
Message ID
<875y26xcgk.fsf@city17.xyz>
In-Reply-To
<27qjmr3tcnezj34mlfycwiz5uix2jznm4qmmotyqrrgdttb6wu@rhlrzgft4gfe> (view parent)
DKIM signature
missing
Download raw message
Thanks for sharing your thoughts.

> The new situation forces all others to share their their source code under
> AGPL, but allows them to sell closed-source proprietary forks. In other words,
> it's a "everyone else must share code under AGPL except us" situation.

In that blog post they also mention they if they wanted, they could have
made a closed-source fork at anytime:

>  (EDIT: to be clear, the sole reason for a CLA is to allow Element to
>  dual-license the software (...) not to give Element the ability to
>  relicense to a non-OSI license in future. After all, Element already
>  had that ability with the Apache license, and has not used it.)

So, this seems to validate that:
- they claim they do not want to make the project closed-source in the future
- they want to keep the option to /also/ relicense as non FOSS

In addition, I watched their latest videoblog [0] and the Foundation was clear
that the situation is evolving. This CLA is not yet completely defined
so it's too early to speculate.

[0]: https://iv.ggtyler.dev/watch?v=9ZUC5pdwbio
Reply to thread Export thread (mbox)