Telegram-foss: Replace Apple's emojis & other licencing issues

Created on 9 Sep 2015  ·  112Comments  ·  Source: Telegram-FOSS-Team/Telegram-FOSS

Apple's emojis have the following copyright statement:

octocat, squirrel, shipit
Copyright (c) 2012 GitHub Inc. All rights reserved.

bowtie
Copyright (c) 2012 37signals, LLC. All rights reserved.

neckbeard
Copyright (c) 2012 Jamie Dihiansan. Creative Commons Attribution 3.0 Unported

feelsgood, finnadie, goberserk, godmode, hurtrealbad, rage 1-4, suspect
Copyright (c) 2012 id Software. All rights reserved.

trollface
Copyright (c) 2012 whynne@deviantart. All rights reserved.

All other emoji images
Copyright (c) 2012 Apple Inc. All rights reserved.

As you can see, only a small part of it is under CC. For the rest, the licence is unknown. It would be beneficial for our freedom to replace them with Google's Noto font, which is available under the Apache licence. (Besides, Apple's emojis are horribly ugly.)

Let's do something about this, for freedom's sake!

Most helpful comment

Please just respect my device's font instead of assuming you know better. Human communication is not going to crumble because you see a slightly different smiley face than I do.

All 112 comments

Freedom is a always win in my book. DO IT

Please do _not_ replace the Apple Emoji set with the Google "Noto Color Emoji" Emoji set.

Most people (or at least a lot), do not like the Google "Noto Color Emoji" Emoji set.

If you don't believe me, then maybe you should read the comments in the following two issues on the AOSP issue tracker:

https://code.google.com/p/android/issues/detail?id=69755
https://code.google.com/p/android/issues/detail?id=73248

And maybe you should also read the comments in the following XDA-Developers forum thread:

http://forum.xda-developers.com/showthread.php?t=2722892

Furthrmore, the Google "Noto Color Emoji" Emoji set looks way different than the Apple Emoji set, which can lead to the issue where Emojis can get lost in translation as described in the following article for example:

http://www.huffingtonpost.com/2014/06/27/emoji-meaning_n_5530638.html

A much better alternative for the Apple Emoji set is the open source "Emoji One" Emoji set, see:

http://emojione.com/
https://github.com/Ranks/emojione

As you can see on the following comparison page:

http://emoji.codes/family

the "Emoji One" Emoji set looks similar to the Apple Emoji set.

This is actually a design goal of Emoji One, see the following comment from an Emoji One developer:

https://github.com/Ranks/emojione/issues/68#issuecomment-93861096

The "Emoji One" Emoji set looks a heck of a lot better than the Google "Noto Color Emoji" Emoji set (IMHO) and it looks much more similar to the Apple set, which in turn would result in a much better interoperability with other Telegram clients, since most of them are using the Apple Emoji set.

And unlike the Google "Noto Color Emoji" Emoji set, the "Emoji One" Emoji set even comes with Unicode 7.0 Emojis (even including middle finger Emoji).

So, please, _if_ you replace the Emoji set, then please use the "Emoji One" Emoji set.

Please do _not_ use the Google "Noto Color Emoji" Emoji set.

Regards

Most people (or at least a lot), do not like the Google "Noto Color Emoji" Emoji set.

I don't think that is true. There are many issues at the official client's Github regarding the switch to Google Noto. Pretty much everybody in the issues agrees that Google Noto looks better.

The "Emoji One" Emoji set looks a heck of a lot better than the Google "Noto Color Emoji" Emoji set [...].

They look pretty similar to me. The only difference I see at first glance is that Noto has weird yellow bubbles instead of "real" people. That is not a bad thing though, _Noto is compliant to Unicode guidelines_: "Unicode suggests that characters with no specific mention of gender or race should be gender-neutral where possible, however the result of this on Android is these 'blob' characters." [Source]

[Furthermore], the Google "Noto Color Emoji" Emoji set [...] can lead to [issues] [...].

So I'm more for Google's Noto than Eomji One, however what I care about is freedom. If to achieve freedom I have to sacrifice beauty, I choose freedom. So if implementing Google's Noto is not possible due to technical issues, at least make it Emoji One please @dev.

@Lesik wrote:

There are many issues at the official client's Github regarding the switch to Google Noto. Pretty much everybody in the issues agrees that Google Noto looks better.

In the issues you are referring to, people basically were not really asking to switch to the Google Noto Color Emoji.

What they were asking for was to use the native system Emojis.

Because Telegram is using a built-in Emoji drawer (independent of the IME keyboard being used) and is using it's own built-in Emoji set, which consists of JPEGs, see:

https://github.com/slp/Telegram-FOSS/tree/master/TMessagesProj/src/main/assets/emoji

and which overwrite the native system Emojis.

But the native system Emojis on Android devices are not always the Google Noto Color Emojis.

Samsung has it's own Emoji set, HTC has it's own Emoji set, LG has it's own Emoji set and so on... (see http://emoji.codes/family for a comparision for example).

So people were asking to simply use the native system Emojis instead of overwriting them with a built-in set.

But I think that would be an extremely bad decision, because then every Telegram user would use and see different Emojis, which can lead to the issue were Emojis can get lost in translation as described in the following article:

http://www.huffingtonpost.com/2014/06/27/emoji-meaning_n_5530638.html

I think Emojis should be consistent across all clients and across all platforms. If I send someone a message with Emojis in it, I wanna be sure that he/she sees the very same Emojis that I am seeing.

If the clients would suddenly start to use different Emojis or would use the native system Emojis, that would really suck IMHO, since the Emojis could get lost in translation easily,

The Apple set simply is the de-facto standard for Emojis.

Many popular apps are using it across all devices/clients/platforms, to make for a consistent Emoji experience.

So, if it is not necessary, then I think the Emojis should not be changed.

But if it is really necessary, then @slp should use the open source Emoji One set IMHO, since it is the one that looks similar to the Apple set.

Another open source Emoji set which looks similar to the Apple set is the Twitter "Twemoji" Emoji set:

https://github.com/twitter/twemoji

But judging from the activity in the GitHub repository, it seems like it's currently no longer actively being maintained or nobody cares about it.

Also I think the Emoji One set looks better than the Twemoji set.

Anyway, the Emoji One or the Twemoji set would be the only alternatives for the Apple set.

The Google Noto Color Emoji set is an absolute no-go.

@Lesik wrote:

So if implementing Google's Noto is not possible due to technical issues, at least make it Emoji One please

There is no technical issue.

The issue would be that the Google Noto Color Emoji set looks way different than the Apple Emoji set, which can easily lead to the issue were Emojis can get lost in translation between different clients, as described in the following article:

http://www.huffingtonpost.com/2014/06/27/emoji-meaning_n_5530638.html

Therefore the Google Noto Color Emoji set is a no-go IMHO.

The only alternatives for the Apple set would be the open source Emoji One set or the open source Twemoji set, since those look way more similar to the Apple set.

And from those two, the Emoji One set would definitely be favorable, since it looks better than the Twemoji set, looks even more similar to the Apple set than the Twemoji set, has more Emojis than the Twemoji set and is actively being maintained by it's developers.

Regards

PS:

I might have to rectify my statement about Emoji One looking the most similar to the Apple set...

Because on the welcome page on http://emojione.com/ , Emoji One is now advertising an entirely new Emoji set ("The 2016 Collection") due to be released in November 2015 which seems to look rather different now...

Well, let's see what they have to say about it:

https://github.com/Ranks/emojione/issues/126

Regards

I wasn't aware of this issue, but definitely this is something worth fixing. Thanks for raising it.

I have no personal preference for the emoji set, both look good to me. Anyway, as a first step, I'm going to look for a way of introducing this change without increasing the maintenance costs (as you know Telegram-FOSS merges the changes from Telegram each time the later makes a release).

And probably, I'll wait until the next official release from upstream to apply this change.

@slp wrote:

Anyway, as a first step, I'm going to look for a way of introducing this change without increasing the maintenance costs

The easiest thing would probably be to simply use the native system Emojis instead. There is already a pull request which kinda deals with this, see:

https://github.com/DrKLO/Telegram/pull/625

And several other users were about to submit similar pull requests as well, see:

https://github.com/DrKLO/Telegram/issues/829
https://github.com/DrKLO/Telegram/issues/222

But please don't do that.

Using the native system Emojis would mean:

  • Telegram FOSS users with Samsung devices would see Samsung Emojis
  • Telegram FOSS users with HTC devices would see HTC Emojis
  • Telegram FOSS users with LG devices would see LG Emojis
  • Telegram FOSS users with Nexus/AOSP devices would see Google Emojis
  • Telegram FOSS users with devices running Android versions older than 4.4 KitKat would see no color Emojis at all
  • Regular Telegram users would see the built-in Apple Emojis on all devices

That would be a mess, as described in the following article:

http://www.huffingtonpost.com/2014/06/27/emoji-meaning_n_5530638.html

It would just suck.

Therefore, please don't do it.

Instead, if you really need to replace the Apple Emojis (which would be sad), then please replace the Apple JPEG Emojis:

https://github.com/slp/Telegram-FOSS/tree/master/TMessagesProj/src/main/assets/emoji

with Emoji One. Please do not use the Google Noto Color Emojis, since they simply look too different compared to the Apple Emojis.

And if you really need to replace them, it would be nice if you could use PNG instead of JPEG, as requested in the following issue over there:

https://github.com/DrKLO/Telegram/issues/914

Regards

The Apple emojis absolutely need to go purely on the basis of licensing. Regardless how many apps may use them, this emoji set is copyrighted and not under any license that allows its 3rd-party use. It is disingenuous to have a GPL-licensed FOSS app which has copyrighted unlicensed material snuck into it.

Using native emojis should be an option, but not default, because vendors have wildly different representations of emojis, and they are far from consistent. Inconsistency notwithstanding, however, there are certainly users who prefer their native options.

Emoji One seems a good candidate for a replacement, because it is similar in aesthetic to the Apple emojis, but is under an CC-BY-SA 4.0 license. My two cents are that it's best to choose a set similar to what is already in use, simply because the existing user base will be more familiar with it. It will be less of a sharp change.

@vsimonian wrote:

Using native emojis should be an option, but not default, because vendors have wildly different representations of emojis, and they are far from consistent. Inconsistency notwithstanding, however, there are certainly users who prefer their native options.

No, please, there should not be an option to allow to switch to native system Emojis.

If I send an Emoji to someone, then I want to be sure that he/she sees the same Emojis that I see.

If he/she would have the option to use different Emojis, I could no longer be sure about that.

So, I think such an option should definitely not be implemented, since it would increase the risk of the Emojis getting lost in translation as described in the following artcle:

http://www.huffingtonpost.com/2014/06/27/emoji-meaning_n_5530638.html

And that would just suck.

@vsimonian wrote:

Emoji One seems a good candidate for a replacement, because it is similar in aesthetic to the Apple emojis, but is under an CC-BY-SA 4.0 license. My two cents are that it's best to choose a set similar to what is already in use, simply because the existing user base will be more familiar with it. It will be less of a sharp change.

As already mentioned, I agree, but I'd like to repeat:

Emoji One is currently working on a brand new Emoji set, "The 2016 Collection", scheduled for a release in November 2015, which then will probably also be Unicode 8.0 compatible.

They already have some preview images for "The 2016 Collection" on their homepage and on their Instagram account, see:

http://emojione.com/
http://emojione.com/images/carousel_slide8.png
https://instagram.com/emojione/

As you can see, the new Emoji One set will no longer look like the Apple set.

But on the Telegram for Android issue tracker, I have now posted a request to @DrKLO (Telegram for Android), @zhukov (Webogram) and @telegramdesktop (Telegram Desktop) and have asked them if they could all replace the Apple set with the new Emoji One set.

That way it wouldn't really matter if the the Apple set looks different, at least not between those three clients.

Since Telegram for iOS is using Apple Emojis and Telegram for Windows Phone / Windows 10 Mobile is using Microsoft Emojis, it would be nice if the Telegram for iOS developers and the Telegram for Windows Phone / Windows 10 Mobile developers would also switch to the new Emoji One set.

But even if only the Telegram for Android, Webogram and Telegram Desktop developers would do it, it would already be nice.

Regards

PS:

Here the link to the request on the Telegram for Android issue tracker:

https://github.com/DrKLO/Telegram/issues/222#issuecomment-141660534

Regards

I get your point, but should it really be Telegram who's fixing the vendor's mistakes? It's how LG/Samsung/HTC make their phones, with inconsistent. Their choice was to f*ck up the system, why should Telegram take care of this and not them?

@Lesik wrote:

Their choice was to f*ck up the system, why should Telegram take care of this and not them?

Because the vendors probably won't...

Also, it's not like Telegram is the only messenger who uses built-in Emojis to make for a consistent Emoji experience across platforms/devices.

WhatsApp, Threema and TextSecure for example are also using Apple Emojis built-in, just like Telegram is doing it at the moment...

By the way, there is a way and even an app to change the native system Emojis, see:

http://forum.xda-developers.com/showthread.php?t=2722892

But it requres root and fiddling around with system files, which sucks.

And Google doesn't really seem to care about this issue.

There have been several requests for an option in Android to be able to switch out the native system Emojis without having to have root access and without needing to manually fiddle around with system files, see for example the following feature request on the AOSP issue tracker:

https://code.google.com/p/android/issues/detail?id=69755

As you can see, Google doesn't really seem to care.

And it looks like the upcoming Android 6.0 Marshmallow won't have such an option either...

Regards

Please just respect my device's font instead of assuming you know better. Human communication is not going to crumble because you see a slightly different smiley face than I do.

I'm sorry, wp9015362 (how do you remember your username?), but I agree with eevee. In my opinion, WhatsApp, Threema and TextSecure are bad examples which we should not follow. They do it wrong.

I can see why Google doesn't care about this issue: It took them six years to fix something as important as the permissions problem (flashlight apps wants to read my contacts? Sure thing!), so such an insignificant issue as inconsistent smileys on different devices doesn't receive too much attention. Even if they did address it, how would they solve it? Disallow vendors to change the smileys? AOSP is under the Apache licence. It's not in their power.

@eevee wrote:

Human communication is not going to crumble because you see a slightly different smiley face than I do.

Wrong.

Also, as already mentioned, it's not just about seeing different Emojis.

It's also about not being able to see Emojis at all.

Android still does not support Unicode 7.0 / 8.0 Emojis. But iOS and Windows 10 does. So if Telegram for Android would use native system Emojis and an iOS or Windows 10 Telegram user sends an Unicode 7.0 or 8.0 Emoji to a Telegram for Android user, then the Telegram for Android user will not be able to see it.

With Emojis being built into Telegram, this issue could be solved by including the Unicode 7.0 / 8.0 Emojis.

To be fair though, that hasn't happened yet. I have addressed this issue to @DrKLO over there:

https://github.com/DrKLO/Telegram/issues/986

Unfortunately he hasn't updated the built in set yet, but once he will, the issue would be solved.

Using native system Emojis would not allow to fix that.

@Lesik wrote:

Even if they did address it, how would they solve it? Disallow vendors to change the smileys?

They could at least add an option to Android to let the user change the native system Emojis, as requested over there:

https://code.google.com/p/android/issues/detail?id=69755

That way a Samsung user would not have to use Samsung Emojis if he doesn't want to. LG users would not have to use LG Emojis if they don't want. HTC users would not have to use HTC Emojis if they don't want to. Nexus/AOSP users would not have to use Google Emojis if they don't want to. And so on...

Regards

This conversation is starting to go in circles (especially if you take into account the context of this discussion having taken place elsewhere numerous times [and by that I refer to the other repos]), but it looks like the majority of everyone here would be okay with:

  1. Use Emoji One as an emoji set
    We can nitpick for days, but the Apple emojis are simply not an option because their use isn't legal. This seems to be the best compromise.
  2. Allow users to use their native emoji set
    FOSS is all about choice, not controlling communication down to a tee. Free as in beer means I should be able to choose what I see.

I think we should just vote on whether or not we want these implemented, a +1 or -1 for either option. If not the ones above, then some others that we choose to vote on. Otherwise, this could go on for perpetuity.

@vsimonian wrote:

Use Emoji One as an emoji set

+1 :+1:

Yes, that would be nice.

Ideally @DrKLO 's Telegram for Android, @zhukov 's Webogram and @telegramdesktop 's Telegram Desktop should do the same then, so that they would all use the Emoji One set.

@vsimonian wrote:

Allow users to use their native emoji set

-1 :-1:

No, that would be bad. Please don't do it.

@vsimonian :

So, where's your vote?

Regards

@wp9015362 Ah, I forgot. Good catch.

+1 - Use Emoji One as an emoji set
+1 - Allow users to use their native emoji set

+ 1 to native emojis

  • 1 Emoji One, or some other replacement for the non-free emoticons. I don't really care.

For what it's worth, I agree that using the native Emoji set is probably a bad idea. We need to ensure that there's a "standard" look-and-feel across all clients and platforms otherwise things will unavoidably (and unacceptably) get lost-in-translation.

+1 :+1: Emoji One or equivalent
-1 :-1: Native

+1 :+1: Emoji One
+1 :+1: Allow users to choose, that would be fantastic.
In case the second one is too complicated, I'd vote the first.

+1 to anything but copyrighted shit
+1 to Emoji One as a good complete set
EDIT
Emoji One has all the country flags too,including oft neglected african countries.

+1 :+1: for Emoji One or something else with a copyleft licence.
0 :zero: for an option to use built-in emojis as there are pros and cons to this decision.

+1 to not ripping off Apple
+1 to native

just a side note; TextSecure now allows the use of system emojis again: https://github.com/WhisperSystems/TextSecure/commit/e077cc658122251b1a20508841e94d2e02c00901

+1 emoji one
+1 native

+1 emoji one

  • 1 native (because this should be done in the original app. we all should be happy, @slp merges this app every time. i think its much less work to only replace some image files than merging java code.)

-1 for Emoji One, as this would be yet another application that behaves differently than any other application on a given device, creating a fragmented and inconsistent experience with the rest of the system. It would also be one of the very few app to use this set, making the matter even worse.

+1 for native, as every platform has its set of guidelines and expected interfaces that an application wanting to live in that ecosystem should strive to adhere to. It's the reason why Telegram has one (or more) native app for each platform, instead of a single standard interface for every platform. Since emojis are part of the look and feel of a system, they too, like the rest of the interface, should respect the guidelines of the system where they are used.

Let's also not forget that emojis are defined in a standard, so wildly mismatching representations (which seems to be the major reason why users are voting no on this issue) are a problem that the vendor themselves should fix, not the single applications.

Current tally, as of this comment:

| Issue | For | Against | Undecided |
| --- | --- | --- | --- |
| Use Emoji One as an emoji set | 10 | 1 | 0 |
| Allow users to use their native emoji set | 6 | 3 | 2 |

@vsimonian Sorry, I think you got my vote reversed :) Thanks

@Zelgadis87 Whoops, good catch! Fixed. :)

I've just took a look at the technical side of this issue. I'd like to share my conclusions with you:

  • Telegam can control the way emojis are displayed on messages, but can't do anything about how they are shown on the on-screen keyboard. This is not the main issue, but I think is worth mentioning.
  • Supporting native emojis is, literally, just a matter of commenting two lines of code.
  • Adding support for Emoji One (or any other emoji set) requires a significant amount of work (my estimation is 4-8 hours), as the sprite sheet changes in both disposition and resolution, so new code would be needed to properly choose the image and adjust it to the display density.

So here's the deal. Mainline has just published version 3.2.0 in the Play Store. If, by the time DrKLO's repo is updated with 3.2.0 changes, I've already finished the changes for implementing Emoji One support, Telegram-FOSS v3.2.0 will support both Emoji One and native emojis, defaulting to the first one (I will also send a pull request to mainline). If that's not the case, it will only support native emojis, and support for Emoji One will be added later.

In either case, newer versions of Telegram-FOSS will NOT include the assets identified with dubious copyright/licenses.

@slp :tada: :+1:

@slp :

Thanks for using Emoji One and thanks for going to submit a pull request to @DrKLO as well.

Much appreciated.

Some questions though:

Are you going to implement all Emojis from Emoji One?

Because Emoji One has the new Unicode 7.0 Emojis (including middle finger Emoji and so on).

Currently Telegram is not using Unicode 7.0 Emojis, see:

https://github.com/DrKLO/Telegram/issues/986

So it would be nice if you would not just replace the existing Emojis with Emoji One Emojis, but also would add all the other Emojis from Emoji One.

Also:

Are you going to use PNG instead of JPEG as requested over there:

https://github.com/DrKLO/Telegram/issues/914

?

Regards

Isn't switching out one spritesheet for another just compounding the problem. Wouldn't it be smart to make the transition to a font for platforms that support it?

Supporting native emojis is, literally, not a matter of commenting two lines of code. Don't forget the emoji keyboard in the app.

BTW, jist for reference, I've already tried this at https://github.com/Jamesits/Moegram and is fully working.

Hey guys so you know, DrKLO closed the bug tracker. Dead. Done. Boom.

@indrora I've sent Pavel Durov an e-mail, hoping for a response.

I attempted to email Telegram on this issue. It appears their system may have dumped my email because '[email protected]' does not exist.

The full text follows:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hey there telegram!

I'm a developer, but also a user of the service and I've got a few
concerns.

First, how much longer until Telegram sets up a proper GitHub
organization (or, barring GitHub, an organization in GitLab) so that
there's one centralized place for the official Telegram code? Not only
does that look a thousand or so times more professional, it means that
there's less chance of people abusing the power they've been given,
such as in the case of Telegram for Android.

Which brings me to my second point: the Telegram for Android, Webogram
and Telegram Desktop apps are technically not free software.

All politics about emoji preferences aside, the iOS/Apple Emoji are not
licensed under a free license, which means that anything licensed under
the GNU GPL (which Telegram for Android is, as is Webogram and friends)
can't legally use the iOS/Apple Emoji without being considered *non
free* software.

Some people like using the emoji from their platform. For example, I
quite enjoy the emoji that are available on my platform - android - and
that others, such as Windows Phone users would rather see their
platform's emoji.

On top of that, I've come to find out that the maintainer of Telegram
for Android is... not the person I would have spearheading my leading
application. This specific topic, of emoji choice, was brought up in a
GitHub ticket, #222 - and deliberated, including someone who included a
simple option to use different skins.

It was closed and the issue tracker destroyed by DrKLO. I am happy to
provide an archive of the GitHub's email correspondence, but it ended
with DrKLO fundamentally going "Fuck you and the horse you rode in on,
this is my project go fuck yourself."

Well, he ended the ticket with "We are pirates."

both Google and Bing have reasonable archives of the ticket:

http://webcache.googleusercontent.com/search?q=cache:HJP2MNW1cuwJ:https://github.com/DrKLO/Telegram/issues/222+&cd=1&hl=en&ct=clnk&gl=us

http://cc.bingj.com/cache.aspx?q=https%3A%2F%2Fgithub.com%2FDrKLO%2FTelegram%2Fissues%2F222&d=4617297485238623&mkt=en-US&setlang=en-US&w=7qKmCqVaZkcztC_jJicJCFjCyG27h1_h

They are unfortunately not complete.

On top of that, this isn't the first time Telegram for Android has had
to be listed as Non-free: It was listed as nonfree by F-Droid over
HockeySDK.

I'd really rather not have the Apple or anyone else who feels the
need to come along and beat people up over something frankly as stupid
as *emoji* take down telegram.

(oh wait, DrKLO already did that and made the rest of us feel very,
very unpleasant: I was going to actively work on the project, submit a
few patches here and there? I'm not and I never plan to after my
interactions with DrKLO)

I am not a lawyer, but it does look as though the use of the apple
emoji in Telegram is against Apple's stated rules:

http://www.apple.com/legal/intellectual-property/guidelinesfor3rdparties.html

> Unauthorized Use of Apple Trademarks
>
> 2. Apple Logo and Apple-owned Graphic Symbols: You may not use the
> Apple Logo or any other Apple-owned graphic symbol, logo, or icon on
> or in connection with web sites, products, packaging, manuals,
> promotional/advertising materials, or for any other purpose except
> pursuant to an express written trademark license from Apple, such as
> a reseller agreement.

the Apple Emoji are, by definition, Apple owned graphic symbols.


/s/, a concerned developer

- --
Morgan Gangwere <[email protected]>
www: http://zaibatsutel.net/
dev: http://papertape.zaibatsutel.net/
pgp: https://keybase.io/indrora/key.asc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWBimXAAoJEEURiCSotvJDp5sP/RfFFA8VZQ5ZzltBdThjhA84
3O11AXO7TfqzuAFVh19LnYRpWdmP0sy4WcJ61nPrDSJi6pdl2FPPLqR7EVNZ5Ov1
QIez8qbyQhfAKBtggDN/lOE1BqGQUW4CnFBpIQbatyLjP5gCxliHyTXgKQZBykv3
PqqrZRPLB6dNEXOUogy8IqiHiH8S5ggFgY7vA2MlITWSvV76qMsR+OCr2t7MKEUG
kmcDPHvtnhvkqaUrpdu04QZgrQF76Icwr0DXLndLTipe3lbrUmIlpnZx9bwlyx0t
VVbWDtuDufm3qzToP4nv7WU25keLTekQwHuIO5DtxaHpLwf1qkKMgNLpSvIvwkWh
xfHn/rAYeCjySlolRJzJsuKTJwLEpU78n73ZYKyNcgp6wyaR8FbL5ViuS8sDR9Br
XfReaRsgBDLiRCzSazXg/J7xpYMIsFRtah/zeqLZiSo+iKLxfrVmgFRjcYNxH3Kb
QjPJVhqRUF7J2LFA1km2wtK7WrcR48+8YskOtipJOlxZdvRcYbc3Jx4amkv6KvtC
9h8V5Fe+woLdljePy3UTYJs5Lr/Iu/m6rHCJ1SA8LTzaMfsXh4K9Mph+hqlffWtJ
ptQocaLrLYOAuS6F4DroDIMuIPCsQMXcRN0mCvDIeHzC3ZLI2qC2KMKBFQdWkFMr
dmDgv6jIoCpIL8GWUoPN
=ILK9
-----END PGP SIGNATURE-----

@indrora wrote:

Hey guys so you know, DrKLO closed the bug tracker. Dead. Done. Boom.

WTF...

@durov & @DrKLO :

Why did that happen?

Regards

_It appears their system may have dumped my email because '[email protected]' does not exist._
@indrora

Not a big surprise is it? To this day, Telegram LLP, claiming to be Berlin-based, have never had an imprint on their page to which they are _legally bound_ to by German law at the latest when they add "nonessential paid options". I assume, they do not want you to be able to contact them in a way that they would be obliged to respond.

Not responding to Github issues because one doesn't have enough time is understandable.

Completely closing all Github issues and thus muting all user feedback is not understandable. Especially since DrKLO gets paid for that. I don't think DrKLO is an appropriate developer for a project like Telegram.

@Lesik wrote:

I don't think DrKLO is an appropriate developer for a project like Telegram.

Let's be fair though, Telegram for Android is a very nice piece of software, so @DrKLO makes a good job otherwise.

@indrora wrote:

I attempted to email Telegram on this issue. It appears their system may have dumped my email because '[email protected]' does not exist.

Where do they actually claim that legal@ would exist?

Maybe you should rather have a look at:

https://telegram.org/faq#q-there-39s-illegal-content-on-telegram-how-do-i-take-it-down

where it says one should use abuse@ :wink:.

Regards

@wp9015362 wrote:

Let's be fair though, Telegram for Android is a very nice piece of software, so @DrKLO makes a good job otherwise.

I agree, it's a nice piece of software, but disabling Github issues is not OK.

@0nse -> I made sure to also cc abuse@ and info@ but mailers are bad.

@wp9015362 -> It's a common idiom among companies that a legal@ local would exist such that.. I don't know, queries about _legal_ issues would be directed at it. This is fairly common in US companies at least (Google, Apple, Facebook, etc).

As of this moment, I've discovered that I have a cache of it on my _phone_. I'll screenshot the conversation as much as I can and archive it somewhere safe.

edit: Here you go: http://imgur.com/a/Pd9uG

Technical details on replacing the iOS emojis with EmojiOne:

  • Telegram's current replacer uses a set of offsets agreed upon in EmojiSpriteMaker.whatever -- A huge chunk of Objective-C code that can only be run on OSX. This is bad.
  • My proposed solution (and someone please call me out for smoking the bad dope here) involves a set of 1x256 32x32 sprite sheets that cover the spectrum.
  • in emojiOne, there's a regex within the PHP library that defines the spectrum. I don't know if it falls back gracefully, but the best solution is to simply have a fallback image in those cases.

Worst case, we bump the size of the app +5M (to 10M of pngs) and ship a bunch of 64x64 emoji. Smashing them down to 32x32 produces 5M of PNGs. Running OptiPNG over everything trims some fat off.

Alternately, we do the Bad Thing:tm: and build something akin to what DrKLO built, except where the generator spits out something like 'emoji.dat' with the offsets for each of the emoji. This does have one distinct advantage though: Tools like OptiPNG and pngcrush can really smash those down small.

Unfortunately, WebP isn't a good option, since Android 4.2.1+ is required for transparency.

@indrora wrote:

As of this moment, I've discovered that I have a cache of it on my phone. I'll screenshot the conversation as much as I can and archive it somewhere safe.

edit: Here you go: http://imgur.com/a/Pd9uG

LOL, WTF...

Thanks for digging this up, hadn't had the chance to read it before the issue tracker was disabled.

@DrKLO wrote:

[...] All our apps has apple Emoji, so I don't see reason to change this. [... ] Telegram for Android is not the onlies our client and I will not bring inconsistency to this project. [...]

@DrKLO , how is that an argument? Then why don't you just speak to @zhukov and @telegramdesktop and ask them to also use Emoji One in Webogram and Telegram Desktop?

That should be easy for you?

If Telegram for Android, Webogram and Telegram Deskop all would be using Emoji One that would be a good start.

Yes, I realize that even then Telegram for iOS and Telegram for Mac OS X would still use Apple Emojis and that Telegram for Windows Phone/Windows Mobile would still use Microsoft Emojis, but maybe they could switch to Emoji One as well.

By the way, I have asked the Emoji One developers to overthink the design of their upcoming Emoji One 2.0 (A.K.A. "The 2016 Collection") Emoji faces once again, and look how nice they are looking now, see:

https://github.com/Ranks/emojione/issues/128#issuecomment-142392710
https://github.com/Ranks/emojione/issues/127#issuecomment-142391124
https://instagram.com/emojione/

It would be nice if you would reopen the issue tracker again.

And it would be nice if Telegram would be using the upcoming Emoji One 2.0 (A.K.A. "The 2016 Collection") Emoji set (scheduled to be released in November 2015).

That being said:

@indrora wrote:

Technical details on replacing the iOS emojis with EmojiOne:

I think it would make sense to wait until November until Emoji One 2.0 (A.K.A. "The 2016 Collection") has been released before implementing Emoji One into Telegram.

It's a brand new set (see above). So if you are implementing Emoji One 1.5 now and 2.0 will be released in one or two months, then you would need to update the entire set again. So, I'd say it would make more sense to wait for 2.0 to come out.

But if it is no problem for you to integrate 1.5 first and then update to 2.0, that would be nice as well of course.

Regards

@wp9015362 -> That's more of an argument for building a generator that's easy to extend!

@indrora wrote:

That's more of an argument for building a generator that's easy to extend!

I see.

By the way, one thing that hasn't been mentioned by you yet is, that the built-in Emoji keyboard of Telegram for Android also is still missing the skin tone modifier feature.

WhatsApp for Android has it now, see:

http://www.androidpolice.com/2015/06/30/live-long-and-prosper-whatsapp-adds-skin-tone-emojis-and-spock-vulcan-salute-on-android/

Telegram-FOSS/Telegram for Android should also get it, because the new Emoji One 2.0 set probably will have the diversity Emojis.

I guess @DrKLO will implement that anyway, since he said that he is planning to update the Emoji set to the new iOS 9.1 release anyway, but who knows what's really going to happen from now on, now that even the issue tracker has been disabled...

So, just saying...

Regards

@Jamesits Yup, you're right, I've adopted your approach for EmojiView: https://github.com/slp/Telegram-FOSS/commit/03771b0cb2a4f18486c66887466551d424e4c9c0

@indrora Thanks for the analysis :+1:

I'm going to say we should change the title of the ticket to "Fix the licensing problems".

It appears that Telegram LLC / DrKLO are violating more than just the GPL, but also taking a nice warm :hankey: all over the Apache License, and potentially many, many others.

It looks like there is uncredited code from

  • the Xiph.org foundation
  • Google (multiple licenses)
  • Skype
  • Odysseus Software GmbH
  • Google AOSP
  • Octastic, Inc
  • Parrot (formerly Skype)
  • Erik De Castro Lopo (float_cast.h)
  • "The LibYuv Project Authors"
  • ESR/Eric S. Raymond (giflib) / Google
  • The Chromium Authors
  • Unicode, Inc.
  • Eric A. Young / Boringssl
  • "Telegram"

These are just some that I've dredged up, and probably most of them can be boiled down to a greater library -- in /TMessagesProj/jni there's a few libraries that stand out:

  • GIFLIB - That's Eric S. Raymond and friends.
  • libwebp - Owned by the WebM project.
  • Breakpad -- Mozilla's crash reporting library.
  • libjpeg - Owned by the libjpeg authors.
  • libyuv - custom license, looks apache2/BSD ish.
  • Opus - BSD license.
  • SQLite - Mixed license.

The reasoning for having these included is sketchy at best, given that Android has included much of these since 4.0. Some I can understand, but others are silly, such as Giflib.

The problem is that many of these libraries include a pair of clauses such as these, from libyuv:

  * Redistributions of source code must retain the above copyright
    notice, this list of conditions and the following disclaimer.

  * Redistributions in binary form must reproduce the above copyright
    notice, this list of conditions and the following disclaimer in
    the documentation and/or other materials provided with the
    distribution.

I must (voluntarily) not contribute (except possibly to fix this). Telegram is violating licenses left and right. Note that this is _only_ in the JNI block - this does not include cases of mangling the namespace in code owned by other groups to make it fit into org.telegram

DO YOU WANT LAWYERS? BECAUSE THAT'S HOW YOU GET LAWYERS

@indrora Sounds like this stuff should go into a new issue.

@indrora I haven't looked into it, but being sincere, it doesn't surprise me at all.

@vsimonian Yes, I agree with you, we should keep track of this in another issue.

The main problem here, is that Telegram-FOSS is intended to be a low maintenance, close-as-possible fork of Telegram. Obviously, this problem needs to be addressed, or the whole "-FOSS" thing wouldn't make any sense, but it should be in way that doesn't compromise future upstream merges.

BTW, I've just tagged version 3.2.2 of Telegram-FOSS. I've removed the offending assets, and implemented a fall back to native emojis (EmojiOne will have to wait for next release), among other, minor changes (like removing HockeyApp references once again).

I'm going to keep this issue open until support for EmojiOne assets is implemented.

P.D: I've just added a "Donate" section to README.md. If you like the work I'm doing, please consider buying me a beer ;-)

@slp Frankly, the biggest problem is that @DrKLO / Telegram have basically said that they don't care about transparency/openness/free-software. The closing of the bug tracker, erasing of history - that's a knife in the coffin of Telegram as a FOSS application in any sense of the word.

I'll consider working on EmojiOne once they have 2.0 out. Maybe.

Maybe DrKLO is just doing what he's told to...

Anyway, I came by to ask if there's any way to get an apk of this app, it seems great and I'd like to use it but I couldn't find any package out there. I know this is not the right place to ask for it because it's unrelated to the emoji issue, but... I didn't want to create a new issue just for this, and I'd love to try the EmojiOne icons in Telegram :yum:

Great work with this fork, guys, congrats!

Well, the EmojiOne emojis aren't in there yet. But you can find an apk on the fdroid site: https://f-droid.org/repository/browse/?fdid=org.telegram.messenger

Note, that it is strongly recommended to install fdroid and get the apk through that. So you will get update notifications.

Oooh didn't know that the F-Droid package was this one! I thought it was the official one. Great, guys! Thanks!

I agree that this emoji discussion is closely related to the whole licencing "dilemma". All of us here want this code to be free software. Thus the issue title is changed and we may discuss other freedom deficits this app might have.

@Ecron Whoa whoa, that is so off-topic...
But good point about DrKLO. Usually it's not helping to find the "bad guy", but in this case I'm really interested in whether DrKLO is just an asshole developer who doesn't credit other's work and mutes user feedback, or if it's the whole Telegram "headquarters" that are anti-freedom. Should the latter be true, I might consider a more freedom-respecting service for communication.

I've found fragments of other people's libraries. I've contacted the author of android-gif-drawable ( @koral-- ) mentioning this and directed them to this ticket.

After stripping out emoji.java a whole instance of libjpeg can be torn out completely. yes, @DrKLO used _an entire copy of libjpeg_ to mask them into ARGB888 slices.

Go with the freedom option. Is a license being violated here?

I really would like to have an option to switch between Emoji-sets. Googles set is soo ugly in my opinion :/

@deavmi Yes. Apple's, at the least and the licenses for several open source libraries that are being used.

Oh oaky, well then remove all of the stuff tof which license's is being violated.

@deavmi This accurately describes "just remove all the stuff"

boom.

Freedom should take precedence for all decisions.

Yes @Allanitomwesh :+1:

@indrora what do expect from me?

@koral-- Just to confirm that you've got code in this monstrosity that's been re-appropriated by Telegram.

to the rest in this thread: @koral-- wrote android-gif-drawable which was mangled and thrown in as gif.c in the JNI library.

@slp i would appreciate if you implement a full instance of EmojiOne,if possible,,as it has some very nice emojis in there that aren't currently in telegram.
@indora just curious,and OT, Since TG's servers aren't open,what would it take to move TG FOSS to open ones and maintain compatibility?

@indrora I know its like "Well it's easy to say but to do it." Well it's the only advice I will give.

"Freedom should take precedence for all decisions. " ~ Allanitomwesh

Best quote ever. I would make a GitHub page for this.

@slp before I post a totally new issue,is something wrong with links,hashtags and slashes in the latest update on F-Droid? They aren't turning blue for me or expanding to show previews

I confirm the behaviour mentioned by Allanitomwesh.

If this is the case then there is probably code that is not being included in the batches from @DrKLO -- creating all sorts of issues.

Hi,
from Telegram-FOSS 3.2.2 I no longer see emojii.
Is there an external package I should install?
However, if there aren't security issue, can I continue to use Telegram-FOSS 3.1.3?
Thanks and sorry if you've already explained.

@vaskas at this point, I'm not going to trust a 5 year old post to an ML, and instead will definitely fall back on what apple's official IP statement is.

Which is, to put it bluntly

I absolutely want to second indrora'S comment from 2 days ago

Removing the emoji without having an appropriate (read "equally good") replacement was a bad bad idea.

FOSS is a great concept, but where the quest for freedom renders the product partially unusable (and that is the case with the ugly black and white system-base emojis on an android device, you can't tell them apart) ...

... it's not a goer!

My advice: If you want to change something that works for reasons of ideology ... that's fine but ... think it through first.

Im curious: Is it hard to add EmojiOne to Telegram?

@Ceeee I disagree. The point of _this_ repository is to provide a free version of Telegram. Freedom certainly has priority over smileys in _this_ repository (in my experience only few people use them anyways). For people who care about smileys more than freedom there is the official repository (https://github.com/DrKLO/Telegram).

It's as if you were complaining that Trisquel or gNewSense or another _free_ distro (just like this is a repo for a _free_ version of Telegram) removed proprietary Nvidia drivers from their repository. It renders some graphic cards partially unusable (and that is the case with the screen tearing and horrible FPS). It's not a goer!

@Lesik Man, please, don't be so radical. Freedom can coexist with a well designed app. I vote for adding the EmojiOne or Phantom emoji sets to this app, as they are FREE, and adding an option to use fallback emoji system. Is that so hard? :)

@Lesik YMMV, some people use Emoji a lot, tastes differ too. Why choose between freedom and UX when you can have both? Telegram-FOSS can set a great example by adopting EmojiOne. Just as it did by removing a dependency on GMS without sacrificing usability. Ultimately though Telegram is just a step in the right direction: it still relies on non-free server software.

What, radical? I'm totally fine with people who don't care about freedom. Those should please go here: https://github.com/DrKLO/Telegram

Surely a free replacement is a good idea. What I said in my comment, and what was apparently misunderstood, is that keeping Apple's emojis with the reasoning "it renders the product partially unusable" is unacceptable.

About the "server uses proprietary software": That is not in our hand to change. Removing Apple's emojis is. We may not achieve total freedom, but doing everything that's in out hands is the direction towards freedom.

I agree with @Lesik. The focus on freedom is what differs this version from DrKLO's version. Same applies to Fennec and Firefox. If you don't like the one, use the other.

As I understand it, no one is _opposed_ to adding Emoji One support to this project; it's just a nontrivial change and was deemed less immediately important than not ripping off Apple. So not sure why there's an argument here at all :)

So, we all agree! :grin: Let's switch to EmojiOne and make everybody happy! Hahaha :smile:

My proposal: Use EmojiOne set and add an option to use system's set. So everybody gets what they want.

Thats a good Idea. I agree.

Stop agreeing, start programming. Simply coming to an agreement doesn't _really_ speed things up. You shouldn't expect @slp to bring this change immediately; if you want to get it in faster, help by writing code - not discussing. (Although I can't really talk, as I know nothing about Java)

@indrora wrote:

@vaskas wrote:

Also FYI https://groups.google.com/forum/#!topic/emoji4unicode-fontdesign/eqY3_p_ET8E

@vaskas at this point, I'm not going to trust a 5 year old post to an ML, and instead will definitely fall back on what apple's official IP statement is.

FYI:

http://stackoverflow.com/a/22949517

:wink:

@Ecron wrote:

Let's switch to EmojiOne and make everybody happy!

Yes, but let's wait until next month when Emoji One 2.0 (A.K.A. "The 2016 Collection") is supposed to be released. It's a brand new Emoji set and looks even better than the current Emoji One 1.5, see:

https://instagram.com/emojione/

Since it is supposed to be released next month (November), I'd say it would make sense to wait until it has been released.

It would be really nice if Telegram-FOSS would get Emoji One 2.0 when Emoji One 2.0 is being released.

Regards

Slp said he'd add EmojiOne in a future update,but removed Apple's copyright emojis in the current update. Not sure where the issue is here? How about a little patience? Also,Lesik is totally right,convenience is not a reason to sacrifice freedom.

Hehehe you all are right. I wish I knew how to code it to help implementing it, but I'm a mere user. And it makes sense to wait until EmojiOne2.0 is released. As Allanitomwesh just said, let's be patients.

What about the other licensing issues?

I just noticed in the stock emoji commit that the lowest Android SDK was raised to 10 (Android 2.3.3). It's not such a big problem, but still a problem. According to Google these are <4% of all Android devices, but keep in mind that Google only counts the devices that have Google Play Services installed. Before the ICS era many (Chinese) manufacturers flooded the market with cheap phones which have not been certified for Google Play Services and thus are not counted in this statistic. The users of these devices rely on third-party stores like F-Droid, which contain Telegram versions like this one. Just to keep in mind.

@Lesik: That seems to be because of the TextDrawable library used for drawing the emoji keyboard with native emojis. I think the minSDK can be lowered again when we have the emoji One emojis.

(You could open a separate issue so that we can keep track of this.)

I started working on the emoji One emojis. I'll put up a first prototype by tomorrow. (Edit.: see PR)
A few things will still need to be done:

  • Implement the option to allow switching emojis.
  • Give attribution to emojiOne somewhere in Settings
  • Test everything with different screen sizes/resolutions/dpi
  • Maybe: Speed up emoji loading with native code?

@Lesik I was told Telegram will drop support to Android < 4.x soon... "Soon" can be at the end of the year or the next one. It's a rumor though, but it's worth to know.

@Bubu Awesome, I gladly help you testing and anything else that doesn't require deep coding knowlegde.

@Bubu how about right under where it says the telegram version at the bottom of settings? You could add the attribution there?

This discussion is comedy gold. Thanks, guys. :joy:

Thanks everyone for your work and for making a cleaner project.
Is there a thread or issue where the licensing issues @indrora listed are discussed? I would also like to tell Telegram that (1) I am worried free licenses are being violated and (2) the fact that the development is not more transparent makes me question their claims about openness and privacy.

I've been analyzing a bit the licensing issue, and I think this problem has been somewhat magnified. Let's see the facts:

  1. Telegram includes third party software, mostly covered by a variety of FOSS licences.
  2. Each piece of third party software, in source form, should include its respective license.
  3. Some of those licenses require keeping a copyright mention on binary distributions.
  4. The OpenSSL license is GPL-incompatible.

And the implications:

  1. Not a problem. Some of these dependencies can be removed, but it's probably not worth the effort.
  2. Easily fixable, just import the respective LICENSE files.
  3. Though this is not explicitly mentioned anywhere, it's common knowledge that if a binary distribution contains a reference to its corresponding sources, the requirement to include a mention in the binary can be ignored (there're _hundreds_ of software out there that doesn't include such mentions, just look at your favorite GNU/Linux distro).
  4. This is something that @DrKLO can easily fix, just using a GPL variant with the OpenSSL exception (https://people.gnome.org/~markmc/openssl-and-the-gpl.html).

I hope this helps to clarify the license situation for both Telegram and Telagram-FOSS.

Now let's work on the real issues ;-)

For the record:

The upstream version of Telegram for Android now has all the new Apple Emojis:

http://blog.emojipedia.org/ios-9-1-emoji-changelog/

Regards

PS:

The upstream version of Telegram for Android now also supports the skin tone modifier feature. In the Emoji drawer you can now tap and hold an Emoji and a selection for the skin tone will come up.

Regards

Does the EmojiOne set also support skintone modifiers?

@vanitasvitae wrote:

Does the EmojiOne set also support skintone modifiers?

Emoji One 1.5.1 (the current version of Emoji One) does not support the skin tone modifier feature.

But the brand new version 2.0, which is scheduled to be released in November 2015, will support it, see:

https://instagram.com/emojione/

Regards

For the record:

It looks like Android now natively supports SVGs (since Lollipop), see:

https://github.com/connectbot/connectbot/pull/321#issuecomment-150282928

:smiley:

So the JPEG Emojis could be replaced with SVGs now :smiley:?

Regards

Potentially.

I just wanted to ask, how far the integration of EmojiOne has been done. How much work is still to do?

I didn't have time to work on this since the last update here:
https://github.com/slp/Telegram-FOSS/issues/50

Basically the option to switch emojis is missing; and testing.
Additionally I need to adjust this to the new version.

Regarding third party library licenses:
There seems to be progress upstream. Most (all?) licenses have been added:

    new file:   TMessagesProj/jni/breakpad/LICENSE
    new file:   TMessagesProj/jni/giflib/COPYING
    new file:   TMessagesProj/jni/libjpeg/NOTICE
    new file:   TMessagesProj/jni/libwebp/AUTHORS
    new file:   TMessagesProj/jni/libwebp/COPYING
    new file:   TMessagesProj/jni/libwebp/PATENTS
    new file:   TMessagesProj/jni/libyuv/AUTHORS
    new file:   TMessagesProj/jni/libyuv/LICENSE
    new file:   TMessagesProj/jni/libyuv/LICENSE_THIRD_PARTY
    new file:   TMessagesProj/jni/libyuv/PATENTS
    new file:   TMessagesProj/jni/opus/AUTHORS
    new file:   TMessagesProj/jni/opus/COPYING

@Bubu Yup, for me, this issue can be closed.

Don't know if this satisfies the requirements of "distributions in binary form" --

Was this page helpful?
0 / 5 - 0 ratings

Related issues

seniorm0ment picture seniorm0ment  ·  5Comments

JimmyS83 picture JimmyS83  ·  5Comments

joeftiger picture joeftiger  ·  4Comments

jeroen7s picture jeroen7s  ·  6Comments

batzuli picture batzuli  ·  4Comments