Hacker News Reader

Comment by phoronixrly | Hacker News Reader

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.

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.

`Apache-2.0` allows Element the same power right now. No organization is maintaining meaningful community forks of Synapse and/or Dendrite with their own proprietary modifications on top. Element hasn't used their power to take the vast majority of their modifications private so far.

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.

Apache-2.0 gives everyone those rights. The CLA makes Element the only one who can build proprietary modifications on top. Monopolization of the position they gained by advertising as open-source.

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: https://blog.opensource.org/the-sspl-is-not-an-open-source-l...

It's also worth mentioning that most of the attacks against the GPL, AGPL and SSPL are done by corporate shills, and OSI is also full of them. They pretend to support "non-discrimination of fields of endeavour" but they are undermining free software to SaaS-ify it. Don't fall for the "SSPL is not open source" propaganda.

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.

>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

> most of the attacks against the GPL, AGPL and SSPL are done by corporate shills, and OSI is also full of them

To underscore something important in this discussion: there is no "The GPL is Not an Open Source License" post on the OSI blog, nor will there ever be one. GPL and AGPL have OSI approval.

And?

If they are doing most of the development they need a way to finance that.

Selling GPL exceptions is a Stallman approved tactic.

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 world, although it unfortunately is not.)

* i.e. so you can make proprietary software

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.

How happy would you be when they later move your contribution to a paid tier only?

Almost as unhappy as if the upstream project failed and went away completely.

And in reality it depends a lot on my level of contribution. If I have dozens of lines of code in a big project, then who cares, all I really wanted was for my pet bugs to get fixed.

If I contributed major features or thousands of lines of code there, then I would be very mad. But I would also be very capable of maintaining an open source fork of the project.

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.

No, the CLA means that if you want something privately developed, you have the option to do so by buying a license that allows that. Without the CLA, nobody would be able to do that, at least if there are any community contributions.

Realistically they probably do like 95% of the real work themselves so it makes sense.

Realistically, if they started as proprietary in the first place, they wouldn't ever grow to this size (just another closed chat app competing with Discord and Messenger), so they still benefited from being open-source. Now they are reaping the benefit and monopolizing it.

I understand your point, but there're the independent home server implementations Conduit (Rust) and Construct (C++) so it's not exactly monopolizing. The Matrix spec will continue to be Apache 2.0 licensed.

It’s still open source now. You can pull the repo and do whatever with it.

They just won’t merge your changes without a CLA. You are free to fork and contribute there if you want.

As an additional plus, I think many SaaS companies (e.g. Google) ban the use of AGPL software on their company computers. The more advantages we can give to non-big tech developers, the better.

Reply on news.ycombinator.com