A new home and license (AGPL) for Synapse and friends
element.io
element.io
> 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.
They already did, as the Apache License allows them to.
That _might_ be the best option for Synapse etc, but it should be clear what they're offering.
Stallman's term is "free software", this said "open source".
I use OSD to define it, so I consider it technically open source, but to me it's open source that isn't under an acceptable license.
https://www.gnu.org/philosophy/open-source-misses-the-point....
“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.”
There's no shortcuts to making a nuanced topic much more clear.
However, it is a frequently used term, so it's useful for quickly referring to these licenses. https://en.wikipedia.org/wiki/Permissive_software_license
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.
If they don't want freedom for themselves, that's on them.
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.
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.
> 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.
> 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.
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.
> 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.
I do contribute to permissive licensed software.
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.
I mean I dislike CLAs personally, but I understand why they can be healthy for a project growth.
These two things are being conflated in this discussion. One thing is a CLA and copyright/license changes. The other is the license itself.
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.
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.
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.
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.
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.
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
> 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.
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"?
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 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.
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.
>> they can't meaningfully profit off of them
To be clear that can absolutely profit off the code, as long as they do do under the same license. ("Meaningful" being in the eye of the beholder.)
Implying that you can't "meaningfully profit" from an AGPL license is not technically true (although, of course, finding examples that do is tricky.)
> they can't meaningfully profit off of them outside of any service you yourself code be providing as well
i.e. They can't do anything with your contributions that any random user or contributor would be able to do under the rights of the license.
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.
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.
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.
I agree with most of your comment, but not that.
> 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.
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.
Element's not demanding anything from anyone. I don't understand your point.
> It makes it clear they intend to ship under the AGPLv3
The blog post says literally:
"or by contacting Element for an alternative license."
So, that's what's on their mind. And that's for a fee [1].
(Not saying anyone is doing anything wrong — I'm using AGPL myself for some software I'm developing, + a CLA.)
[1] See this comment below: "The reason for the CLA is purely to allow us to sell AGPL exceptions", https://news.ycombinator.com/item?id=38181368
Never sign a CLA unless you want the recipient to have full rights to your code.
I’ve signed the FSF CLA, precisely because I want them to have that higher level of rights to my contribution.
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.
The AGPL rocks.
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 generally agree, however a cla in this case might make sense:
1. Allow for dual licensing, helping make the project sustainable
2. Help with copyright assignment, keeping stuff free: it makes possible to switch to agpl v4 if it’ll ever come out.
Point 2 is particularly important and is why linux will be forever stuck on gplv2
It’s literally AGPL. Do you believe a project must not be sustainable to be considered true open source?
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.
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.
[1]: https://element.io/blog/element-to-adopt-agplv3/
[2]: HN thread: https://news.ycombinator.com/item?id=38162275
The CLA is an absolute atrocity, though. It is a bright line of perdition. No one should sign it.
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
Could you elaborate what's wrong with the CLA? It's the Apache one which is a reputable open source organisation, I'd imagine it wouldn't be that bad.
Based on what has been said by Element, they have no intention of making this part of their CLA.
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.
It's precisely what the (A)GPL was made for and it's something even Stallman and the FSF agree with.
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.
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?
I welcome this change - as I've stated multiple times here, we need more AGPL-licensed software!
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.
That’s approximately as long as we have between now and when they stop investing in improving the end user experience.
This is pretty close to ideal IMO.
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.
The SSPL is effectively a stronger AGPL. This makes it non-OSI-approved, but the licence itself is completely fine. The major difference is that the SSPL also mandates that you release everything needed to run the software, not just the software itself.
For reference, it's worth to read the OSI's blogpost about this, it's quite illuminating: https://blog.opensource.org/the-sspl-is-not-an-open-source-l...
It's also worth mentioning that most of the attacks against the GPL, AGPL and SSPL are done by corporate shills, and OSI is also full of them. They pretend to support "non-discrimination of fields of endeavour" but they are undermining free software to SaaS-ify it. Don't fall for the "SSPL is not open source" propaganda.
Which makes it incompatible with little things like the linux kernel, since you don't have the licence to release it as SSPL
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.
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.
If they are doing most of the development they need a way to finance that.
Selling GPL exceptions is a Stallman approved tactic.
(The natural corollary to this is that if the Element/Matrix folks—or anyone—were to ask you for a CLA excepting them from the project's own open source license, then you could/should feel comfortable kindly requiring them to pay you for it—a response which should be the default in the open source world, although it unfortunately is not.)
* i.e. so you can make proprietary software
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.
They just won’t merge your changes without a CLA. You are free to fork and contribute there if you want.
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.
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).
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.
anyway, thanks for the words of support :)
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.
Rust implementation of the matrix server stack
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.
Ah, selling exceptions. Even Stallman thinks this is legit.
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).
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.
[0] https://en.wikipedia.org/wiki/Contributor_License_Agreement#...
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.
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.
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 Element's CLA though.
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.
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.
[edit: clarify that CLA != assigning code ownership]
I have a very straightforward and reasonable solution for you: don't do that.
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.
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.
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.
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.
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.
This fundemental asymmetry is incredibly unfortunate for a project whose stated mission is being a fundamental communication layer.
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.
- 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.
If I understand the confirmation statements at https://find-and-update.company-information.service.gov.uk/c... , M & A already have way under the majority of votes in Element, and nothing catastrophic happened
* 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.
What, exactly, are you talking about here, Matthew?
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.
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!
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.
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"
Competitors can just take the open source parts of the matrix projects without contributing code or funding back.
As result, in a bid between Element and competitors, Element will lose because Element actually pays for maintaining these open source projects.
And where criteria like “trust and confidence” are too often cover for corruption and favoritism.
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.
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.
The very existence of those forks breaks the community's ability to truly collaborate. Private forks still participate in our ecosystem!
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.
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.
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.
[0]: https://github.com/matrix-org/synapse/graphs/contributors
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!
> 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!
Can't they already do this w/ the Apache version?
The change made here wasn't from good to bad, it was from bad to bad.
They can, but they now have more of a financial incentive to do that, since they're implicitly going to get paid by Apple/Microsoft/Google.
- 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.
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.
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.
[0]: https://element.io/blog/element-to-adopt-agplv3/
[1]: https://www.apache.org/licenses/contributor-agreements.html#...
"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.
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?
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.
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.
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.
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'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.
https://commission.europa.eu/content/european-union-public-l...
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
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.
That being said, as another commenter pointed out, the "make available as service" language is a bit weaker in EUPL than AGPL.
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?
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.
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".)
> 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.
I have no idea what this is. Can you share specifics?
[1]: https://docs.github.com/en/pull-requests/collaborating-with-...
I was hoping you meant a checkbox that says, "this contributor is OK with the maintainers taking over this PR to finish it up"
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.)
Synapse and Dendrite projects are forked. Ok.
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.
Can someone clarify this a bit?
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.
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).
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.
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.
Ah, selling exceptions. Even Stallman thinks this is legit.
Even so, I appreciate what his position adds to this discussion.
All I'm really interested in is whether the new (read, old) overloards at Element have serious plans to revive p2p efforts or not.
Going off their behavior on certain github issues, I won't hold my breath and will continue to use briar instead.
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.
link?
More discussion on the blog post over here: https://news.ycombinator.com/item?id=38162514
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.
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).
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.
> 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.
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.
Disclaimer: working part time for them
Synapse and Dendrite have been under Apache 2.0 so far, which would allow anyone to turn them into proprietary products. Including Element.
With this change, the situation is: Element can make them proprietary but no one else.
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.
Disclaimer: I am not a lawyer.
> 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.
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.
> 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.
https://web.archive.org/web/20230320134618/https://min.io/co...
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.
Sadly that usually ends up being the end result.
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.
It's an open source project. What royalties?
>continue to do
and are 100% allowed to.
> I think they should go the CE & paid versioning that other projects have chosen.
I don't think that'd be the best idea, it works for other projects because they're not essentially acting as defacto communication protocols.
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]