Skip to content

Legal thoughts and Threema's business model

Moritz Stückler edited this page Jun 26, 2022 · 4 revisions

We're big fans of Threema. We've used this messenger for many years, and still think it's a great choice for many purposes. We also applaud the fact that Threema chose to open source their client applications. That's a bold and idealistic decision. And we understand how hard it is to find sustainable business models for Open Source projects. So with our Matrix bridge, we do not want to hurt Threema by driving away customers or reducing their revenue in any way.

However, despite being Open Source, Threema still is a little bit of a walled garden for private customers. Threema is lacking the ecosystem and interfacing possibilities that some of the alternatives like Telegram and Signal offer and we want to change that. We are fully aware that we will still be using Threemas server infrastructure, and it's only appropriate to pay for this usage.

So for the architecture of our bridge solution, there's basically two different routes we can take:

Client mode

We can look at most parts of their client code and reverse engineer it and/or use existing Threema client implementations like o3 and ceema, which already did this. The bridge would behave like a regular client app. To use it, a bridge user would have to buy a regular Threema license (through their own shop and enter the license key into the bridge. Threema says, that it allows the usage of self compiled clients on their website (under the "License" headline of their Open Source Page. To use the bridge for personal relaying use would probably be fine in this setting. However the bridge could still be used for automation purposes, which might break Threemas terms & services and could potentially lead to Threema banning bridge users.

Good:

  • Pay a one time flat rate license fee (3,99 Euro)

Bad:

  • Might break terms & services, when used for automation (Threema might ban your account)

Gateway Mode

The other solution would be to use Threemas official "Gateway API" product. This is a paid API product which explicitly allows automation use. However this API has a usage based pricing model. So not only do you need to pay a rather steep one-time setup fee of around 60 Euro (and go through a multi-step signup process with manual verification), but even after that you will be billed for every message that you send to the API. Meaning that every message going from Matrix to Threema will cost you money. Imagine you're part of a big chat group, then your bill could ramp up very quickly (for regular text messages they charge about 0,02 Euro). This seems like a fair business model for companies, but for small and private users (which is who we're targeting with Threematrix) this is a huge dealbreaker.

Good:

  • Automations use in accordance with Threemas terms & services

Bad:

  • Expensive and usage based fees

Conclusion

Because we are only passionate open source developers, we do not want to get into any kind of legal dispute with Threema. Which is why we will be starting our development efforts with the "Gateway" approach. This seems like a good task to familiarize ourselves with both technology worlds (Threema and Matrix). And maybe we can build some good will and when we have something to show, we can contact Threema and see if we can get their blessing for the "Client approach", too.

We're looking forward to get your feedback on this topic. Please feel free to join the discussion.