Ubuntu touch app

Hi, I’m currently working on an app for Ubuntu Touch. I have some questions, for example regarding app name and icon. Is it possible to use the name “Delta Chat” and the official icon? Who would be the correct contact for such questions?


If it’s an open source project and your goal is to make it an official release that some point and merge it into our GitHub organisation, then it’s ok to use the trademark, but you could also invent some other name like @adbenitez did with his android fork “DeltaLab” whose icon is a remixed version of the deltachat icon. And once your ubuntu touch app becomes “official”, we can change it to the official name and icon.

We don’t have strict trademark rules yet, I tried to start a list back sometime at FAQ entry on releasing a fork of deltachat · Issue #359 · deltachat/deltachat-pages · GitHub

But as you are not an asset flipping publisher that wants to sell delta chat for money without putting in any own work, there shouldn’t be any problems using the trademark in this case.

What tech stack are you using? is there already a repo and/or some screenshots to share?

1 Like

Yes, it’s open source (GPLv3). I plan to publish it in the OpenStore and won’t make any money with it, i.e. I won’t even put a donate link (maybe a note directing those that want to donate to the UBports and DeltaChat donation pages). Your suggestion to use some other name and a remixed logo in the beginning sounds good, though. I thought of “DeltaTouch” before, so looking at “DeltaLab”, this name would be fine for now? Making it an official release may be a goal, but it’s a long way to go until then.

The app is based on C++/Qt/QML. No repo yet, mainly because I am not sure how to deal with certain license topics. The layout is heavily inspired by the Ubuntu Touch version of FluffyChat. I also took some (GPL’ed) code snippets from here and there. And libdeltachat.so would be lying around pre-compiled for armhf, x86_64 and aarch64. The aim is to fulfil legal requirements and give credit where credit’s due (any help here would be greatly appreciated).

Some screenshots:


sure I think that name is fine.

delta chat core is licensed MPL2, the android and the desktop client are licensed GPL3. Depending on what libraries you are using you could just also use GPL3.

1 Like

wow, that looks very nice - and it looks already quite usable :slight_smile:

1 Like

Ok, thank you. I’ll see to push it to a repo soon.

Thanks :blush:

@lk108 great! that looks nice and promising!

tip: for the “Unknown message type” you can actually use the message summary, Delta Chat always have a text representation for messages so if your app doesn’t support image attachments yet, the message will look like “Image - hey, look at this flower” which is good enough for an start instead of a “unsupported message type” placeholder

1 Like

Thank you for the tip! Looks much better with it. But it’s really time to implement the image viewer :smiling_face:

1 Like

you could also just check for the filename property for unknown messages types and provide link/button to open path externally + message text

1 Like

Sounds good. I’ll implement this once I’ve learned how to deal with the “content hub” of Ubuntu Touch.

1 Like

I don’t have Ubuntu Touch, but would like to look into the source code, especially since it is written in QML. I made a Kirigami2 client ~link2xt/kdeltachat - sourcehut git, it is functional and I use it sometimes, but it is not actively developed at the moment. Maybe at least some C++ parts can be shared or we can make a single convergent QML app for all kinds of mobile Linux. There is a related thread at Native Client for Linux based mobile OS - #19 by link2xt

Wrt. licensing if you intend to publish as GPLv3, see how it is done in ~link2xt/kdeltachat - sourcehut git. I think it’s a good idea to have an explicit OpenSSL exception because its compatibility to GPLv3 is sometimes questioned and boils down to whether you can consider OpenSSL a “System Library”. The “GPL-3+ with OpenSSL exception” is also what Kaidan application does in LICENSE · master · Network / Kaidan · GitLab

1 Like

Thanks for the hint regarding the OpenSSL exception. I hesitated to upload because although Simon told me that it’s ok to use GPLv3, I came across this gnu.org page which states that I would have to use AGPLv3 instead of a pure GPLv3 when linking to MPL2. So it seems to me that the GNU people think that the exception would have to include deltachat-core, too, or am I misunderstanding something?

I am wondering about the consequences if i just put these exceptions into the license - would it block re-using pure GPLv3 code from other projects?

Once I’m clear about the license issue, I am ready to upload. It’s still under heavy development, though, so the app is not really functional yet. And I have to admit that I’m a little bit afraid that the quality of my code will disappoint as I am just a hobby programmer and very inexperienced.

That said, your suggestion to share C++ parts or even make a single convergent app sounds good! The latter might require quite some effort, but why not work in this direction.

The page says “This is a free software license. Section 3.3 provides indirect compatibility between this license and the GNU GPL version 2.0, the GNU LGPL version 2.1, the GNU AGPL version 3, and all later versions of those licenses.” This means you can use GPLv2, GPLv2+, GPLv3, GPLv3+ etc. You can just license with GPLv3+ as a license, it is compatible according to the page.

I decided to use GPLv3+ with an explicit OpenSSL exception, because Delta Chat core has an option to be linked to OpenSSL and OpenSSL has a GPL-incompatible license. GPL explicitly allows to link even to proprietary “system libraries” (e.g. linking to proprietary Windows API is fine for a GPL program), but whether to consider OpenSSL a system library is not obvious. Most Linux distributions, e.g. Debian, consider it to be acceptable, but adding an explicit exception avoids such questions.

No, it would not block anything. If you combine GPLv3+ code that you wrote with some GPLv3+ code from the other project, you can only provide OpenSSL exception for the code you wrote, but it is still arguably better than not providing such an exception at all. If someone is concerned about whether OpenSSL is a “system library”, they can remove/rewrite GPLv3+ code that does not have OpenSSL exception.

See license compatibility - GPL V3 with OpenSSL Exception - Open Source Stack Exchange, OpenSSL exception is a fairly standard thing to do.

It’s also fine to upload without a license at all until you decide, in this case it’s effectively a proprietary software until you allow others to use it :slight_smile:


Alright then, here we go:


Finally, we have an Ubuntu Touch app ready for using. Thanks so much for that. Can you push this app to the OpenStore?


Successfully build the app and run it on a Google Pixel 3a powered by UT 20.04. Backup import from Android app works flawlessly.

If you need a beta tester - here I am :slight_smile:


Oh wow, that’s great. None of my devices has been ported to 20.04 yet, so I wasn’t able to test it on 20.04. And I thought that coming from 16.04, some changes are necessary to make it run on 20.04. I’m pleasantly surprised that it works.

Much of the functionality is already there, but some things I consider critical for an official release are still missing, so the upload to the OpenStore is still at least a few weeks away.

It would be very cool to have you as beta tester :slight_smile: I will DM you.


@lk108 How hard would it be to adapt the app to also work on any regular Linux distro?

1 Like

I think the app is quite specific due to Ubuntu Touch’s content hub, confinement policy etc. If you want an alternative to the regular DC Linux client, maybe you can take a look at kdeltachat by @link2xt, see one of the posts above dated Jan 22.

1 Like