That helps a lot with future-proofing the openness of an open-source project [1], and it's a critical detail often overlooked, mainly because it's a technicality of copyright licensing and most people understandably just want to know if something is open-source or not, without getting into the details.
The simplistic gist of it (not getting into differences between Licenses) is that if you contribute to an open source project that requires copyright assignments, then its only promise is that current versions of the code will remain with the same (open-source) license. Future versions might as well become proprietary while benefiting from your code. So depending on your willingness to accept that, it's an important factor to consider. Sometimes you just don't care, then all right just go ahead. Other times you might have a stronger position on this, then step back and think about it.
On the other hand if you contribute to a project that won't ask you for any copyright assignment, then your contribution is yours, its license cannot change in the future without asking for your explicit permission (or dropping your code altogether). This is, if your contribution was a significant enough work; I don't know where the line is drawn legally, but I know (from reading here in HN) that trivial enough contributions might not need permission to be relicensed.
[1]: On the other hand, it might hinder the ability to commercialize it, which might end up meaning that there are no devs pouring serious work into it, which in turn might end up meaning there is no project at all :-) "pick your poison", I guess.
If we look closer, I believe (not an expert, though) that without a copyright assignment your contribution would have to be kept with the same license. We'd be just getting into the fact that non-copyleft licenses typically allow to use the code for building proprietary software. But AFAIK the contributed code itself would need to be kept with the original license? (that's where my knowledge is lacking)
There’s no devil in the details. The entire codebase can be taken proprietary right now and there’s not a thing you can do. You’re free to extend the last permissively licensed version.
OTOH if I had signed a CLA, then your company would be within its right to entirely strip any attribution to give whatever license they see fit to the code I wrote.
Some of us prefer permissive licenses, or choose between permissive and copyleft depending on the nature of the application.
But here's something you can't do with my MIT licensed code: change the license to copyleft.
Point being, if one is contributing to a project with a permissive license, that should imply being a-ok with it getting rolled into some binary in a form you don't have access to.
If one is contributing to a project with a permissive license, that should also imply being a-ok with it getting rolled into a copyleft project too.
Examples of permissively licensed code being used in proprietary systems abound.
Has anyone ever successfully copyleft-jacked such a project? I grant that it's possible but I'm not aware of it actually happening.
That aside, any permissively licensed library used in a GPL program would technically fall under this situation, as it ends up distributed under the terms of the GPL. It just so happens that usually the libraries aren't modified by the application developer, so you can typically go find the original source.
If they are, those changes may be under the GPL, depending on whether the application developer kept the derivative version of the library explicitly under its original license, or licensed their changes under the application's license.
That depends. I don't know the current paperwork, but I assume assignments for GNU software still involve a contract promising to maintain a substantially similar free software licence.
When a license is "compatible", it allows you to relicense that code as GPL, sometimes with additional conditions.
This means that if you link it GPL code into a MPL code base, the GPL requires that entire code base to now be GPL. And as such all other code linked against it also must become GPL.
This can lead to accidentally violations.
On the contrary, you can use MIT, BSD, MPL, LGPL code in a GPL codebase without any issue. You can dynamically link LGPL in any codebase. You can statically link GPL in another GPL codebase.
This is all working as intended.
> All GNU GPL versions permit such combinations privately
IE, the copyright holder can permit anything they want, as they own the copyright
> they also permit distribution of such combinations provided the combination is released under the same GNU GPL version. The other license is compatible with the GPL if it permits this too.
IE the license grants the ability to add the GPL license that code.
---
Taking this to the MPL example: https://www.mozilla.org/en-US/MPL/2.0/
> 1.12. “Secondary License”
> means either the GNU General Public License, Version 2.0, the GNU Lesser General Public License, Version 2.1, the GNU Affero General Public License, Version 3.0, or any later versions of those licenses.
> 3.3. Distribution of a Larger Work
> ... If the Larger Work is a combination of Covered Software with a work governed by one or more Secondary Licenses, and the Covered Software is not Incompatible With Secondary Licenses, this License permits You to additionally distribute such Covered Software under the terms of such Secondary License(s), so that the recipient of the Larger Work may, at their option, further distribute the Covered Software under the terms of either this License or such Secondary License(s).
---
The MPL 2.0 is compatible with GPL because it explicitly grants the right to release MPL code as GPL. All the copyright holders of MPL 2.0 code have authorized this secondary licensing because the license they released it as says so.
This means that in cases where compatibility matters, then the MPL2.0 code base has all the additional restrictions that the GPL has. And the GPL is _all_ code, which means it spreads out from there. If you are using GPL-2.1, MPL-2.0, and APACHE-2.0 code in the same code base, there is a violation.
> There is no such thing as a GPL compatible license
...and later on:
> MPL 2.0 is compatible with GPL
It is GPL compatible because the GPL licenses can explicitly be added to it. Adding the license requires all of the restrictions that licence brings.
So that if project A originally licensed as MIT is statically linked inside a project B licensed under the GPL then in the event that all copies of project A source code are destroied except those distributed via project B (a more likely scenario before mirror servers) then project A is now only available under GPL.
I believe that GP relies on the fact that GPL source code can only be statically linked with other GPL code and so "compatibile with GPL" means "can be relicensed under GPL" rather than "can be included as is in GPL works"
There is a lack of awareness and understanding of how this can transitively affect things accidentally.
For the record I am all for GPL code. I think the GPL is a fantastic license that has enabled great good in the world. But there are reasons why a company may not want to release code that is compatible with it.
Like if I said this comment is licensed under GFDL 12.34 and you thought GFDL 10.01 is “compatible” with it, it’s still mine to decide under what license it is licensed.
A popular phrasing found on many GPL projects are “Version 2 or later”, but that doesn’t mean you get to rewrite it to “AGPL 3 or stricter”. That’ll be a copyright violation.
you are wrong about basic gpl code linking concepts.
So, yes, Amazon can spin up as many matrix servers as they want. And so can MS. And so can Google. Maybe that wouldn't be such a horrible idea as they have mutually incompatible products that loosely overlap with the matrix feature set; those things interconnecting would be progress. Email is doing pretty OK decades after MS tried to embrace and extend via outlook and exchange. Federated communication networks are nice.
So, that's a feature not a bug.
The way you wrote it makes it sound like someone can make the project proprietary over night.
They cannot and I wish GPL people would stop pretending.
Whoever has a copy of the repo or even a snapshot of the source can continue using and developing it under the original license.
What one, strong contributor can do is make a proprietary fork and stop contributing towards the original open source one, possibly dumping prices and thereby starving the original project of code and donations.
Despite years of deployment, 90%[1] of the work is still done by paid Element employees rather than the community. Could you imagine a world where Microsoft make 90% of the effort to Linux and still tried to call it diverse?
Likewise, the vast majority (>80% anecdotally) of users on the main Matrix federated network live on a single instance centrally administered by matrix.org. Again, not a shining example of decentralisation at work.
My worry isn't about Matrix the protocol, though I think it leaves many aspects to be desired. My worry is that the fate of Matrix rests on Element Co, which seems to be a default-dead start up, repeatedly needs to seek funding, and nearly went bust in the past.
[1]: https://lobste.rs/s/emxymp/introducing_p2p_matrix#c_ilr501
The lobsters comment is from me, a year ago, talking about the spec and implementation work published by the Matrix core team - i.e. the contents of https://github.com/matrix-org. Matrix started in 2014, and the core team formed Element in 2017 to fund its work, so it should hardly be surprising that much of that code comes from Element employees. Just as if Linus had chosen to fund himself to work on the linux kernel by creating a startup, the balance of code in the kernel would be different. Nowadays I'd guess it's more like 75% of the code at github.com/matrix-org which comes from Element employees contracted to work on Matrix by the Matrix.org Foundation.
However, across the wider ecosystem, Element's contributions are an increasingly small minority. There are completely new independent implementations out there like Conduit.rs (rust server) or the whole FluffyChat stack (cross-platform flutter clients) which have almost no contributions from Element and build on entirely different codebases to the reference implementations at https://github.com/matrix-org. So, where it counts, I'd guess that Element probably does <20% of the overall code in the Matrix ecosystem?
> Likewise, the vast majority (>80% anecdotally) of users on the main Matrix federated network live on a single instance centrally administered by matrix.org.
Looking at the phonehome stats, it's more like 30%.
> My worry is that the fate of Matrix rests on Element Co, which seems to be a default-dead start up
Nope, if you read the Element blog post at https://element.io/blog/element-raises-30m-as-matrix-explode..., you'll see that Element is explicitly default-alive.
> repeatedly needs to seek funding
Nope, we didn't need to seek funding in this instance; we consciously chose to. We could have just continued profitably at a slower rate, but we wanted to go faster in order to compete with Discord & Teams etc.
> and nearly went bust in the past.
Nope, Element was formed after we lost funding for the original Matrix work... which is why we formed the company.
This is a tech chat product but the way you dig into it makes it sound like you have bones to pick with someone who came to your house and killed your cat.
Can I run my own identity server?
See also: What is an identity server?
Yes - the reference implementation is sydent and you can run your own ID server cluster that tracks 3rd party to Matrix ID mappings. This won't be very useful right now, though, and we don't recommend it.
If you want your server to participate in the global replicated Matrix ID service then please get in touch with us. Meanwhile, we are looking at ways of decentralising the 'official' Matrix identity service so that identity servers are 100% decentralised and can openly federate with each other. N.B. that you can use Matrix without ever using the identity service - it exists only to map 3rd party IDs (e.g. email addresses) to matrix IDs to aid user discovery.
It appears that the data which is collected includes [1]:
Message senders
Message senders are never encrypted
Session/device IDs
Due to Matrix's design, encrypting this would break verification
Message timestamps
It's impossible to prevent timestamps from leaking, since the server can simply note when an event is received anyway
Room members (join/leave/invite events)
Join/leave/invite and other room events are never encrypted
Message edit events
While contents are not leaked, an attacker can know when messages are edited
Message reactions
Reactions are never encrypted
Read receipts
Read receipts are never encrypted
Nicknames
Nicknames are never encrypted
Profile pictures
Profile pictures are never encrypted
The Matrix ID of users, usually including their username.
Email addresses, phone numbers of the user and their contacts.
Associations of Email, phone numbers with Matrix IDs.
Usage patterns of the user.
IP address of the user, which can give more or less precise geographical location information.
The user’s devices and system information.
The other servers that users talks to.
Room IDs, potentially identifying the Direct chat ones and the other user/server.
[0] <https://www.hackea.org/notas/matrix.html>
[1] <https://serpentsec.1337.cx/matrix>
[2] <https://www.hackea.org/notas/matrix.html#facing-the-real-and...>
All the stuff you enumerate is metadata that your server stores in order to store your conversations. Until P2P Matrix lands, if you're worried about metadata, only talk to people on servers whose admins you trust.
Congrats on your round. Best wishes for turning that into a robust truly decentralized E2EE communications platform that the average person won't shy from. Btw, I hope SNEK sticks!
Collected hashed at a identity server (you can choose) in case you decide that other people should be able to use the identity server to discover you via phone number
Those kinds of anchor clients leave me sanguine about the prospects of Matrix and Element.
As for decentralization, what the ~80% do is totally irrelevant to the other 20% of us. My company finally got off Slack (where 100% of users are trapped in a ransomware monolith) and we couldn't be happier. I federate with a couple other servers and it all Just Works.
Matrix is federated, and the way federated decentralization tends to play out involves a few big 'continents' and a vast archipelago of small instances. If you want true decentralization you have to force it with a peer-to-peer architecture, like Urbit or Secure Scuttlebutt.
Those have their place, but so does Matrix.
We only have 5 users, and we use coturn on the same machine, but three of those users are also linked to glitter and matrix.org channels/rooms. The ~/synapse directory weighs in at 5GB with 2GB of that being logs.
The setup took me a 'few hours' over two nights, but my work revolves around setting up services and software[0] - it may take someone else a couple of days to correctly set up and run it.
[0] uptime reflects the rolling nature of Gentoo, and I had a certificate update at the same time, reboots are inevitable. I start with Gentoo with any new online service, since I know the pain points and failure modes. This homeserver is run on a VM in a datacenter. I have no complaints about synapse so far.
The problem with Apache 2.0 is that it's incompatible with GPLv2. That's the main problem with copyleft licenses, they are made as if they were the only FOSS licenses in the world and just introduce incompatibilites between different camps. Apache 2.0 vs GPLv2, GPL vs CDDL, GPLv2 vs GPLv3[1]. I prefer to go with permissive licenses and save myself the headache. Regarding Apache, a common solution is dual-licensing under Apache+MIT (e.g. the default for Rust projects created with Cargo), which takes care of this problem.
[1]: And "vN or later" is not a solution, since that's just a backdoor of a random org in US.
LGPL v3 didn't make things better.
1) Element or other matrix components do not require a copy right transfer. That means Element is hard to re-license under another license than its current one.
2) The license for Element is Apache 2.0. A fine choice for any OSS project looking to maintain a healthy ecosystem of contributors for decades to come.
3) The ecosystem has a diversity of stakeholders and contributors outside of Element the company maintaining various components, integrations, etc. It's an ecosystem that already serves many millions of users.
4) Not all the Matrix components are under the Element umbrella (see 3). Element is probably dominant in this community but it's based on merit rather than ownership. E.g. the Matrix foundation is mostly run by people outside of Element. Even the Element apps have contributions from outside Element the company (see 1).
5) Decentralization is at the core of the Element sales pitch. They are unlikely to want to walk back on that; or even be able to do that without damaging their credibility. For better or worse, that's what they are selling and stuck with. And they seem successful with it too. Hence the investment.