> 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 ship under some alternative license, for a fee. They’re making others sign an agreement to ensure that they have privilege to ship the project (or forks of it) under a proprietary license.
I wouldn’t consider any of this open source any more. These are step that a organisation takes when they want to move to an open core model and screw over the community. What they are doing is a required step to pull the same stunt as terraform.
It’s technically still open source today, but this consolidates them into a position to change this at will. Don’t be fooled by the tricky wording that makes this sound like a good thing. These folks are very unambiguously screwing over the community and making it sound otherwise.
Much of your comment is speculation and unfounded accusations.
> This makes it clear that they intent to ship under some alternative license, for a fee.
It makes it clear they intend to ship under the AGPLv3. What's wrong with that? They can change the license at a later date? Just fork!
> I wouldn’t consider any of this open source any more.
This is bananas; the AGPLv3 is extremely open source. And again, nothing prevents contributors from forking the code if Element closes it.
> What they are doing is a required step to pull the same stunt as terraform.
Didn't this result in the creation of OpenTofu? I haven't kept up and don't really have an opinion, but a cursory examination shows that their GitHub project has a gazillion stars [0].
> These folks are very unambiguously screwing over the community and making it sound otherwise.
They've contributed an enormous amount of work to try and move the state of the art in messaging forward in a way that respects users (being extremely open, implementing end-to-end encryption, embracing decentralization, etc). Your characterizations of them are super uncharitable. They owe you precisely nothing.
You're missing the point. I'm saying people are getting super exercised about the "we might sell alternative licenses", but the code's AGPLv3, which everyone should be fine with.
This is true. And nobody owes them anything either, something the GP was trying to make clear to the reader (with a reminder that if they do this thing how that will be used). I think this is a reasonable stance to take when any party pulls out the lawyers. Such a move must be mistrusted, lawyers are a mistrustful tool.
> And nobody owes them anything either, something the GP was trying to make clear to the reader (with a reminder that if they do this thing how that will be used).
Element's not demanding anything from anyone. I don't understand your point.
This thread is full of people being super negative about the Element team. It's definitely not "slight" criticism.
> a lot of people come out of woodwork with the tried and true "they owe you nothing" line.
Criticism is how we improve and I'm a fan, but there's a difference between constructive criticism (which would be something like, "it looks like you're trying to build a sustainable revenue stream to continue your work on Matrix/Element but I'm not sure this is the best way to go about it, here's an alternative") and entitlement.
Entitlement is demanding that Element essentially not run a business to fund Matrix/Element development. You might not think you're doing that, but what else could you be doing?
- You can't think Element is getting special treatment; anyone could do what they're doing here.
- You can't think this change could open the door to some entity buying a proprietary license and "causing problems" because that applies to the Apache version as well (you can close source an Apache 2.0 project).
- You can't think Element would lock away community contributions; the community is free to fork Element's version if they do ever close the source.
- You can't think they're tricking people into contributing to their versions and profiting unethically from them; they're being super upfront about this (they make you sign the CLA that makes this clear!) and anyone is free to continue contributing to the Apache-licensed versions. And again if you don't like either of those options, make your own fork! Or write your own server, the Matrix/Element people have erected a super open development and standards process (you're welcome!)
Thus your only objection must be that Element is forcing people to pay if they want to run a closed-source version of their code. Another way to say that is you feel entitled to run a closed-source version of their code for free. You might say, "but Element's CLA gives them the ability to run a closed-source version of my code for free" which is true. The difference is they're giving you a choice, whereas you're demanding it from them.
> A community is allowed to have certain expectations, champ.
> I wouldn’t consider any of this open source any more.
If this was BSL I agree with you, but that is not the case.
AGPL is about as open source as it gets. It is forced open source.
I recommend AGPL to any of my clients open sourcing anything in a competitive environment these days. Free for the public, but greedy corpos that do not want to share changes and be part of the community are forced to pay to support the developers that are.
This AGPL working as designed, and is certainly FLOSS.
The AGPL is not the issue. The CLA is. It allows the project to change licenses at will, without going back to all contributors and asking for approval.
> Ah yes, CLAs are not a real open source, which is why they're required by uhh FSF.
The last time I saw a FSF CLA, it was part of a larger agreement that also imposed obligations on the FSF.
In the long run, there may be risks to the FSF holding so many copyrights. But I don't think it clarifies matters to treat the FSF's CLAs the same as ones used by a "open core" VC funded startup.
Do you truly see no difference between assigning rights to your own code to a non-profit foundation dedicated to Free Software and assigning rights to your own code to a for-profit company?
Especially when the for-profit company openly announces this assignment of rights is for the purpose of selling code you wrote to others without giving back to the authors.
The FSF doesn't have a track record of asking for CLAs, and then selling your code to others under different licenses and pocketing the profits.
If the Free Software Foundation which was started and is headed by Stallman himself betrays the free software movement, then nothing in this world can be trusted anymore.
They would still have to go back to past contributors prior to introducing CLA.
Source: My PR was merged in 2021, the changes are still part of Synapse, and I never signed any CLA. I don't think they'd be able to get enough sign-offs from historical contributors to pull off any actual shenanigans with the Synapse license.
There are many of us who regard the AGPL as a nonfree license. It’s just the FSF zealots who regard the ability to run a services business with free software as a “loophole”.
Hard disagree. I'm looking at a similar license setup for my upcoming project, and I'm going with AGPL because I want to ensure any _users_ of the software have access to the source code.
Nothing is stopping anyone from setting up a competing service and charging for it. The only thing they can't do is provide their _modified_ version as a service without providing the source code. Which is just the GPL's usual distribution clause updated for how modern software is distributed. Bear in mind that said source code could literally be a zip file that is emailed when someone requests; there's no requirement to post it publicly on an ongoing basis.
I don't consider myself a FSF zealot; far from it in fact. Most of my software to date has been permissively licensed. The difference in this particular case is I'm not just building a tool or a library, I'm building out a complete product and putting a LOT of my hard-earned time and energy into it. Enough that I want to actually put in writing that any modifications should also be open-sourced.
Hard disagree with your sentiment here. The AGPL is what every company doing BSL stuff should have done. They will never deviate internally from their upstream repo, they have to keep it maintained to make it worthwhile.
Yes, they can relicense contributions to paid customers but that’s the case anywhere. People need to make money and that’s okay. The problem is when the publicly facing code is relicensed and a person who has contributed effectively loses the rights to run their own code. This solves that problem as long as that person continues to be a good open source citizen.
I see this a lot. And I think I understand where you are coming from. But I guess I see things another way.
My thinking is something like this. I'm using project x (for free). I fix something or whatever. I contribute it back because that's the social contract. It's my minor contribution, my paltry acknowledgement of the value you add to me.
Do as you please with it. It's not a stick for me to wave later on. It's not a ticket for me into your boardroom. Here it is, it's my gift to you.
I fully expect you to create a commercial product down the road. I acknowledge that you probably like eating as much as I do. I've no problem with that. I'm probably not the market for you, I'll likely never actually pay you, so here's my offering.
If and when you make a commercial offering I'll have lots of options. You'll have lots of options. Worst case I'll make a fork, or move onto something else. You owe me nothing, I have received more than I gave. I wish you well.
So sure, here's my CLA. I do this for you, not for me.
-- I'm not saying that my attitude is more, or less, right than yours. If you don't want to sign a CLA, then don't. That's fine. I present merely an alternative viewpoint.
> I wouldn’t consider any of this open source any more.
If you sell someone a AGPLv3 licensed software, that is completely okay and FOSS.
If that someone sells someone else a (maybe modified) AGPLv3 licensed software, that is completely okay and FOSS.
Not only Matrix can resell Element for a fee, so can you! That is open source and freedom for you.
The ability to change or dual-license has always been limited to special circumstances. That said, yeah, don't sign a CLA.
No, the Affero GPL is not "FOSS". It is Open Source but it is NOT libre because of the additional requirements (forced upstream contributions even on unreleased modified versions of the upstream software) imposed on potential forks of the project.
Affero GPL is the premier tool of "open source" corporations to confuse potential contributors into THINKING that the project is FOSS and in order to trick them into giving up their labor for free.
Don't fall for it! If someone wants you to contribute to an AGPL project, you should ask: how much will you pay me for my labor?
The AGPL is the single best example of the difference between Open Source and Libre software. The AGPL is so restrictive and grants so much power to the original rights holder that it is really a source available proprietary license.
Stop giving your labor to for-profit companies for free! It screws all of us!
HEY DOWNVOTERS SHOW ME WHERE I'M WRONG IN THE LICENSE
I quit a job over this stance, because I won't contribute to this farce. But Element lovers downvote because they like being exploited and won't even comment to show me why I'm wrong about this
No open source licence I am aware of, including AGPL forces upstream contribution. They force you to make the source code available to anyone who asks. It is very different. Upstream contribution typically requires a significant investment, there is usually some process to follow, quality requirements, sometimes a bit of politics. Here, you only need to go to the dev machine, make a big zip file of the "source" directory and put it on a server somewhere. And you may even ask to get paid for the hassle, as long as it is reasonable.
As for what you will gain by contributing to an AGPL project. You gain the contributions of all the other contributors. And the original rights holder has no more and no less rights on your contribution than you have on the entire project. They can't take your contribution and make it proprietary unless you explicitly allow it, in the same way that you can't use the project and make it proprietary. It is the base principle of free software licenses (incl. AGPL), everyone has the same rights.
Now, the rights owner had the additional rights of being able to release the software under any license, including commercial licenses. But that's only for the code they own, not external contributions, unless they made a separate deal with the contributors. And once it is released, they can't go back, it can live its life as an AGPL project forever, get forked, etc...
As a contributor, if you don't want to be exploited, just don't sign the CLA and stay with the AGPL license.
> They force you to make the source code available to anyone who asks.
That’s not precisely correct. It requires that iff the person asking is a user of the code in question (including over a network for AGPL).
I can take AGPL code, modify it, run it privately for my own purposes, tell you that I’ve done that, and still turn down your request for the source code.
> The GNU Affero General Public License is a modified version of the ordinary GNU GPL version 3. It has one added requirement: if you run a modified program on a server and let other users communicate with it there, your server must also allow them to download the source code corresponding to the modified version running there.
I don't understand how this corresponds with anything you are saying.
It says if you modify the code you must distribute it. That means if, for instance, I wanted to modify Synapse to satisfy my users, for instance a bespoke authentication backend, I would be FORCED to release and distribute that change.
This is NOT the way the GPL works, because the AGPL forces you to make your change available to the parent corp so that they can benefit for free from your labor. The GPL only forces you to make your source code available if you plan to distribute it. The AGPL makes that requirement for even USING server software. It is not the same, at ALL!
And it's right there in what you quoted -- what part don't you understand about "must make available for download the source code"?
> the AGPL forces you to make your change available to the parent corp so that they can benefit for free from your labor
I think you're missing a crucial nuance here. You have to make your change available under the AGPL. So the parent corp cannot use your modifications in proprietary offerings unless you separately and voluntarily sign a licensing agreement.
This grants you power over the parent corp: if they want your changes, they either need to keep them equivalently open, or they need to come to an agreement with you.
It's GPL3 with a server technicality loophole closed. If you think that's intolerable, I think it just did it's job in protecting the authors and everyone else from you.
> It says if you modify the code you must distribute it.
It doesn't. It says if you modify the code and make the modified binary available as a service, then you must share the modified code with users of the service.
You're not obliged to let the parent corporation use your service, so you're not obliged to give them its source code.
I almost went there myself in my response, but I don't think that's the strongest argument since any of your users could request the source and then hand it over to the parent corporation, albeit only under the terms of the AGPL.
Yeah but then you have non CLA-ed code in the original codebase which in the context of an AGPL+CLA project, now it's just AGPL and their upstream has to be maintained separate from their proprietary offering.
So in that sense, it's no different than if the maintainers was just a collection of open source contributors rather than a corporation. They can integrate your changes as long as they comply with the license but they can't meaningfully profit off of them outside of any service you yourself code be providing as well.
Oh, so modifying and releasing source code automatically makes you sign the CLA and contributes those changes back to the parent project? I'm not seeing how forcing modifications to libre software be published as libre software is a bad thing.
I cannot speak knowledgeably about the original (non-GNU) Affero GPL v1, but about the GNU AGPL v3 I can say:
It does not require "forced upstream contributions". What it requires is that users who use the program over the network can get a copy of the source code. Your statement sounds a lot like the FUD about the plain GPL requiring forced upstream contributions; no, it only requires you give the source to those who get a binary from you; the AGPL only requires that you give the source to those who have access to your server instance.
Now, there is a cogent argument that applies everything you said not just to the AGPL but the GPL as well; but that does not appear to be the argument that you're making. So I will proceed with the assumption that you consider the GNU GPL v3 to be acceptable (possibly with the exception of the AGPL-compatibility clause in section 13).
The only non-name-change-related/reflective difference between the GNU GPL v3 and the GNU AGPL v3 main license text is that the AGPL adds the following paragraph to section 13:
> Notwithstanding any other provision of this License, if you modify the
Program, your modified version must prominently offer all users
interacting with it remotely through a computer network (if your version
supports such interaction) an opportunity to receive the Corresponding
Source of your version by providing access to the Corresponding Source
from a network server at no charge, through some standard or customary
means of facilitating copying of software. This Corresponding Source
shall include the Corresponding Source for any work covered by version 3
of the GNU General Public License that is incorporated pursuant to the
following paragraph.
Now, if you're giving your contributions to a for-profit company that can re-license your work to a non-copyleft license... yeah, stop doing that.
> I cannot speak knowledgeably about the original (non-GNU) Affero GPL v1
The only non-name-change-related difference between the GNU GPL v2 and the Affero GPL v1 is the addition of the following item to section 2:
> * d) If the Program as you received it is intended to interact with users through a computer network and if, in the version you received, any user interacting with the Program was given the opportunity to request transmission to that user of the Program's complete source code, you must not remove that facility from your modified version of the Program or work based on the Program, and must offer an equivalent opportunity for all users interacting with your Program through a computer network to request immediate transmission by HTTP of the complete source code of your modified version or other derivative work.
> Selling exceptions means that the copyright holder of the code releases it to the general public under a valid free software license, then separately offers users the option of paying for permission to use the same code under different terms, for instance terms allowing its inclusion in proprietary applications.
Crucially, Element is not trying to sell an exception as the copyright holder. They want you to sign a CLA, because they want to sell AGPL exceptions code you wrote, and they are not a copyright holder of your code.
“In practice, open source stands for criteria a little looser than those of free software. As far as we know, all existing released free software source code would qualify as open source. Nearly all open source software is free software, but there are exceptions.”
I know that term, but I don't think it's that much more clear. When someone forks the code and makes changes but doesn't contribute it back to the community, them having been allowed to do that is more permissive. However, what outsiders can do with their changes is less permissive.
There's no shortcuts to making a nuanced topic much more clear.
I also didn't say that this type of license is the only kind that is acceptable to me. I like copyleft, including AGPL, and for me it depends on the context. In this situation, I want a vendor neutral federated chat tool. There already is one, XMPP, and Matrix has long been putting itself forth as the successor. However, they just made the reference implementation non vendor-neutral.
Stallman’s point (which I largely think is a cop out, fwiw) is that the goal should be that the software remains free, and that making small compromises to further that goal is ok. Repositioning your software to be nominally free but actually picking a license that maximizes the chance that people pay you for a proprietary version goes against this spirit, because it’s clear that you don’t actually have software freedom as your priority.
> Stallman’s point (which I largely think is a cop out, fwiw) is that the goal should be that the software remains free, and that making small compromises to further that goal is ok.
Mm, that doesn't really summarize (or engage with) Stallman's thinking on the matter.
Stallman's position is that if it is perfectly ethical for someone to license their research under e.g. BSD, MIT/X11, or a license that is similarly permissive, and it is (of course) ethical to license it under GPL, then it is not more unethical to go with something which sits in between the two (copyleft for some, permissive for others).
To put it another way: if Alice picks a GPL-compatible, free software license like Apache 2.0, and then Goog makes something proprietary out of it, then Goog is being unethical, not Alice. If Goog does the same thing and gives Alice money, then nothing changes except the bad actor has less money and the good actor who created the software and made it libre has more money.
This doesn't make sense, though, because Alice could just pick a permissive license and claim that everyone who uses it to make something proprietary is being unethical. The whole point of the GPL existing is to prevent people from doing this, because going "oh it's on them for ruining things" doesn't actually work.
Your claim, if I understand it correctly, is that selling an alternate license is OK because you're not doing anything unethical directly; after all, you're offering your version with the code. If they don't provide their source, they're the ones being unethical, not you.
I don't think this actually works, because if you look at the reason GPL exists in the first place, it's to prevent precisely this kind of move. It is "immoral" to release your code under a permissive license, not because you are doing something wrong, but because you are enabling someone else to come in and take that code and make proprietary changes. So selling a license to let someone do this seems like the same thing to me.
My claim is that my characterization of how Stallman thinks about this is an accurate characterization of how he thinks about this.
> It is "immoral" to release your code under a permissive license
That doesn't jibe with the FSF philosophy at all. I get the feeling that I'm interacting with someone who "knows" more about the FSF and Stallman based on what they've heard or imagined rather than actually reading what either Stallman or FSF have to say.
Permissive licenses like the X11 license are free software licenses and have the FSF's (and Stallman's) approval.
I called Stallman's point a cop out, so I quite frankly do not care very much about his position here, because I think it explicitly goes against what he espouses elsewhere.
I think the real cop-out is wading into a discussion with a comment purporting to explain/address a public figure's "point", and then when it is explained that you haven't portrayed it accurately, declaring you don't actually care about what their position is.
If you didn't have software freedom as a priority, then why even pick an open source license?
To me they are trying to find a way to make a living, while still working on free software. It seems to me like a win-win situation: users get more free software, and they get to pay their bill.
This is not always possible with every kind of software or business model though.
Because being open source gives them a marketing win. The number of people who would contribute to this is higher than the number that would contribute to a proprietary license.
If the proprietary version is what they prefer over free and open source software, and which they are not allowed to distribute and modify, and which are otherwise completely identical, it's no skin off my back.
If they don't want freedom for themselves, that's on them.
The whole point of copyleft is that the proprietary version is going to have changes in it that are not free, which are not contributed back. If they want to go "oh we can sell you an alternative license but you're not actually allowed to change any of the code, so it's just strictly worse than AGPL" only the stupidest of legal departments are going to go for that.
Never is a bit much. It really depends on the language in the CLA. Are you giving them the right to change the license, etc? Some CLAs (e.g. Apache’s) are not objectionable. Some are very objectionable.
Are permissive licenses also "screwing over the community"? Those also allow third parties to use the code in proprietary software. What difference does it make to the community if Element gets paid for this?
Yes using permissive license allows businesses to take unfair advantage of the work done by the community for their own profit without contributing anything, but it's explicit in the license terms. When you go with *GPL + CLA, it's more subtle: bad things can happen, but pinky promises are made that won't be the case. We've seen that movie before of course.
As a community contributor, I may not want my contributions to be used to enrich a corporation that doesn't give back to the commons.
Yes. That's why you shouldn't contribute to software on permissive licenses.
> What difference does it make to the community if Element gets paid for this?
Without that, Element would have to either pay people their fair share, or _leave_. They're not a charity, they're not doing this "for us," they're just extracting free labor.
that'll depend on the preferences of the individual contributor; some might be perfectly content with a single lump-sum payment for signing the cla, but it's true that it might be difficult for the company to negotiate something so simple with other contributors
Honestly? Yes. Permissive licenses are one of several reasons that the net effect of Open Source software has been a net negative in terms of software freedom.
I way prefer them to do that than them to close their shop. They do all the development and then you have some big software development providers selling solutions for millions of € to government agencies and they get nothing out of it. That at some point they consider that a part should go back to them or if no money some code is fair.
The difference is that so far, everybody was allowed to do that. With that change, only they can do that (with new code going forward). And ask developers to jump through hoops for the privilege.
That _might_ be the best option for Synapse etc, but it should be clear what they're offering.
Isn't this the case for any GPL-like license? Anyone wanting to build commercial software based on GPL-licensed code has a choice - either publish the full source code, or try to negotiate a closed source license with the copyright holder.
> What they are doing is a required step to pull the same stunt as terraform.
Except that Terraform never had a strict open source license like the AGPL, they had MPL which doesn't require you to distribute your changes with the same license as the project.
I don't see this as hostile and I believe it's more targeted towards Beeper (created by the Mautrix bridge devs), who maintain a closed fork of Synapse and will eventually sell their services for other users. This way makes sure that the Beeper devs either contribute back to their upstream projects, or pay a fee to not have to contribute back.
fwiw, it’s not targeted at Beeper, who support Matrix via the Foundation, and who I believe are happy to publish their synapse changes under the AGPL. It’s targeting companies and governments with many billions of dollars at their disposal who commercialise Matrix without contributing anything back at all.
Agreed. The difficulty of changing the license is proportional to how many copyright holders there are. To change Linux's license, everyone who ever contributed to it probably needs to agree in writing. In comparison, it is trivial for a single copyright holder to change the license, even the GPL. Anyone contributing should know the risk exists.
There are two related but separate issues here that need to be considered:
1. Relicense to AGPLv3
2. New CLA in place for contributions.
For a project like Matrix, the move to AGPLv3 seems clearly a good one. This is not just a library that you add to your app, it's a product in and of itself, and it's been getting abused by proprietary companies who are robbing the ecosystem. From the blog post from Element[1][2]:
> Today we have arrived at a crossroads. We have succeeded in making Matrix wildly successful, but Element is losing its ability to compete in the very ecosystem it has created. It is hard for Element to innovate and adapt as quickly as companies whose business model is developing proprietary Matrix-based products and services without the responsibility and costs of maintaining the bulk of Matrix. In order to be fair to our customers, we need to be able to put more focus on them and their specific requirements.
This is a major and legitimate problem that could undermine the future of the project, and lead to a world where proprietary versions are king and open source lags behind. The AGPL is a good solution to this problem IMHO. When a project gets to a certain scale, GPL-style protections become important to ensure contributions are being returned instead of hoarded. The Linux kernel being a class case study.
The CLA however, I'm not a fan of generally speaking. It appears to exist so that Element can sell proprietary licenses/versions of Matrix, which I'm less sympathetic too. However, without Element, Matrix would not exist and generally they have been good stewards and provide 95% of the contributions (per their claim in the blog post). To me, they deserve benefit of the doubt here.
Everything that you side was said of Terraform months back, and of some other organisation before that.
It is very unambiguous that this is part of a move to an open-core model. I would not consider this project open source any more, even though it still technically is so for now.
I don't know about "everything" but yes I agree, there are a lot of similarities here. There is definitely a possibility (maybe even probability) that Element is going to release proprietary versions with "extensions" to general customers, in ways that core would benefit from but they withhold for competitive advantage. I really hope they don't do that, but they could. Definitely we should watch them closely and with a skeptical eye, and we should call them out if they do that.
In a way Element already develops with an open-core model because of special features for customers that aren't useful for the wider ecosystem. E.g. adjustments for the healtcare sector.
Element has existing contracts with companies and governments about permissively licensed software. They can't relicense to AGPL without a CLA to honor their existing contracts without much work.
I think the AGPLv3 is a poor choice for what is essentially the reference implementation of the Matrix Protocol. The whole point of a protocol is to allow different implementations. Having a base implementation that others can freely fork and develop into whatever they want with whatever license model they want is a good thing for the protocol. I can understand if the Foundation were to maintain a very basic reference implementation- maybe even just a library or set of libraries with no real UI. And then corporations could develop an AGPLv3 (or whatever license they want) Project on top of it.
The CLA is an absolute atrocity, though. It is a bright line of perdition. No one should sign it.
This is an interesting point and does sound good in theory, although in practice it's just the for-profit proprietary companies who are doing the forking and expanding, and then making a ton of money and not contributing anything back to the reference implementation.
I do also dislike the CLA, but I'm torn because if anybody should be making the money from these custom extensions/implementations, it should be the company who does 95% of the core contributions, and I don't see a way to do that without the CLA. Not that my opinion matters as I'm not connected at all to Element or any other players, but just generally speaking I'd love to hear potential solutions to the problem that don't require a CLA
fwiw, the main problem with the CLA seems to be that folks have assumed the intention is to use it to switch Synapse & co to a closed license in future - which I honestly hadn’t even considered as a possibility. For one thing, we could have done that already under the Apache license; instead, we deliberately did the opposite - to move to AGPL. The reason for the CLA is purely to allow us to sell AGPL exceptions to commercial forks.
They claim it will be the Apache one in their blog post, but I doubt it, the Apache CLA grants the ASF a license, not Element or the Matrix Foundation. From what they have said, it sounds like it will be a grant to Element. The ASF CLA says: "In return, the Foundation shall not use Your Contributions in a way that is contrary to the public benefit or inconsistent with its nonprofit status and bylaws in effect at the time of the Contribution."
Based on what has been said by Element, they have no intention of making this part of their CLA.
I'm a big fan of AGPL + CLAs. It's a perfect balance where Free Software community gets what it wants (actively maintained, quality, free software that humanity at large can benefit from), while propriety community gets what it wants too (pay and get paid).
People who complain about it are naive and entitled thinking that someone can build and maintain something non-trivial for them indefinitely by just pure altruistic sacrifice and just give it away for free.
With AGPL + CLAs you get all the benefits of fully free software, while the copyright holders get something in return for their work: a competitive advantage and being able charge someone other than free software community.
As a developer signing a CLAs it doesn't bother me at all - my work is freely available to everyone with a license that preserves that freedom for everyone, which is what I cared about. The fact that it can make money to the copyright holder doesn't cost me anything, and is a reward for value they shared.
You don't get people bitching nearly as much about MIT, BSD, etc. where ones making most money on it are the usual big tech players in a position to resell it as a service or an appliance. Why does it bother anyone so much that company providing all that FOSS value will be in position to make money?
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 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.
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.
> 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.
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.)
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.
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, 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.
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.
I have never seen as much negativity for an open source project on Hacker News as I have seen in every single Matrix thread. It is unbelievable. The only thing that might come even close is FlatPak. It's been going on for years and years. If anyone doesn't believe me, just click Arathorn's post history and start browsing. I've never understood what Matrix did to deserve this. It's a fantastic project - I've been using it every day since ~2017. It has its problems but it's head and above every other project like it and provides real value. Better still, the Matrix folks seem to really be thinking things through and making, even if not the best (subjective), a well thought out and well explained decision every time they make a decision.
I have seen every. single. possible. attack. thrown at Matrix OVER AND OVER again. Every single one. So many quite obviously not in good faith. Matrix is owned by the Jews. Matrix is owned by the CIA. Matrix is owned by Germany. Matrix violates privacy laws. Matrix tricks you into thinking your messages are deleted when they aren't. Matrix (this one's hilarious), BROKE SIGNALS ENCRYPTION (lol). Matrix is scraping all the rooms to sell to Google (lol). XMPP was perfectly fine and we didn't need Matrix. Matrix collects too much metadata. Matrix federates by default. Matrix is too slow (ok fair). Matrix is going to sell out.
This has been going on for the 5+ years I've been using Matrix. People have been sounding the alarm for a half decade about how awful and evil Matrix is. Yet it keeps plugging along, solving truly hard problems, getting better and better, and being released openly (I have no idea why, if I were on the Matrix team I'd have ragequit by now). It is absurd the level of criticism that is thrown at a project that has asked no one for anything, and has truly made the world a better place.
You're right, it's absolutely ridiculous. While there are things worthy of criticism (e.g., the protocol based on HTTP polling isn't exactly realtime, decryption errors are mostly just a UI bug in Element, Element in general having many UI bugs, etc) these aren't even close to worth the outright hate Matrix gets here.
HN is usually a hypefest for any new technology, but as soon as the topic turns to Matrix the threads immediately become a Mad Max-style wasteland. It makes no sense whatsoever. Especially this thread – a move to AGPL with a dual-licensed option for corporate customers is absolutely fine, Stallman and the FSF support it, and it's the most sustainable way to run a truly free software project.
The only reason I can think of why HN would be so hateful towards a license change is that many people here actually used Matrix to build proprietary products and don't want to contribute to upstream (be it with code or money).
It's an interesting pattern to be sure. It's not all negative though (e.g. this thread has a few moments of positivity mixed in with all the folks jumping to the conclusion that we're trying to pull a Hashicorp). I have a few theories as to why it happens:
1. Communication is an intensely personal and social (even intimate) thing, and people get irrationally attached to how they do it - and so end up defending their favourite system, attacking ones which threaten it, or attacking their ex-favourite if they feel let down and/or betrayed.
2. I think this effect gets amplified in a feedback loop if you use the platform to build the platform itself. This is true of course for operating systems, desktop environments, programming languages etc. too - but it seems to be particularly the case for chat systems. Perhaps this is because it's intrinsically accelerated by the higher emotional/dramatic/intense characteristics of realtime chat - it's effectively mixing the intensity realtime interactive social interaction with programming. So if you spend all your life sitting in a chat system talking about and building that chat system, then spirits can run disproportionately high. You see the same levels of jingoism in IRC and XMPP too.
3. Culturally I think Matrix has picked up both good and bad cultural vibes from IRC - and for better or worse, one of the things that defines IRC is a somewhat elitist vibe: it's a fringe subcommunity for folks who are smart and informed enough to navigate the by-geeks-for-geeks interface. As a result, folks get tribal about it - both Matrix (although I pray that we eventually get mainstream), IRC and XMPP.
4. Matrix has been going for over 9 years now, and it's still not as good from a plain UX perspective as a centralised system like WhatsApp (although I'd hope that we've improved a lot recently, especially with Matrix 2.0 and Element X). As a result, there's been a lot of expectation and hype over the years, which hasn't always materialised as rapidly as you'd hope. So there are certainly those who feel let down.
5. Matrix wouldn't exist if previous projects had not hit a plateau and got stuck, and so folks who are still working away on previous projects are understandably irate.
6. I talk too much on HN and it pisses people off.
Honestly, given that Matrix is a spec and not just a first-party client, it reminds me a lot more of BitTorrent.
BitTorrent the client went full proprietary, but that did nothing to the adoption of BitTorrent the protocol, because open-source implementations are all over the place.
That's at least what I hope is the worst case here.
Nice to see AGPL instead of something like the increasingly-popular (non-FOSS) BSL. Copyleft licenses are great, I've seen too many examples of permissively-licensed libraries being taken, worked on by corporations and profited from without any bug fixes/improvements being upstreamed.
I've been using Conduit as my matrix server with the help of a few programs I wrote myself to ensure admin user exists etc.
I am really impressed with how little resources Conduit uses. A fresh install with a few rooms was only consuming about 32 MiB of RAM. Compared to both Synapse and Dendrite, this is nothing! I haven't stress tested the server by federating with a gigantic channel like the official matrix channel, but for a select few channels on libera.chat with hundreds of people, I am still yet to break over half a gigabyte of memory used.
It's also refreshing seeing RocksDB being used as opposed to Postgres, at least for ease of deployment. I run Conduit in a single container and have all of its data in a single volume. I think a large reason why memory consumption is very low compared to Synapse is because I don't have to deploy Postgres. (Yes, I am aware Synapse also supports SQLite, but you quickly migrate to Postgres the moment you need to run any popular app service).
The only downsides I can think of at the moment are
- Lack of SSO support, which means my friends and I have to maintain dedicated accounts for Matrix even though all of my other self-hosted services use OpenID Connect a single IdP.
- Conduit does not send read receipts in federated rooms, though you can see read receipts from others.
It's great. I've been using it as a single-user Matrix homeserver for a little more than one year now and haven't had any issue with it whatsoever. It's taking around 100 MiB of resident memory and consuming 0% of the CPU on my small server; I've used chat /clients/ that use ten times more than that.
A long time ago, I remember a MySQL talk where they explained dual-license as "if you make money, then we make money", while keeping the product FOSS.
I think it's a reasonable simplification.
And if the company changes the licence, then a A/GPL fork can survive (c.f. Hashicorp, which could have probably avoided their issues with a better licence from the start, but at the time no one expected to be eclipsed by big cloud providers with infinite resources).
While I don't agree with everything Stallman says and does, I really do appreciate that his position on this issue is not just another axiom, but follows purely from other positions he had already established.
This really sucks. I have always had great hope for the Matrix protocol. The AGPL isn't my favorite open source license, but it has its place... but a CLA? That is a complete nonstarter. No one should ever sign a CLA that gives a company more rights to your contributions than you get from theirs.
Speaking as CEO at Element - I don't particularly like CLAs either from an ideological perspective. However, the only way that Element can retain the right to provide alternative licenses to proprietary forks is if it has the right to do so, which means requiring a CLA. Otherwise the license change would not solve the problem that it's trying to solve, i.e. to provide a way for proprietary forks to contribute back to Matrix development costs, without having to AGPL their forks.
[edit: clarify that CLA != assigning code ownership]
> However, the only way that Element can retain the right to provide alternative licenses to proprietary forks is if it has the right to do so, which means requiring a CLA
You wouldn't need a CLA if you didn't want to reserve the exclusive right to move from an open source model to an open core model. You wouldn't need a CLA if you didn't want the privilege to switch away from an open source licence at will.
Yes, a CLA is the only solution to retaining the right to un-open-source the project. The problem is that you'd want to retain this right in the first place.
We don’t want to un-open-source the project. We’re not trying to pull a hashicorp or set up to do so; we just want the option to dual license to sell AGPL exceptions.
I've used element every day for a while now, it's fantastic software...
The trouble is that I want to believe you, but I'm(and I imagine certain others) having a hard time doing so.
Element has been giving us open source code under the most liberal license for something like 10 years. I think he’s earned a little benefit of the doubt.
If folks want to keep their contributions on their own fork and not sign a CLA that's fine too. Yes, we're trying to monetise our code in order to pay folks to keep working on it.
The subject of this discussion is collaboration. You want to benefit from that collaboration without providing collaborators an equal opportunity. By instituting a CLA, you have disincentivized collaboration.
I understand you have determined this to be a good compromise for you and the developers you pay to work on Element. That doesn't make this situation any less bad to the rest of the community.
So that begs the question: will having a stronger source of revenue for your team be worth alienating 3rd-party contributions?
No matter the answer, I think its totally reasonable for those contributors to complain about the situation you have placed them in.
> That doesn't make this situation any less bad to the rest of the community.
How is the community suffering here? Let's say Element adds a bunch of baller stuff to their versions over the next few months and then closes the source. Can't the community just fork the last AGPL version? You might say, "well then no one can take the AGPL fork and make their own closed-source business", but do you want them to? Even if you do, they still can with the existing Apache-licensed version, just like Element is doing right now.
You're arguing that Element will lose a lot of contributions, but TFA points out that despite being super open, the vast majority of contributions are still made by Element employees (which seems to be true [0]). It's not the case that Element is looking to monetize the (small) contributions of others, it is the case that others are looking to monetize the (huge) contributions of Element.
And besides, aren't the MSCs the core of Matrix? It's already super possible to build your own compliant client and server.
The situation is that Element needs money to keep developing the ecosystem. It would be cool if there were a big network of donors and contributions, but there isn't. You're essentially saying, "that's fine, go out of business then, and the community will keep developing the ecosystem", but that's not happening now, and it can still happen anyway with the Apache-licensed versions, which again people can still contribute to.
It hurts the community by promoting proprietary forks.
If Element adds a bunch of baller stuff to their version, then that is the best case scenario.
On the other hand, if Apple or Microsoft or Google add some really baller stuff, then Element's version has to compete by blindly reproducing that work.
Even worse, if Apple or Microsoft or Google add some mediocre feature, but use that feature to make their users incompatible with Element's version, then Element will have to compete by blindly reproducing a feature that no one actually wants!
---
And why should any of us expect the best case scenario? Corporations are paying to monopolize this work. Why would you pay to monopolize something, then never use that monopoly to be anti-competitive? That would be fiscally irresponsible!
> On the other hand, if Apple or Microsoft or Google add some really baller stuff, then Element's version has to compete by blindly reproducing that work.
> Even worse, if Apple or Microsoft or Google add some mediocre feature, but use that feature to make their users incompatible with Element's version, then Element will have to compete by blindly reproducing a feature that no one actually wants!
Only if the diff against the Apache version is worth money though, which doesn't seem like it will be for a while. I can think of other more likely scenarios:
- Apple forks the Apache version
- Microsoft contracts some Element developers
- Google buys Element
- Facebook makes some contributions under the AGPLv3 (okay, maybe this one isn't super likely)
In any and all cases, the community still has the AGPL version. I really don't see a downside here, and plus I don't know what companies are supposed to do if not this.
> I don't know what companies are supposed to do if not this.
Maybe there's not actually a viable way to be an open-source company as a business model. As much as I want Matrix to succeed, the world doesn't owe them that.
Well then I don't really understand why you're upset now. Element is doing what everyone says you should do: have a GPL project and sell hosting, support, and proprietary licenses. We can't have the only model be "get donations or be independently wealthy".
I'm not sure who this "everyone" person is, but I have certainly never suggested having a GPL/AGPL project and then selling proprietary licenses. (The other two, very much yes.)
This seems like a tedious point. What are you looking for here, a survey or something? Are you in good-faith interested? I think if you were you'd google around a little.
Yet I don't get to sell it (edit to clarify: under a proprietary license, like Element corp) in order to pay for my contributions, or for my own employees contributions? So you are saying you don't trust the Matrix community, present or future?
Plenty of companies survive without CLAs and pay folks to work on open source. I appreciate the business interests, but there are better ways to manage open source projects than CLAs.
With the previous licensing, yes. The change to AGPL would have ended the ability to make proprietary forks, but that ability was preserved by the CLA instead.
This means that the only effective result of switching to the AGPL is that Element can demand money from anyone who makes a proprietary fork. Basically, the AGPL has been backdoored for profit.
If it's any consolation, the fundamental asymmetry replaces a previous asymmetry that Element uniquely donated all of its core Matrix code, including ownership, to the Foundation. But yes, I wish that the economics balanced without a CLA. But they don't.
I have high hopes for the future of Matrix in large part because of the Matrix Foundation. But what happens at Element when you and Amandine leave? What stops Element from being bought by a huge corporation that takes the whole thing proprietary and kills it?
I'm sympathetic to the position that you find yourself in here (I have a standing recurring donation to the Matrix Foundation). But this seems substantially less secure of a future.
I don't know if it would work from a legal perspective, but it'd be nice if there was some sort of dead-man's switch.
> what happens at Element when you and Amandine leave? What stops Element from being bought by a huge corporation that takes the whole thing proprietary and kills it?
If Element explodes by whatever mechanism, other folks can fork the AGPL code to keep it going. We’re looking into mechanisms to ensure CLA’d code stays published under an OSI compatible license regardless of the type of explosion, which I guess is a kind of dead man’s switch.
I think there are a few helpful things in that regard:
- There are already viable and deployed alternatives to Synapse, including Conduit. Making changes that would break compatibility would fragment the network.
- There are already viable and widely-used alternatives to Element on the client side. I myself mostly use Nheko these days.
- The structure of the Matrix protocol is such that breaks in compatibility would look very weird to users, so I think they're incentivized to avoid making such changes for their user experience's sake.
- The primary selling point of Matrix (and thus Element) over other systems is precisely that it's an open protocol for communications. It seems unlikely (though not impossible) that they would do anything to harm that, but if they did, it would not look good for the company. Speaking personally, I would start looking for alternatives if they did.
I thought Element was founded after the Matrix Foundation, and thus Element has been using the Foundations code all along? Yes, they have continued to voluntarily contribute to the Foundation, knowing that it was in their own best interests to grow the Matrix community.
* 2014: Matrix core team creates Matrix, writes Synapse and other implementations, starts writing the Matrix spec
* 2017: Matrix core team wants to be able to focus on this exclusively as their dayjob; creates New Vector (aka Element) to fund their work.
* 2018: Matrix core team establishes the Foundation as a neutral custodian of the standard on behalf of everyone in the ecosystem. Element transfers all its core Matrix IP to the Foundation, and (uniquely) continues to donate its future contributions to the Foundation, hoping that by letting the whole ecosystem build on top, including proprietary forks, Matrix will spread as far and wide as possible to the benefit of everyone, and Element will make enough $ selling Matrix hosting/distributions to keep hiring the core team to work on Matrix.
* 2022: Matrix has spread far and wide, but turns out that in the commercial space, huge companies who bear no cost for supporting the Matrix ecosystem whatsoever discover they can sell proprietary forks for many $. Meanwhile, Element spends its life funnelling most of its time & energy into doing core Matrix ecosystem work, and it turns out that trying to compete with the big guys while all your energy is going into the commons doesn't work.
* 2023: Element decides it can't afford to contribute as Apache any more, and switches to AGPL + CLA, thus requiring the big guys to either opensource their proprietary forks as AGPL or arrange a paid license from Element. Yes, this means that contributors to Synapse will need to sign a CLA to Element, and it's depressing if this hinders community contributions, but it's the least worst solution we can see.
Thank you for that clarification. I would echo the other comment- What "huge companies who bear no cost for supporting the Matrix ecosystem whatsoever discover they can sell proprietary forks for many $"? Please call these "huge corporations" that are making a fortune selling proprietary forks of Element/Synapse out? A huge part of the reason Matrix has spread far and wide is because it was open source, under a foundation, and had quality, liberally licensed open source implementation. If it weren't for these facts (I grant there may be some debate on how much the liberality of the license played into it, but I am pretty confidant it has been a significant factor) I doubt it would have grown nearly as much, and Element corp would either not exist or be much smaller. I think this change is a huge mistake, and I only hope that the Matrix protocol survives this mistake, hopefully the Matrix Foundation will continue to be a good steward of the protocol.
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.
Not necessarily. There are a lot of things that folks look for when buying hosting or a support contract. For example, trust and confidence. I trust the primary maintainer of a open source project to be able to support me better than some one else maintaining a proprietary fork. In fact, the fork being proprietary means I am not going to use it when there is an open source alternative. However, I also distrust a project that is AGPL/GPL with a CLA to a corporation. If there were no good alternatives, I would probably choose the open source option to proprietary one... but I would try to find some one else to support it. Prior to this change, I would have defaulted to using Element/Synapse software, and paying Element corp for any services I require. After this change, I am looking for alternatives not only to Element corp, but to Element/Synapse the software. Even if I continue to use Element/Synapse, I am unlikely to pay Element corp for support services. I will look for an alternative.
Governments are a whole other ballgame, your right. They often have very particular requirements that not every company is going to be able or willing to meet, though. I don't know enough about their particular business to say without a more complete analysis, but even with governments, just having a cheaper product is not always enough to get your bid accepted.
But they were not in the business of private forks, as per their statement. They were in the business of providing hosted instances, and services.
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.
I already mentioned a bunch of them at the top of https://matrix.org/blog/2022/12/25/the-matrix-holiday-update... when trying to get folks to donate to the Foundation. While this helped with new players, it didn't help with existing ones (although one did send us $500). So switching to AGPL is the next line of recourse.
That post mentions a few big companies using the Matrix protocol, but are any of them using proprietary forks of Element/Synapse/Dendrite?
Another thing not clear from that post was the layoffs- were those layoffs at the Foundation, or Element corp? Either way it was a loss to the Matrix community, for certain!
Yes, the commercial Matrix vendors are all using proprietary forks.
The layoffs were from Element; the Foundation has only a managing director as an employee (who started a few months ago). And yes, the layoffs have been a nightmarish loss for Matrix - as a result P2P Matrix, Third Room, Low Bandwidth Matrix and many other more ambitious projects are currently shelved.
The point of the licensing change is to try to break even and avoid further layoffs, by requiring third party commercial forks to contribute financially.
The amount of hate for doing so is astonishing, but hey.
The thing that's so upsetting to me is that since I started using and developing against Matrix.org in 2016, Synapse has always been positioned as a reference implementation, it has always been a wedge to get others to come play in your sandbox, a gift to the community to encourage growth, a positive-sum engine, even if companies like Discord or whoever are trying to use Synapse behind the scenes to implement Matrix.org interop. To enclose that now because your business model relied on the good graces of other corporations just causes those proprietary forkers to not trust neither Matrix nor Element.
y'all are trying to get this shit IETF standardized and cram Matrix interop through via DMA while tying down your reference implementation, think about how that looks. that code should be as permissive and easy to integrate with as possible! who wants to pay a protection racket to an organization who's proven itself this fickle?
sure sure, enclose dendrite and the Element product family, things you explicitly built for scaling the matrix.org server and "Element the product" but Synapse should always have been seen as a loss-leader, a hulking mass of Tornado code that says "here's how you could implement this standard and it works well enough for operators of small or medium sized communities but wouldn't it be nice if you did it this more sustainable/scalable way? give us a call"
It just shows to me a lack of creativity or courage and instead says "well we parted ways with our corporate sponsor a few years ago without enough of a business plan and now we're hungry"
I would fully agree if your contribution were 50%, or even 10% of the code base.
But if your contribution makes up 0.001% of the code base, and theirs makes up 95%, I think there is a much bigger fundamental asymmetry already at play that changes the fairness math a bit.
My understanding is they're already doing it, and they're already allowed to under the previous license.
The CLA is also my least favorite part of this change, but it is overall a shift towards copyleft vs. the previous permissive licensing. If this means the project can remain FOSS and the company can continue to work on it, that's a good thing in my book.
If they ever relicensed to a proprietary license though I'd be calling for a fork.
It's a great step, except that it effectively doesn't matter, because anyone interested in ignoring the copyleft mandate can afford to buy their way around it.
The only effective purpose for a copyleft license here is to get paid for permissive license! I'm not against the Element devs getting paid, and I get that this is their best shot at that. I still won't count this as "a good thing in my book".
The whole point of the [A]GPL is that the end user can access source code. Letting people buy their way out of copyleft effectivley nullifies that.
> The whole point of the [A]GPL is that the end user can access source code. Letting people buy their way out of copyleft effectivley nullifies that.
But previously, anyone who wanted to deny end users from accessing their modified version of the source code could do so, immediately and at no cost to themselves. This adds a barrier to doing so.
I'm not saying it's the ideal situation. What I'm saying is that from the perspective of someone who wants to ensure that end users retain access to the source code (which describes me!) this seems to accomplish that goal better than the previous license.
Yes, that is an improvement, but that improvement ends at the boundary of proprietary forks that pay their way out of copyleft.
Encouraging corporations to pollute the Matrix network with proprietary clients will surely introduce fragmentation to the overall ecosystem. This will only hurt end users.
The other side of the coin is that Element will be in a stable position to pay its devs, which is great! Regardless of that, I'm not a fan of this strategy. Hopefully it will pan out well enough that proprietary forks fail to compete with Element's AGPL repo.
A better comment here would be a little more curious about why they're doing it (so they can run a business and fund future Matrix/Element development) or to maybe suggest some alternatives.
They're allowed to say they don't like it and people shouldn't do x or y.
I'm not sure why you believe that every comment needs to sealion in some way or another, or provide alternatives. People are allowed to dislike choices made by others and state that. And just that. "I'd have preferred you didn't" is a perfectly valid comment to make. They don't have to do what the comment is asking, you don't have to agree with it etc, but it is a valid comment.
I didn't say it was invalid. I gave an example of how it could do better. I'm allowed to say I don't like their comment, to dislike it and state that. I even did better and gave them constructive criticism, walking the walk, which you are not doing for me.
> No one should ever sign a CLA that gives a company more rights to your contributions than you get from theirs.
Why not? I've signed CLAs to contribute to open source projects that I use every day. These projects already offer me tremendous value for free, and while my contributions may help other people, they mostly help me since they tend to be fixes for problems that I personally have with them. Having the fix contributed to the project also usually means that it becomes someone else's problem to maintain it in the long run, so it's not even a burden for me.
So I already get way more than I give in that kind of situation. Knowing that they can potentially profit off of my contributions gives me some peace of mind. If they can build a sustainable business from it, then they'll be able to survive and I'll be able to keep benefiting from it. It's a win-win!
Of course, I guess it's possible (maybe) that they'll be able to do a bait and switch and force me to start paying. I've never had that happen to me, and I might change my mind if it does.
There have been GPL/AGPL projects in the past that used CLAs and gone propeietary... I don't have the details at the moment, but I prefer to the ounce of prevention, rather than waiting for it to happen to me.
There have also been Apache v2-licensed projects that have not used CLAs and gone proprietary. The risk of a proprietary fork by Element is not changing as a result of this, and actually the risk of a proprietary fork by anyone else (that includes post-relicense changes) goes away.
I too would prefer AGPLv3 with no CLA, but that doesn't seem like it's going to happen at the moment, and this seems like a step in the right direction.
If I (and everyone else) have the same power to make a proprietary fork as they do, then I don't mind so much. It is when they have more power than everyone else that I start to mind.
I don't have a broad opinion on CLAs, but the Element announcement [0] says it's just the Apache Software Foundation's CLA, which I think most people are fine with [1]. It's more or less just a copyright/patent grant.
Matrix even has a foundation, they could have the CLA go tot he Matrix Foundation... but they aren't. Even then, I trust the Apache Foundation more than the Matrix Foundation- not that I have any particular distrust of the Matrix Foundation up to this point, just that they don't have the same track record as the Apache Foundation.
On their blog post, they claim to use the "standard Apache CLA" which indeed does grant the license to the ASF... presumably they plan to modify the CLA to grant the license to Element... but I haven't been successful finding a copy of their modifications. The Apache CLA also contains a critical clause :
"In return, the Foundation shall not use Your Contributions in a way that
is contrary to the public benefit or inconsistent with its nonprofit
status and bylaws in effect at the time of the Contribution."
Based on the Element blog-post as well as comments they have made here... I doubt they plan to keep that clause in place.
> Based on the Element blog-post as well as comments they have made here... I doubt they plan to keep that clause in place.
I'm trying to understand your objection, but I can't see how the community can suffer here. Even in the worst case scenario where the foundation versions wither and Element takes their versions closed source, can't the community fork the latest open source AGPL versions and continue the work?
I don't know if there's a copy of Element's CLA, and until there is we don't know that.
People are free to use the existing Apache-licensed versions of Synapse/Dendrite, they just won't get Element's contributions. Basically all this means is you can't resell Element's work for free. If you really want to build a business around the Apache Synapse/Dendrite, you're free to do exactly what Element is doing right now. I don't get what the problem is.
One example is Linux. You don't need to sign CLA to contribute to Linux. It has contributions from thousands of developers all over the world. It means that to switch Linux license to, say GPLv3, you would need to get permission from all of those developers or rewrite their contributions which is not possible in practice.
To avoid this situation, some projects require their contributors to sign contributor license agreement. Terms might differ, but generally you allow your contribution to be relicensed in any way in the future. So today Matrix's AGPL, tomorrow they can go proprietary and you're OK with that. Also they want to sell their source code with proprietary license (so buyer's not obliged to open his modifications) and they also need contributor permission to do that.
Basically it's a commercial project which is not interested with external contributions.
> tomorrow they can go proprietary and you're OK with that
That depends on the CLA's wording. A CLA could allow the right to sell commercial licenses to the code while always keeping the same code under the AGPLv3.
I haven't read it either, but a comment nearby (allegedly from the Element CEO) claims that their intent is to use this CLA to sell commercial licenses.
AGPL also has some annoying side effects if you do t use a CLA. For example, Matrix has had a few proof of concepts for pure peer to peer network designs where every device runs its own server.
That would be impossible toddeploy to app stores like the Apple App Store because that store is inherently incompatible with (A)GPL. The only way you can publish (A)GPL code to iPhones and iPads legally is to dual license all code from all contributors.
With a CLA, a project can relicense the code to itself. Without it, the project can't upload their own project to the App Store and similar platforms.
I think you'd be crazy to run Synapse on a phone, but Dendrite is built to be much more efficient for such use cases.
When you try to contribute code back upstream, the company will require you to grant them broad rights to do whatever they want with it, including to relicense the code you are contributing under a proprietary license. You do not get the same rights in return to the upstream code. So the company can yake your contributions and go proprietary and you have no recourse.
I'm surprised it's not more of a thing to have a CLA that allows relicensing only to another OSI-approved license. I don't see many examples along those lines[0]. And the "OSI-approved" wording would allow a project to freely switch between MIT/BSD/GPL/etc or even create their own license (as long as they get it OSI-approved) without having to hunt down past contributors for permission.
I would never sign an open-ended CLA, though. For all I know, the project (with my code in it) could end up being bought by Oracle, proprietized, and used by Larry Ellison to construct the Torment Nexus.
> I'm surprised it's not more of a thing to have a CLA that allows relicensing only to another OSI-approved license.
That would be meaningless - they could relicense it to MIT, distribute that MIT-licensed version to their subsidiary, and then have that subsidiary sell it under whatever proprietary license they wanted.
They grant the organisation (in this case a for-profit) the exclusive right to redistribute the project (and contributions made to it) under a different license. Including a proprietary licence.
It is only required if you intend to move to an open-core model, or intend to eventually make the project non-open-source entirely. This is a common first step for many organisations that have moved in this direction.
The announcement even makes it clear that they intend to ship versions for a fee, so it's very likely that we'll see a "community edition" and a "full edition" at some point. Or some other model which amounts to the same general idea.
they allow the company making you sign the CLA change the license the entire project with your contribution in it to what they like, including making it proprietary.
I do appreciate _not_ using some home made license, thank you.
Personally though, I find the AGPL too restrictive for projects. The [OSI Certified] EUPL I think is perfect:
* If you don't modify the code: Behaves like the ASL2.0
* If you do modify the code:
* Behaves like the LGPL in that your private codebase remains private, but changes to the library must be submitted back during a 'distribution' event
* Behaves like the AGPL: Offering a service that uses the library counts as a 'distribution'
The last point I never understand. E.g. take Redis if it were licenced in that way: where is the line where it counts as a service? Directly exposing a Redis port? Putting a REST API over the top of it and selling a cache as a service? Making a paid for JWT invalidation service that's basically a small application layer of Redis? Or something else?
I suggest reading the license as IANAL... but my understanding is all three of those would count as a "distribution" event.
Keep in mind, you would only need to "make source available" if and only if you modified Redis. And even in that case, you only have to submit the modifications to Redis. So even though a "distribution event" is happening, if there are no changes to the Redis server or client library itself, you're compliant without doing anything else.
So yeah, all things considered, it'd be a great license for Redis in my opinion.
You have to go to a list of languages, and then once you find English on the list it gives you a PDF or text, no HTML version.
I read it, and I think the exception allowing for compatibility with the MPL would allow me to pretty much do what I want with a larger work, as long as I release changes to the code files, and shipped it with some MPL code. It says that where the license conflicts, the compatible license prevails. I'm also not convinced that the Distribution section behaves like the AGPL: https://opensource.stackexchange.com/a/12298
The fact that the EUPL is available in all the official languages of the Member States of the European Union is a very important aspect of the license for me. This means I could reasonably fight for the freedom of my software in the local courts available to me in my home country, which does not have English as an official language.
As the European Commission claims on their site, as one of the reasons they chose to create a new license instead of relying on those already available:
> The licence should have equal legal value in many languages.
In addition, the EUPL is not any license text some (from a legal perspective random) people came up with, but the text of the license was written and voted into law by the EU itself, therefore it can and does rightfully claim the following, which is invaluable to me as a FLOSS author residing in the EU.
> any litigation resulting from the interpretation of this License [...] will be subject to the jurisdiction of the Court of Justice of the European Union [...]
So even if the local courts interpretation in my home country falls short, the Court of Justice of the European Union will surely take into account the intended purpose of this license as laid out by the legislators of the EU.
I've never see that detail, that's incredibly insightful. Granted, for outside the EU it doesn't win much, but I'm guessing most reasonable places would defer to what the host country intended.
That being said, as another commenter pointed out, the "make available as service" language is a bit weaker in EUPL than AGPL.
I, for one, am glad that licenses exist that aren't written in English exclusively.
Most of the world aren't native English speakers and most native English speakers live in a particularly British-derived system of law. Most open source licenses are full of assumptions that the legal system they're implied in are either modeled after the American system or derived from Common Law. Translations exist, but they're not more than that.
The EUPL was explicitly designed to comply with EU trademark and copyright law, which differs from American copyright law in various ways. It also fixed the "you can read the license in your own language but if you want to use those freedoms you'd better learn English because that's the version that counts" problem.
One big limitation to the EUPL is that it only covers European languages (as it was designed for the EU).
I can't say I feel too bad about needing to pick the English license from an alphabetically sorted list. There aren't any officially valid translations of AGPL, nor for Apache, nor for MIT. I don't think many programmers will run into problems using English, as programming is often very English oriented, but for the common people, that's different. A rural farmer with little to no access to higher education should know that he has the right to change the software on the embedded equipment he bought, even if he doesn't speak a word of English. He won't be altering the software, but perhaps he knows someone who could, and knowledge about possibilities can be the start of change.
After all, what freedoms does free software provide if it's only free to the minority of English readers?
> 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 unfitting(substandard/wrong.
I never thought I'd say that a FOSS team is doing too much work, but it seems to me they burned out for some reason. I can only speculate as to the cause. Changing the license is not going to fix that problem.
Anyway, I'm still an active Matrix user, and am grateful for all the work they do put into the projects. I just thought it was more fun to be able to contribute.
> 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 to have five, six back and forths trying to get the person to write the test case you are telling them to, which you could write yourself in 90 seconds. never mind then getting contributors to write good docs, good changelog notes in the format your project uses, etc. I'll give them one shot for that stuff then I just do it, I really don't have time to "train a new employee" (who doesnt even want to be trained, they just want their one-line fix) for every single one line change.
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".)
You mean PR edits? Yes, for small touchups, certainly. Anything that makes the life of maintainers easier. I'm talking about changes that requires maintainers to check out code. You shouldn't feel you have to do that, and if there are many PRs, you shouldn't feel you have the time to do so.
> Tangentially, I'm finding that with Nix it's now feasible to apply fixes and customisations to packages even if they have "hostile maintainers"
I have that same feeling with Docker/K8S. I don't know how many images I've modified to make them runnable as non-root, but quite a few.
When you open a PR, look for the "Allow edits by maintainers" checkbox beside the "Create pull request" button. For PRs you've made earlier, you can find it in the sidebar under the participants list.
oh that thing. I've always found the flow for "editiable PRs" in github to be horrendously confusing and difficult to use. we do all of our edits in Gerrit.
I was hoping you meant a checkbox that says, "this contributor is OK with the maintainers taking over this PR to finish it up"
You're absolutely right that sometimes holding hands takes longer, and as a project maintainer it's up to you to decide where the right tradeoff point is.
However, the alternative side is to simply ignore the PR until the contributor is actually helping you. As a maintainer, you shouldn't feel you have to drive the PR. You should guide it, and spend most of your time on whatever else makes sense.
(Again with the caveat that I don't know what caused the Dendrite devs in particular to make the decision to close down contributions.)
A lot of folks will just walk away from the project after such an experience. Its in the long term interests of a community to bring new contributors up to speed rather than alienating them.
But then they say they won’t be continuing to fund development and “They’ll need to get their upstream releases from Element’s repositories going forward.”
that seems to mean that future downloads should come from Element? That sounds more like a handoff than a fork.
The old repos "belong" to the matrix foundation, but the work on them was mostly done by the element team. This is them officializing that synapse and dendrite are element branded projects, not matrix (so yes, it is indeed a handoff), except they are branding this as a fork because the license is changing.
They also are changing licences to require downstream forkers to also open-source their changes, ensuring corporate users of matrix contribute back upstream if they modify their implementation (beeper might be in some hot water, though they can very well continue using and maintaining their own fork from the matrix foundation repos with the old licence).
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 whatever they please with your code... but you don't get the same rights to their code.
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 could use another server - like Conduit.
Beeper’s Synapse fork is already open source. Element has not had any license changes as far as I know and their applications are hard forks, meaning that even if the license changes in the future, they are safe from it.
Not sure if AGPL’s “network use is distribution” is a concern but most of their bridges are open source as well.
Disclaimer: Currently working part time for Beeper. I specifically asked the founder about this after reading the article.
> ensuring corporate users of matrix contribute back upstream
My understanding is that they are doing the opposite: by making contributors sign a CLA, they are free to sell corporate users their own private licenses, so those corporations can each keep a proprietary fork of Element's AGPL source.
From how I understand this: Synapse and Dendrite were Foundation projects, but the contributions came almost exclusively from Element.
Element is forking the two projects, and is redirecting their maintenance efforts towards their own forks. This means that the Foundation versions of the projects will not receive active maintenance anymore, and the Foundation does not have the funding to invest in the development themselves.
It's a de-facto handoff, unless someone wants to invest significant resources in development of the pre-fork versions of the projects.
If I'm not mistaken: The two projects were started by the people that founded Element. When they founded Element, they transferred the projects to the Foundation, to make them more independent. Now, they're taking them back and relicensing them with a reciprocal license (AGPLv3 + CLA) instead of a permissive one (ALv2). I assume this is about other companies using Synapse and Dendrite without contributing back, so now Element wants to be able to sell licenses for the projects, or get contributions. See https://element.io/blog/element-to-adopt-agplv3/ for more details.
I contacted the foundation funding channel, multiple times,specifically about becoming a member to support p2p development and they don't even have the decency to respond.
Honestly this whole thing feels like a bait n switch. Get the community based matrix popular and cozied up with the public sector and then lock that shit down under the element Corp.
The foundation, who's job it is apparently to protect/guide matrix outlook and development, now has no ability to actually govern said project.
AGPL is the way. Every time I see BSL I just laugh - the AGPL is enough to scare away people that don't want to contribute back. And the enforced contribution means the original author can incorporate changes they put no effort into back into their own product.
IMO the only options for a cloud hosted service are:
1. Closed source
2. AGPL
Anything else is a half measure that disproportionately puts users or the business at risk.
If they want a CLA, fine. It still enables a fork later.
GPL and its derivatives are the only licenses that will stand the test of time for open source products for sale.
It’s awkward to ask people to assign everything to you in a way that makes you the only entity that can sell AGPL exceptions. If contributors are paid for their contributions that would be awesome, but it’s not clear that they are.
I welcome this change, with the hope that they will be able to release higher quality server implementations resulting from this change. Question to @Arathorn: is there a plan to consolidate and have a single server implementation? I would love if Dendrite would become the reference implementation and have something works both for self-hosters and big deployments.
no plan to consolidate; current plan is to keep improving Synapse as a mature & stable server, and use Dendrite as a test bed for new ideas (eg account portability)
So does this pretty much boil down to "we are re-licensing Synapse and Dendrite from Apache to AGPL"?
In what way is the "owner" of the code significant, in this case, other than being a proxy for the maintainer of the most popular fork?
These projects are open source, so the only thing this code is really attached to is the license. Whatever entity controls the majority of developer effort effectively controls the future of the project. So far, that entity has been Element, and the features being worked on in the client and server applications have been and will be influenced by the customers of Element and the sponsors of the Foundation (for an example of this influence, see the biometric/PIN lock introduced in the Element X mobile applications).
The point of contention here is not really the license change, but the CLA attached to it. Basically, if you write code for Synapse/Dendrite, submit it to the project, and sign the CLA, the (for-profit) Element Foundation may relicense your code under a proprietary license. It's intended to keep contributions from proprietary clients coming without them fleeing the ship because they see the four letter word AGPL.
> Whatever entity controls the majority of developer effort effectively controls the future of the project.
Yes, but that doesn't preclude others from stepping up with developer effort on the originals, should they want to. Given the widespread use of matrix, this does seem like a possibility.
Oh wow, this is laudably frank in my opinion. They are quite up front about the motivation behind this change. Two relevant excerpts:
> Over the last year or two Matrix has evolved from ‘explosive growth’ to being a ‘category’ in its own right. In other words, ‘Matrix-based’ is now specified as a requirement in massive public and private sector tenders - in which multinationals compete to provide Matrix-based products and services.
and
> Today we have arrived at a crossroads. We have succeeded in making Matrix wildly successful, but Element is losing its ability to compete in the very ecosystem it has created. It is hard for Element to innovate and adapt as quickly as companies whose business model is developing proprietary Matrix-based products and services without the responsibility and costs of maintaining the bulk of Matrix. In order to be fair to our customers, we need to be able to put more focus on them and their specific requirements.
So basically, Element can't compete with other companies for the contracts that only exists because of Element's work, because the other companies can focus just on making proprietary extensions for code that Element has more or less the sole burden of maintaining. So Element is saying to those companies, hey, either AGPL your modifications and extensions (AGPL is relevant since if you're running eg sidecar services with Synapse or Dendrite, this will still hit those sidecar services), or pay for a license for our code. This seems fair to me, to be honest.
And yeah, I understand people's moral objections to the CLA, but it's necessary for Element's strategy to work. And maybe I'm naive but I do believe Element and the team have Matrix's best interests at heart, they're just also grappling with making money and being self-sustaining, and so I hope that they succeed in that for the sake of the broader Matrix project and ecosystem.
This change also does not seem likely to me to affect open-source work or the broader Matrix community for the most part. If you want to self-host a Matrix server this shouldn't change anything for you. All the code you're running is already open-source, you don't need to do anything. Matrix as a protocol and an ecosystem of servers and clients and users won't be affected by this, just companies selling services that are based on Element's open-source code.
And protocol governance hasn't changed, it's still in the hands of the Matrix Foundation, and this won't change that. And you can say, hey, Matrix protocol development has always been driven by Element and its priorities and interests—yes, that's absolutely true. But this change won't affect that either! And in fact, if the CLA pushes pushes community development efforts away from Synapse/Dendrite and toward other projects like Conduit[0], then this might even be good for the ecosystem and community governance by decreasing Element/Synapse's influence over the direction protocol, which I'd be happy to see.
So yeah, as someone who is self-hosting Synapse and really rooting for an open, free, community-centric Matrix protocol to succeed, I'm not heartbroken over this change. I'm actually even a bit hopeful about what it means for Element and Matrix going forward.
Probably a silly question but I’ve always avoided looking at the source code for anything which I think might later want to implement myself. If I avoid others’ IP I can claim I wrote mine in a clean-room and license my code on my own terms.
The reason is that I believe if there’s even a whiff of me having seen someone else’s code then I can’t make any claim to the copyright and, in fact, they will claim it instead.
So then imagine if I put up a pull request to synapse with a feature or bug fix but — crucially — I do so without signing a CLA. Do orgs like Matrix employ PR reviewers who work in dirty rooms (opposite of clean room) to review these, shielding their core devs from the accusation that they are reading others code without a CLA to transfer the copyright?
An attack from a kind of Doctorow-esque scifi story: you publicly fix your competitors bugs for them without assigning copyright, tainting their dev pools’ ability to claim their own code was a clean room implementation.
"Element is losing its ability to compete in the very ecosystem it has created" - anybody know what proprietary companies/projects are possibly being referred to here?
They keep open source license, so why not. If money's involved, it's gotta be messy either way and matrix is too convoluted and complex to be developed without money envolved.
1. You can still use any code written before today under Apache 2 and build a proprietary version out of that.
2. If you'd like to build a proprietary tool that makes use of the new features Element builds after today, you can do that as well if you negotiate with Element.
But you won't be able to use any of the new work Element does on Synapse after today without either open sourcing your project or paying Element.
The CLA gives them the ability to relicense, which affects proprietary products built on top of Synapse/Dendrite. Without the CLA, all code written against the AGPL-licensed Synapse/Dendrite would have to be licensed AGPL as well, even if it interacts with Synapse/Dendrite over network boundaries as part of a SAAS offering or somesuch.
I believe that's why 'AGPL' is a four letter word in certain circles.
No, that's a common misconception. The relevant section of the license is:
> Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.
This does not state that you must license any of your software that interacts with the AGPL code over the network as AGPL, merely that you make modified versions of the AGPL code available to users who interact with it over the network licensed as AGPL. The rest of the license generally behaves as the GPL would.
Why move the repos from the matrix-org GitHub org to Element's? Feels like that's a step back in what concerns Matrix Foundation assets being untangled from Element.
The problem I have with the AGPL is some companies interpretation of the AGPL. And the FSF or the license itself doesn't help to clarify these issues. For example MinIO had this text on their compliance page:
> To "modify" MinIO means to copy from or adapt all or any part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting derivative work is sometimes referred to as a "modified version" or we say that it is "based on" the earlier work. > Passing configuration parameters to a MinIO binary instance constitutes making a modified version, as it does not produce an exact binary copy.
> Combining MinIO software as part of a larger software stack triggers your GNU AGPL v3 obligations. > The method of combining does not matter. When MinIO is linked to a larger software stack in any form, including statically, dynamically, pipes, or containerized and invoked remotely, the AGPL v3 applies to your use. What triggers the AGPL v3 obligations is the exchanging data between the larger stack and MinIO.
They changed this language now, perhaps understanding now how insane that made them look (or a lawsuit forced them to, no idea): https://min.io/compliance
But still, I like the AGPL too in theory, but I understand why many companies don't touch anything AGPL, its a very fuzzy, complicated license that leads to a legitimate uncertainty. For the license to be useful it actually needs to be used by companies in order for them to contribute anything back to begin with, but many are avoiding it like the plague.
/edit MinIO also still has this text on their page:
"Designed for developers who are building open source applications in compliance with the GNU AGPL v3 license and are able to support themselves. It is fully featured. If you distribute, host or create derivative works of the MinIO software over the network, the GNU AGPL v3 license requires that you also distribute the complete, corresponding source code of the combined work under the same GNU AGPL v3 license. This requirement applies whether or not you modified MinIO."
So AGPL (at least in some peoples twisted minds) goes far beyond protecting something from AWS&Co.
You can remix it for commercial uses going forward. Provide your source code when requested, as required by `AGPL-3.0`, or pay for a commercial license.
Depends on what you want.. XMPP as a protocol is somewhat comparable, but I like the Matrix model better. You can still use the Matrix protocol without adopting this new corporate fork, though.
AGPL, on the spectrum of “I’m allowed to do whatever I want” to “they heavily restrict what I can do” sits firmly on the right side, alongside patents and other forms of heavy handed government intervention. It sucks how free as in freedom came to mean freedom to make rules about others.
Have you ever contributed anyway ?
If not it was already assymetric since you were just an user and they were providing the software.
Anyway, nobody forced you to use their software. Your loss.
Forced open source for everyone but them. They retain copyright and will continue to sell proprietary adaptions, while forbidding everyone else to do the same.
It's forced for those who can only use it under the license (everyone except Element/Matrix). It isn't forced for the copyright assignee (Element/Matrix).
This seems a little premature. It reminds me of Monty Python and the Holy Grail where the "bring out your dead" cart[1] is coming and a guy tries to dump a body, and the body says "I'm not dead."
It's definitely not a good look, but when taken in context this ironically might be the thing that saves the project from death.[2]
I definitely felt like something was wrong, given that the protocol seems to have lots of problems and Dendrite has been in 0.x beta since basically forever. But I don't know what this means practically for Matrix.
Too many people riding their coat-tails and not paying royalties for the hard-work they did and continue to do. I think they should go the CE & paid versioning that other projects have chosen. Let people continue to experiment with CE and once they are in a corporation, "we" can steer our bosses to the paid version.
Alternatively, they should move up the stack and offer a clean deployment/hosting option (remove the container ops with a ci/cd direct to their hosting company). The argument is, we have to host this somewhere, why should we give peter that which rightfully belongs to John? So if John Matrix get into the hosting business, problem solved.
> 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 ship under some alternative license, for a fee. They’re making others sign an agreement to ensure that they have privilege to ship the project (or forks of it) under a proprietary license.
I wouldn’t consider any of this open source any more. These are step that a organisation takes when they want to move to an open core model and screw over the community. What they are doing is a required step to pull the same stunt as terraform.
It’s technically still open source today, but this consolidates them into a position to change this at will. Don’t be fooled by the tricky wording that makes this sound like a good thing. These folks are very unambiguously screwing over the community and making it sound otherwise.
As usual, remember to never sign a CLA.