Posts and replies

Essentially, you should consider any AGPL+CLA project as "source available", not as a true open source project where everyone's contributions are equal.

Of course, at least it's possible to fork since the base license is AGPL.

@atax1a @lina @kouhai yeah, they admit to doing so in a blog post[0], ugh ​​

[0] blog.fluxer.app/how-i-built-fluxer-a-discord-like-chat-app

@thufie Sigh...

@larsmb @lina all cases of agpl+cla I have seen so far (cough matrix element cough) have been purely to a) claim "but its open source!" (usually followed by "our product theme doesn't think this feature is needed despite 600+ upvotes) and b) to force companies into buying the (usually very overpriced) enterprise license (usually comes without extra support contracts) because companies usually misread agpl (I stopped counting how often a customer of my dayjob tried to claim that agpl means they have to open source their proprietary unrelated tool 3 data enters away from our code... Agpl is not that hard to understand...)

So in my book this feels deliberate to have a power gradient. They get free contributions that cost less, they get publicity, they get free qa and they make a lot of money. :/

Matrix in comparison luckily seems to have reached in the foss world at least a place where it isn't anymore overly relying on element for foss code. (Continuwuity and cinny for example exist as polished alternatives to synapse and element-web which both are open code agpl+cla). Sadly this doesn't seem to fully apply yet to the enterprise half of the matrix ecosystem :/ (can't complain about details since I work for a matrix company which IMHO is part of the bigger issue...)

@mtrnord @lina Again, that's due to the CLA, not the AGPL.

garage is AGPL, and that's perfectly harmless.

AGPL plus distributed copyright keeps predators & non-reciprocal actors at a distance, more than a weaker license like Apache would.

@larsmb @lina oops I should have been clearer that I am agreeing with you

I was more focusing on the second half of your post/toot. Wanted to give an example of why people (from my POV) seem to choose agpl specifically together with cla instead of let's say Apache or others together with the cla.

The "scary" impression companies have of agpl seems to help driving potential customers towards an enterprise license rather than using the foss code. As a result you get an (probably intentional) power gradient in a project.

@alwayscurious @larsmb @lina implementing e2ee is a solved issue. All featured clients at https://matrix.org/ecosystem/clients/ support it as does the majority of that list. (In fact I am not aware of any client on that list which does not support e2ee.)

VoIP on the other hand is not as well supported. Quite a few support legacy VoIP (as in true direct webrtc with negotiation over matrix) but only very very few do support the new MatrixRTC which can utilize an SFU like livekit which increases usability for the enduser.
In terms of server support for MatrixRTC I believe only synapse and continuwuity support it fully currently.

Either way I suggest clicking through the list at https://matrix.org/ecosystem/clients/ which has an overview of features supported by a client.

@keyshooter That depends, but the bigger issue here is the CLA...

@maddyunderstars I personally don't think the AGPL is a good license (it's very widely misunderstood and doesn't work how most people think), but that ship has kinda sailed with how popular it's become lately so... pick your poison I guess.

@valpackett The point of licenses like the GPL is that *everyone* has the same rights. "Owners" are not special, so they can't rugpull or take advantage of contributors. This is what enables equal forks.

If you fork an AGPL+CLA project, you can't have a CLA any more because the fork does not inherit the special privileges of the original owner. The CLA permanently enshrines the "original" author as superior to everyone else as long as that repo exists.

As a contributor, my expectation is that if I spend my time to contribute to your project for free, that my contribution will not be later be part of a rugpull where the repo owner flips to a commercial enterprise and stops doing FOSS. If there's a CLA that allows them to do that, I won't contribute in the first place.

If they *want* to be able to do that, then the whole repo should be MIT so *everyone else* gets to do that too. It's only fair.

FOSS projects are all about a group of people contributing under an equal license with equal rights. The original author already has leverage in the form of controlling the original community and repo (making a fork succeed isn't easy), they don't need legal leverage on top of that.

@valpackett Can you imagine if Linux had a setup like this, and Linus started licensing it out to Android device makers under a commercial license (or just to Google, who then sublicenses it out)? Android custom ROMs basically wouldn't exist, and it would be incredibly unfair to Linux contributors who contributed expecting it to remain GPL.

@maco @lina AGPL is considered toxic by many companies, e.g. Google's policy: https://opensource.google/documentation/reference/using/agpl-policy

So AGPL+CLA is "we can do whatever we want with this commercially, other companies will go away". Maximum asymmetry between the project owner and other contributors.

(As another example: I've considered releasing software under AGPL+anticapitalist license, in order to satisfy Codeberg's license requirement.)

@snowfox @maco @lina Google saying "we could be forced to release source code for Gmail" doesn't exactly show any toxicity - in fact, that seems like a good thing.

It seems that the key here is combining it with a CLA that allows the maintainer/repo owner (and them only) to relicense the code under any terms they wish, thus creating the asymmetry - they can take anything and make it proprietary, others have to publish their modifications and linked code.

@snowfox @maco @lina and this is probably how fluxer is making it legal for the LLC to paywall "early access" and "exclusive features" - which they're doing already(!), via subscriptions and a special early backer purchase/tier, even as their public repo has only 94 commits and only exists since January.

Fluxer overall seems like a textbook example of a startup that pops up to scoop up people fleeing a hostile corporation, only to be sold to a hostile corporation once it has a user base.

@outfrost @snowfox @maco @lina if i may, i think the point here is that if you drop the CLA then the project can't be so easily and arbitrarily rug-pulled from users at a future point, the CLA enables it to 'seem free', harvest primarily unpaid contribution (paid contribution is scared away by AGPL), but maximizes the copyright owners ability to run off with the result and execute some form of extend and extinguish of any fork

@raggi @snowfox @maco @lina Thank you, yeah, rugpull summarises this pretty well.

* they can do what they're doing now, which is keeping some source closed and proprietary to paywall features that only they can host;
* they can also do that to host feature implementations (paid or free) which are incompatible with self-hosted instances and forks in a hostile way;
* they can just stop updating the public repo at any point, or update it selectively, effectively sunsetting the open source part

@disorderlyf @maco @lina CLAs can be a mess, but AGPL+CLA has an overall similar effect to a hypothetical "non-commercial+CLA": Most companies stay away, hobbyists contribute, and the owner can relicense contributions commercially. I interpret AGPL+CLA as "we want to be the only people who can exploit this software commercially".

If you want a license that's toxic to big companies, there are perhaps better ones than AGPL (such as the anticapitalist license, depending on who/what you want to allow ). The main benefit of AGPL, IMO, is it checks the "OSI-approved license" checkbox, and I only considered it because I don't plan on allowing contributions (so I'm free to relicense if I need to in the future).

@techokami @lina to be fair, a CLA for this could be done in a way that allows that without being a blanket "we can change the license whenever"

like you could just have the CLA allow the org to sell exemptions for part of the license with limits on redistribution rather than just giving the blanket right to change the license any time

@clarfonthey @techokami Exactly, this is the issue. The existing CLA is way too broad.

@lina @clarfonthey Yeah, looking this over... it IS too broad. That's... not good. And I had some actual hopes for this one, too :(

@keyshooter @lina not that I can recall... I do know they go after people that use the GPL licensed version in non-FOSS projects, and use the revenue from the commercial licensed version to fund development of the GPL version

@didek Fair. The point I'm trying to make is, it's not an open contribution FOSS project. It's more like source drops with an option to donate your time to them for nothing in return.

@dsseng It's different because *anyone* can do that with an Apache licensed project, while only *the maintainers* can do that here. It creates an imbalance that puts the maintainers above contributors in terms of licensing.

FOSS licensing is supposed to be fair, everyone bound by the same terms. CLAs subvert that.

Essentially, the point of the AGPL is "nobody can enshittify this into a paid service". AGPL+CLA is "only we're allowed to enshittify this into a paid service". And they usually end up doing just that.

@lina ah, well, I thought mostly from the perspective of a user who uses it on the FOSS license basis. I got it, well, and the key point is perhaps the last one since such policy is quite indicative