8 ms·

A few key differences with other OSS companies that IMHO are positive: 1) Element or other matrix components do not require a copy right transfer. That means E

A few key differences with other OSS companies that IMHO are positive: 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.

j1elo 5y ago
> 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. 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.
- nwellnhof 5y ago
  If you contribute to a project under a non-copyleft license (MIT, BSD, APLv2), even without copyright assignment anyone can use your code for proprietary, closed-source projects without asking for permission. There's no need to relicense since the original license is permissive enough. So your argument only applies to copyleft licenses.
  - j1elo 5y ago
    Yep, I went for a coffee and realized that. But this is a consequence of the simplistic summary, as I warned. As everything, the devil is in the details! 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)
    - richardwhiuk 5y ago
      What do you mean by "kept with the original license"?
      - Proven 5y ago
        He means you couldn't relicense under another license. I think if the copyright is yours then you could.
      - pininja 5y ago
        The proprietary+forked code would become a mix of closed and open source license, but just never get released so you’d never be able to get ahold of it.
      - jcelerier 5y ago
        If you make a MIT project "Foo", not protected by a CLA and I contribute to it, then if your company uses Foo in a proprietary product they still have to give the attribution for my code as required by the MIT license, as my code will still remain MIT even if embedded in a larger non-MIT project. 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.
abstractbeliefs 5y ago
I fully believe that Element want Matrix to be decentralised and diverse, but I don't think it's actually true. 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 https://lobste.rs/s/emxymp/introducing_p2p_matrix#c_ilr501
- Arathorn 5y ago
  Lots of confusion here. 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 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 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-explodes/ 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.
glogla 5y ago
Does Apache 2.0 license protect from Embrace, Extend, Extinguish (Microsoft) or from Embrace, SaaS, Tax (AWS and the like) in any way?
- goodpoint 5y ago
  No. Like BSD and MIT it cannot protect from prorietization, tivoization and SaaS. You need GPLv3 or AGPL for that.
  - whimsicalism 5y ago
    Gplv3 doesn't protect against saas
    - goodpoint 5y ago
      That's why I wrote AGPL in the sentence.
      - whimsicalism 5y ago
        Yes, but your sentence suggests either of those would be protective against all of the former.
  - skinkestek 5y ago
    It is a bit more nuanced than that: 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.
- jillesvangurp 5y ago
  Together with the lack of copyright transfers, it just guarantees the code will always be available under the same license. There can't be any re-licensing of existing code without twisting the arms of every single copyright holder. No more, no less. It gives nobody an exclusive control point. It gives nobody exclusive rights to exploit. 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.
yakubin 5y ago
> 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. 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.
- glandium 5y ago
  Don't forget the LGPL, which, in its attempt to allow proprietary software to use LGPLed code with conditions, makes it painful to use LGPLed code in free software licensed under anything other than the GPL.
  - tardyp 5y ago
    Can you elaborate? This does not make sense to me
    - glandium 5y ago
      See LGPL v2.1 section 7. It's annoying to comply with. Section 6 too. 7a was clearly designed for proprietary software. It would be a problem with the GPL too if section 3 wasn't there. LGPL v3 didn't make things better.
- trasz 5y ago
  The problem isn't with copyleft licenses, only with GPL (in its various variations). You don't get license incompatibility problems with other copyleft licenses, eg MPL; you need GPL for that.
maxme3 5y ago
The MPL v2 license would be a better choice. It offers the same kind of terms and it explicitly compatible with the GPL licenses.
- georgyo 5y ago
  There is no such thing as a GPL compatible license. The GPL is only compatible with GPL. 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.
  - marcosdumay 5y ago
    Well, the bundle is GPL, the particular code is still MPL, so that you can still take that portion away from the bundle and do anything that the MPL allows.
  - deleted 5y ago
    [deleted]
  - goodpoint 5y ago
    > There is no such thing as a GPL compatible license 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.
    - georgyo 5y ago
      I don't think you are correct here: https://www.gnu.org/licenses/gpl-faq.en.html#WhatDoesCompatMean https://www.gnu.org/licenses/gpl-faq.en.html#WhatDoesCompatM... > 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/ 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.

j1elo 5y ago

> 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. 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.

nwellnhof 5y ago
If you contribute to a project under a non-copyleft license (MIT, BSD, APLv2), even without copyright assignment anyone can use your code for proprietary, closed-source projects without asking for permission. There's no need to relicense since the original license is permissive enough. So your argument only applies to copyleft licenses.
- j1elo 5y ago
  Yep, I went for a coffee and realized that. But this is a consequence of the simplistic summary, as I warned. As everything, the devil is in the details! 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)
  - richardwhiuk 5y ago
    What do you mean by "kept with the original license"?
    - Proven 5y ago
      He means you couldn't relicense under another license. I think if the copyright is yours then you could.
    - pininja 5y ago
      The proprietary+forked code would become a mix of closed and open source license, but just never get released so you’d never be able to get ahold of it.
    - jcelerier 5y ago
      If you make a MIT project "Foo", not protected by a CLA and I contribute to it, then if your company uses Foo in a proprietary product they still have to give the attribution for my code as required by the MIT license, as my code will still remain MIT even if embedded in a larger non-MIT project. 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.

abstractbeliefs 5y ago

I fully believe that Element want Matrix to be decentralised and diverse, but I don't think it's actually true. 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 https://lobste.rs/s/emxymp/introducing_p2p_matrix#c_ilr501

Arathorn 5y ago
Lots of confusion here. 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 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 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-explodes/ 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.

glogla 5y ago

Does Apache 2.0 license protect from Embrace, Extend, Extinguish (Microsoft) or from Embrace, SaaS, Tax (AWS and the like) in any way?

goodpoint 5y ago
No. Like BSD and MIT it cannot protect from prorietization, tivoization and SaaS. You need GPLv3 or AGPL for that.
- whimsicalism 5y ago
  Gplv3 doesn't protect against saas
  - goodpoint 5y ago
    That's why I wrote AGPL in the sentence.
    - whimsicalism 5y ago
      Yes, but your sentence suggests either of those would be protective against all of the former.
- skinkestek 5y ago
  It is a bit more nuanced than that: 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.
jillesvangurp 5y ago
Together with the lack of copyright transfers, it just guarantees the code will always be available under the same license. There can't be any re-licensing of existing code without twisting the arms of every single copyright holder. No more, no less. It gives nobody an exclusive control point. It gives nobody exclusive rights to exploit. 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.

yakubin 5y ago

> 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. 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.

glandium 5y ago
Don't forget the LGPL, which, in its attempt to allow proprietary software to use LGPLed code with conditions, makes it painful to use LGPLed code in free software licensed under anything other than the GPL.
- tardyp 5y ago
  Can you elaborate? This does not make sense to me
  - glandium 5y ago
    See LGPL v2.1 section 7. It's annoying to comply with. Section 6 too. 7a was clearly designed for proprietary software. It would be a problem with the GPL too if section 3 wasn't there. LGPL v3 didn't make things better.
trasz 5y ago
The problem isn't with copyleft licenses, only with GPL (in its various variations). You don't get license incompatibility problems with other copyleft licenses, eg MPL; you need GPL for that.

maxme3 5y ago

The MPL v2 license would be a better choice. It offers the same kind of terms and it explicitly compatible with the GPL licenses.

georgyo 5y ago
There is no such thing as a GPL compatible license. The GPL is only compatible with GPL. 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.
- marcosdumay 5y ago
  Well, the bundle is GPL, the particular code is still MPL, so that you can still take that portion away from the bundle and do anything that the MPL allows.
- deleted 5y ago
  [deleted]
- goodpoint 5y ago
  > There is no such thing as a GPL compatible license 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.
  - georgyo 5y ago
    I don't think you are correct here: https://www.gnu.org/licenses/gpl-faq.en.html#WhatDoesCompatMean https://www.gnu.org/licenses/gpl-faq.en.html#WhatDoesCompatM... > 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/ 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.