cinnyapp
Switch license to A/GPL or Apache?
I feel a project as big as this should have a license that fosters community growth and protect the project's identity.
Why A/GPL?
GPLv3 or AGPLv3 protect from closed source clones thus the project could benefit if there are some useful features in clones. You can read more at https://www.gnu.org/licenses/quick-guide-gplv3 or https://www.gnu.org/licenses/why-affero-gpl.html
Why Apache?
Most of the implementation by Matrix Team are under this license so it fits better in the community. And this quote from GNU.org site summarizes why Apache over MIT
Among the weak (pushover) licenses, Apache 2.0 is best; so if you are going to use a weak license, whatever the reason, we recommend using that one.
Why not MIT?
Because it's most permissive and doesn't give any kind of protection and is mostly used for Tools, Libraries, packages,
Note: I have privately asked the lead dev @ajbura about this and he advised me to open an issue so that it could be discussed more broadly.
Apache is also a permissive license, so it's more comparable to MIT.
In my opinion AGPL would be the best choice for a web application to protect freedom.
Something to keep in mind is that despite the lofty ideals, the practical usefulness of copyleft licenses is... debatable, at best. GPL violations are widespread in practice, and are basically impossible to do anything against without having a lot of money for lawsuits. Cinny developers most likely don't. Established copyleft-supporting organizations rarely take on such cases on their own funding. Meanwhile, plenty of corporations (including eg. the much-maligned Apple) also release source for tools where it is not required by the license.
The end result of this is that it's questionable whether a copyleft license actually protects from proprietary forks any better at all than a simple request to contribute back changes; and unfortunately there is a non-zero cost in adopting a copyleft license, as they are generally highly complex to understand (especially for individual developers who don't have a legal department), and they come with a lot of caveats where it concerns combining them with code under other licenses (see eg. the concept of "GPL compatibility").
I've found it much more effective in practice to simply exclude proprietary/commercial actors from the community and support channels entirely; forking a FOSS project is not very commercially interesting if it's not possible to get support for it. This approach also does not place any burden upon non-commercial FOSS developers, who now won't have to try and understand a massive license (and if anything, this provides them with a significant advantage over proprietary actors).
I realize that the belief of copyleft licenses as a "way to ensure software freedom" is widespread, but I really want to ask to think critically about whether this is actually true under real-world circumstances. Ideals are one thing, but if the implementation turns out ineffective, it doesn't make sense to keep relying on an ineffective tool; and instead, alternative approaches should be considered.
AGPL doesn't do what people think it does. The way it's actually written, any time you make a source code modification, you have to, at the same time, make the modification to make it serve the correct source code URL. Any time you make any change, that change must include the changes needed to make it point to your changed copy of the code, even if you have not published anything yet, aren't planning to run it. So in practice, it's basically impossible to comply with, and ~100% of AGPL projects simply exist in a state of constant license violations by their own contributors.
GPLv3 is a fine choice for end user facing application. It gives people incentive to not make proprietary forks.
As for effectiveness, I've seen plenty of proprietary developers steer away due to GPL. Of course some people may still violate it, but that doesn't mean that GPL isn't effective; the same way door locks aren't useless just because a burglar might pick the lock.
AGPL doesn't do what people think it does. The way it's actually written, any time you make a source code modification, you have to, at the same time, make the modification to make it serve the correct source code URL. Any time you make any change, that change must include the changes needed to make it point to your changed copy of the code, even if you have not published anything yet, aren't planning to run it. So in practice, it's basically impossible to comply with, and ~100% of AGPL projects simply exist in a state of constant license violations by their own contributors.
It is a common myth (spread by google) that the AGPL is hard to comply with. In reality, Cinny is already in complience with it, as it contains a link to the github page, and a version number. If you wanted to make it even easier to find the exact source you can just generate a link to that release.
Anyone else running the same version (e.g. the one on docker hub) is also in compliance, as its the same code, and so the same applies as above.
The only difference is that if I wanted to host a fork of cinny, I would have to indicate where the code is hosted (ie. change the github link)
No strong opinion on AGPL/GPL/MIT on the rights, AGPL seems like a totally fine choice for this project, but in general I strongly prefer open source licenses with an explicit patent grant. That implies [A]GPLv3/Apache/etc and not MIT.
One note, in order to ease the burden of AGPL compliance, one "normal" trick is to have a feature directly in the UI to download the current code running on the server. This avoids having to add additional code to comply with AGPL if you change any of the source running on the server.
What about ignoring the proprietary forks? It's an E2EE app, who would use a proprietary client? Someone might create it, but nearly nobody would use it.
Probably someone would create a proprietary fork. But if there is no open source fork, you could simply change the formatting rules, reformat, commit, and the fork is wrecked. (This method can't be used if there are open source forks.)
AGPL doesn't do what people think it does. The way it's actually written, any time you make a source code modification, you have to, at the same time, make the modification to make it serve the correct source code URL. Any time you make any change, that change must include the changes needed to make it point to your changed copy of the code, even if you have not published anything yet, aren't planning to run it. So in practice, it's basically impossible to comply with, and ~100% of AGPL projects simply exist in a state of constant license violations by their own contributors.
Even if this was true, using git does this automatically lol
Beeper is already a proprietary fork of Element (and is very popular), and these guys are very big parts of the matrix community, (you've most likely used their bridge software), so that is what will happen if you choose a permissive license. And there are umbrella organizations that handle GPL enforcement, e.g. Software Freedom Conservancy. Additionally with it being javascript, it's very easy to detect if there is a proprietary fork, and most of the relevant programs will be by western companies that do follow the law and licenses. Also as you may seen with the kernel, they have even managed to make back-alley chinese companies publish source code for their android modifications.
Obviously the AGPL only applies to things you have distributed, as the license only grants users of your software the right to see the code that is running, even if it's done over the network (whereas non-affero doesn't apply to websites). Also naturally this can be done via github or gitlab like usual, as there just needs to be a reasonable way to access it. (You could probably still get away with CDs if you wished).
I fail to see why the current license is a problem, what are we trying to protect the project from, why are private forks bad for the project exactly?
I fail to see why the current license is a problem, what are we trying to protect the project from, why are private forks bad for the project exactly?
closed source software is bad for everyone.. especially the users who don't know better than to use it.
closed source software is bad for everyone.. especially the users who don't know better than to use it.
Bad for everyone how? sounds like an opinion, is there any real reason?
I fail to see why the current license is a problem, what are we trying to protect the project from, why are private forks bad for the project exactly?
When I want to contribute to a project it's kinda demotivating to think about someone using my work to spy on users, lock them in silos, and make sure they can't tweak their program, and then abandon their proprietary software once they are done with it. With the GPL they will at least have give the users some freedom, and the community can see the code and potentially integrate it into the official version.
The patent grant that you find in both GPL and Apache are also very important, because it means the contributors cannot sue people using or modifying the software for violating a patent they have.
Also note that private forks that aren't shared with anyone are not being discussed here, it's only once you start providing the program to third parties.
When I want to contribute to a project it's kinda demotivating to think about someone using my work to spy on users, lock them in silos, and make sure they can't tweak their program, and then abandon their proprietary software once they are done with it. With the GPL they will at least have give the users some freedom, and the community can see the code and potentially integrate it into the official version.
The patent grant that you find in both GPL and Apache are also very important, because it means the contributors cannot sue people using or modifying the software for violating a patent they have.
Also note that private forks that aren't shared with anyone are not being discussed here, it's only once you start providing the program to third parties.
Isn't this why Cinny is built on top of matrix itself? as i understand it matrix is supposed to tackle this problem by being an open standard.
Besides isn't comercial use of matrix is a good thing as shown by the matrix project itself, and matrix services?
Couldn't it be a good thing for Cinny itself too? In the future?
Why are you worried about feeling demotivated?
Opinion warning: Let the project grow first, matrix related things need way more attention, you should welcome those problems means your project is successful and people have an interest in it.
What if Cinny could be used as a library to integrate into other products is that a bad thing? would a change in license limit that kind of use? or is that against the goals of the project?
Being an open standard doesn't help if everyone uses a proprietary program that uses it (see gmail), because then that program becomes the standard. Also I'm not saying that commercial use is a bad thing, but we can still have expectations and demands from enterprises (just like we have taxes and laws). If people are demotivated by the permissive license, then the project will have less developers, and the people with proprietary programs won't be contributing either. And since there are other clients that do use (A)GPL, it becomes more attractive to contribute to those programs instead for some people.
Like you've seen in the thread some companies like Google hate the GPL with a passion, because it conflicts with the google-controlled future they are aiming for, so they will avoid the GPL like the plague, so a change in license will discourage these kinds of companies, you can still use AGPL programs as a library, but then it can't be proprietary. Although yes, cinny seems more focused on making a simple and elegant instant messaging app, things like hydrogen/chatterbox probably fit better for embedding anyway.
Being an open standard doesn't help if everyone uses a proprietary program that uses it (see gmail), because then that program becomes the standard. Also I'm not saying that commercial use is a bad thing, but we can still have expectations and demands from enterprises (just like we have taxes and laws). If people are demotivated by the permissive license, then the project will have less developers, and the people with proprietary programs won't be contributing either. And since there are other clients that do use (A)GPL, it becomes more attractive to contribute to those programs instead for some people.
Like you've seen in the thread some companies like Google hate the GPL with a passion, because it conflicts with the google-controlled future they are aiming for, so they will avoid the GPL like the plague, so a change in license will discourage these kinds of companies, you can still use AGPL programs as a library, but then it can't be proprietary. Although yes, cinny seems more focused on making a simple and elegant instant messaging app, things like hydrogen/chatterbox probably fit better for embedding anyway.
Hmm if you can do that and become a standard yourself, if you have that kind of resources like google has, i doubt you need this code in the first place, wouldn't you just be hurting many small companies that could be a part of the community instead?
And Cinny looks great for embedding if you ask me.
The thing google does well is using open source software, because it puts them ahead of everyone else, with the most resources, and with the most available software they manage to win. Chromium for example is built on many LGPL programs, this has resulted in us now having a proprietary browser from microsoft once again, which might have been different if it was GPL.
And note that the way google becomes the standard has always been https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish, they get popular by participating in open standards, and then they gradually make things exclusive, while reaping all the benefits from using a standard that was already popular.
@morguldir
And there are umbrella organizations that handle GPL enforcement, e.g. Software Freedom Conservancy.
In practice, it is very unlikely that your case will be taken on by such an organization.
When I want to contribute to a project it's kinda demotivating to think about someone using my work to spy on users, lock them in silos
Keep in mind that the AGPL in no way prevents this. This is not something you can prevent through a license, it requires addressing on a community/support level (and even there it isn't always possible).
Like you've seen in the thread some companies like Google hate the GPL with a passion, because it conflicts with the google-controlled future they are aiming for, so they will avoid the GPL like the plague, so a change in license will discourage these kinds of companies, you can still use AGPL programs as a library, but then it can't be proprietary.
Note that Google is extremely finicky about licenses in general, including non-copyleft ones. If your goal is to scare off Google, you have broad discretion in what license to pick, they hate almost everything :)
The thing google does well is using open source software, because it puts them ahead of everyone else, with the most resources, and with the most available software they manage to win. Chromium for example is built on many LGPL programs
While I agree that Google is a bad actor, they are also famously hesitant to use any third-party dependencies, and tend to reinvent their own wheels including in many cases where it would be completely unnecessary. A license change is not likely to make any real-world difference in whether Google murders your ecosystem or not. See also: XMPP and Google Talk, which certainly wasn't forked off somebody else's client.
@hypnoagus
Bad for everyone how? sounds like an opinion, is there any real reason?
Something being an "opinion" does not somehow automatically make it invalid. This is a really strange criticism.
IMHO the assumption that this project would be (more) successful if you switch to a less permissive license is wrong. The only asset this project has compared to Element is the current license.
Hello everyone. Thanks for the comments so far.
I have no hard feeling with any of these choices, the reason I initially selected MIT was the it was the simplest to understand (without any legal help).
IMO there's hardly any chance that someone will fork Cinny and maintain in parallel to this repo, so I am not worried about that. There is a fair chance that people will (or are) customize it to their need or maybe rebrand it as their own but in that case, all I want is proper attribution to this project and MIT is not really helpful in that case. So I am also looking into a better license to achieve that. And I also want people to build on Cinny, so here is what I have been thinking:
- We make our design system and release it under a permissive license.
- Make this repo which is an actual matrix client released under a copyleft license. This will contain only the Matrix logic.
What this will achieve is that, if someone wants to make a clone of "Cinny Matrix client" then they will have to open source it as per our copyleft license but if someone wants to use only our design system then they could do whatever they want and in that case we just want is attribution.
IMHO the assumption that this project would be (more) successful if you switch to a less permissive license is wrong. The only asset this project has compared to Element is the current license.
@menturion How exactly? Afaik Element has a permissive license.
Afaik Element has a permissive license.
Afaik, you are right.
What is/are the USP(s) of Cinny and why should a decision maker of a university decide to deploy Cinny instead of Element next week?
Cinny's points from what I've found after installing it this week:
- Uses tauri for the desktop client
- Has categories for spaces
- Design is less noisy
- Built in stickers
- Read receipts are much more compact
- You can pin spaces
- Since cinny is a bit simpler it's also feels quicker
- Sync seems faster
- A few defaults like showing avatar changes are different, which is probably not too important for a university for example
And finally with the plans above, a GPL codebase :p, which is definitely a plus for a university that doesn't get funded by making proprietary programs
@morguldir
Thanks for the feature list. I like Cinny as you do and the maintainers - esp. @ajbura and @kfiven - are doing a really good job.
But to be honest, Cinny does not have any USP compared to Element, with the exception of its current license. Element is a more mature, robust and more feature rich product backed by companies. There are obvious reasons why many universities in Europe use Element.
And finally with the plans above, a GPL codebase :p, which is definitely a plus for a university that doesn't get funded by making proprietary programs
This is a bold and already disproven statement. Major universities get their spin-off funded as long as they present a convincing and robust business model. There is already a cited spin-off in Germany based on Element. And with every project, Element gets more awareness resulting in more financial support at the end of the day.
To think that Cinny will get a competitive advantage in its competitive environment by restricting - i.e. worsening - the licence is kind of illusive. Even more, this measure is a blunt sword. A license agreement is only as good as you are able to enforce it legally.
As @hypnoagus stated this project needs as much attention as possible to grow and to build its own business model on top once this has been achieved. Attract as many organizations as you can ... with less, and not more restrictions.