Make Telegram code FOSS friendly

[slp]

Hi,

Current Telegram code depends on non-free services and contains binary blobs, so it doesn't qualify as Free Software attending to some criteria. These changes try to address this issue:

• Remove binary blobs from repo.
• Create two Gradle flavours, "standard" and "foss". The first one builds Telegram with Google Play Services and HockeyAppDB, while the second removes those dependencies and their related functionality (Location sharing and updates).

If you don't feel comfortable with those changes "as is", but would rather accept an alternative disposition, please let me know what would you change and I'll try to comply your requirements.

Thanks!

[amunizp]

Yes please! I support this!

This would help make it available in the f- droid repo for added piece of mind.

On 4 de febrero de 2014 09:48:34 GMT, Sergio Lopez [email protected] wrote:

Hi,

Current Telegram code depends on non-free services and contains binary blobs, so it doesn't qualify as Free Software attending to some criteria. These changes try to address this issue:

• Remove binary blobs from repo.
• Create two Gradle flavours, "standard" and "foss". The first one builds Telegram with Google Play Services and HockeyAppDB, while the second removes those dependencies and their related functionality (Location sharing and updates).

If you don't feel comfortable with those changes "as is", but would rather accept an alternative disposition, please let me know what would you change and I'll try to comply your requirements.

Thanks! You can merge this Pull Request by running:

git pull https://github.com/slp/Telegram master

Or you can view, comment on it, or merge it online at:

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

-- Commit Summary --

• Remove binary blobs.
  • Create two Gradle flavours, "standard" and "foss".
• Cleanup leftovers on LocationServiceWrapper.

-- File Changes --

M TMessagesProj/build.gradle (16) D TMessagesProj/libs/HockeySDK-3.0.1.jar (0) D TMessagesProj/libs/armeabi-v7a/libtmessages.so (0) D TMessagesProj/libs/armeabi/libtmessages.so (0) D TMessagesProj/libs/x86/libtmessages.so (0) A TMessagesProj/src/foss/AndroidManifest.xml (142) A TMessagesProj/src/foss/java/org/telegram/messenger/GcmBroadcastReceiver.java (10) A TMessagesProj/src/foss/java/org/telegram/messenger/HockeyServiceWrapper.java (14) A TMessagesProj/src/foss/java/org/telegram/messenger/LocationServiceWrapper.java (20) A TMessagesProj/src/foss/java/org/telegram/ui/ApplicationLoader.java (124) A TMessagesProj/src/foss/java/org/telegram/ui/LocationActivity.java (10) M TMessagesProj/src/main/AndroidManifest.xml (29) M TMessagesProj/src/main/java/org/telegram/ui/ApplicationActivity.java (8) M TMessagesProj/src/main/java/org/telegram/ui/ChatActivity.java (55) A TMessagesProj/src/standard/AndroidManifest.xml (171) R TMessagesProj/src/standard/java/org/telegram/messenger/GcmBroadcastReceiver.java (0) A TMessagesProj/src/standard/java/org/telegram/messenger/HockeyServiceWrapper.java (17) A TMessagesProj/src/standard/java/org/telegram/messenger/LocationServiceWrapper.java (28) R TMessagesProj/src/standard/java/org/telegram/ui/ApplicationLoader.java (0) R TMessagesProj/src/standard/java/org/telegram/ui/LocationActivity.java (0)

-- Patch Links --

https://github.com/DrKLO/Telegram/pull/76.patch https://github.com/DrKLO/Telegram/pull/76.diff

---

Reply to this email directly or view it on GitHub: https://github.com/DrKLO/Telegram/pull/76

Enviado desde mi teléfono con K-9 Mail.

[lucianodato]

+1 This must happen!

[slp]

Please, tell me if you're thinking about merging these changes (or an alternative, but equivalent solution), or you prefer the FOSS version to be kept on an third-party repository (and if this the case, please create tags to make easier tracking your versions).

[DrKLO]

I have my own private repo except this on github, where i pushing all changes with unfinished things, because i can work from not only one place. After all new features are tested, I pushing new code to github, So github contains only major updates that will go to google play, so i think there is no need for tags, because every commit is release version. If i remove something from this repo, for me it will be harder to merge all new changes from my private repo.

I will think about this pull request later, when I finish all important features.

[slp]

So github contains only major updates that will go to google play, so i think there is no need for tags, because every commit is release version.

Even if each commit is a release, for third party packagers is still easier and more elegant to build their versions pointing to an specific git tag, than a "well known" commit. It's a oneliner and would be very helpful :-)

I will think about this pull request later, when I finish all important features.

OK. Please let me know if you'd prefer an alternative approach.

[julianwachholz]

I'm not saying that this sounds a bit fishy but unfortunately it does. What are the exact reasons for not providing additional insights into the progress of development of this app? I.e. pushing all commits with actual commit messages to maybe even a develop branch on Github and tagging all releases properly which is really a sane thing to do.

[DrKLO]

Because all my commit history looks like this:

I don't want to waste time to writing tags, commit comments, etc. I write some code at work, commit it, than move to home and continue to write code. This code maybe untested or unfinished. And this is historically, because when I started this project about half year ago, I didn't knew that it will go to github.

[julianwachholz]

Ah, well. Happens to the best of us. I'd just like to leave this here:

Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.

[umazalakain]

Well, if you are planning to open up the project a bit more and make it easier for other people to contribute, following some committing guidelines would be a good idea.

And as far as I'm concerned, taking care of your project organization isn't "wasting time".

[3to8-decoder]

I would be really really happy if this app could just be gotten from F-Droid. I cannot and will not run it as long as it is dependant on google-play-services.

[hectorespert]

+1

[mvdan]

@slp: As a temporary measure until this is merged, we can use your fork as the source repository for inclusion on F-Droid. If you would merge upstream into your branch, I'd look into getting the app in F-Droid in the following days.

[jonnius]

I really need this app in F-droid without google apps dependencies! Thanks for the great work!

[sucotronic]

:+1:

[XayOn]

+1. Are those binary blobs and non-open services actually compatible with the opensource license? =/ Most of telegram users are open source supporters, telegram not being REALLY opensource can be a huge issue.

Also +1 to using SLP's repo for F-Droid.

[captainepoch]

The day this app doesn't have these Google Services, it won't deserve to use.

That's what Open Source mean! Remove it by yourself and upload as a FOSS Modified version.

[XayOn]

Errr, That's what SIC actually did.

We're asking upstream to aknowledge this changes and make an "official" foss branch of the stuff. Also, I think you're confusin the meaning of open source with something else.

2014-02-21 13:19 GMT+01:00 Adolfo Santiago [email protected]:

The day this app doesn't have these Google Services, it won't deserve it.

That's what Open Source mean! Remove it by yourself and upload as a FOSS Modified version.

Reply to this email directly or view it on GitHubhttps://github.com/DrKLO/Telegram/pull/76#issuecomment-35725895 .

[jonnius]

Maybe you could build and offer an apk to download? My friends are aksing me every day when I would install telegram.

[func0der]

@jonnius There is an app in the play store. If you do not want Google to know that you downloaded this app you have to build it on your own.

@DrKLO About your coding behavior. "master" branches are most of the times "unstable". Problem is easily solved by creating a "stable" branch of a version branch like "1.3.x" or so. Pretty good example for this is CakePHP(https://github.com/cakephp/cakephp). I do not say that you should not keep your private repository, but I think you should at least sync branches once per day. Tags would be also really necessary to use/fork older versions and/or fix bugs in those versions. I think it is not that important to have those tag messages, but the tags are necessary.

To your commit messages: Sorry, to say that, but they are aweful. Not only for the open source community, but also for yourself. You never know what you did when. Diffing those commits won't help no one, not even you. I know, that you want to code and do not "waste" time. But maintaining your code with comments and write descriptive commit message is as essential as wiping your butt after...you know what ^^ Also this is what you have to do while maintaining an open source project.

Please do not take this as a personal insult, but rather as a well meant advice.

[ManuelSchneid3r]

Why ain't there a community driven open source alternative for Telegram? All those complaining could contribute what they want. I also think that this coding behaviour is not really helpful. But there is the problem getting all together.

[XayOn]

Well, that's what github is isn't it? But who creates the main center repo? And who manages it? Where?

[ManuelSchneid3r]

True, true. I have no time at the moment, as I have to prepare for my exams. So it is up to you :). Sorry DrKLO, but I have to recommend the S-Edition (2nd competition winner) here, as it covers much more of the desired FOSS friendliness. It is available at the store, too, and the source is here on github.

[ghost]

Where?

[ManuelSchneid3r]

https://github.com/ex3ndr

[jonnius]

@DrKLO Do you plan to merge this and distribute a FOSS version of telegram or should someone else do that?

[mythsunwind]

@DrKLO On the Google Play website you can currently download version 1.3.25 as binary. Where can I find the source code of this version? The public repo seems to only contain a much older version (1.3.21).

[DrKLO]

@dserodio please, no need to advertise here other apps.

[alejandro-amo]

IMHO, we all only need a higher frequency of syncing between private and public repos. I understand the points of @drklo regarding many other details, and I think we all can "bear" with his particular style of code even if it's not the best style for the sake of community coworking. Lack of tags is not as bad if we all make an arrangement and try to stay in sync without separating versions in any way (which I think would be better than separating FOSS version from official google play one, etc etc)

[pdf]

@DrKLO I can't stress to you how important it is for you to improve your git workflow. For your own benefit, for the project's benefit, and for everyone else's.

Here are the important points:

• Commit as frequently as you like (but clean up for public consumption)
  • Committing often during development is useful, and makes it easy to backtrack
  • Before you push to a public repository, you may use git rebase to squash commits down into logical units of work
  • This also transforms the merging of patches from being all-but-impossible to very-manageable
• Use descriptive commit messages
  • Doing so allows everyone (including you) to review changes (and determine what you were doing when you broke something)
  • If you rebase before pushing, you can clean up your commit messages during the rebase
• Use branches
  • Ideally, you should develop features in topic branches
  • If the above seems like too much effort, a simple segregation is to create a develop branch that can contain dirty/broken code, that once working can be merged into master
• Tag releases
  • Not doing this is just silly, and your excuse that it takes too much time is absolutely ridiculous.
  • It literally takes one second to create a tag
  • Doing so allows tracking of exactly what changed between versions, so that you can tell which versions are affected by a bug, for example

It will be absolutely impossible to maintain this as an open source project until you start using source control responsibly. You're obviously new to software development, so all this may seem a little overwhelming, but if you think that source control is a waste of time, this project may as well already be dead, or closed source.

Either this project is open source, or it's not. Having binaries shipped on source that's not even available means this is not open source.

[jedie]

Personal for me, Telegram will be only have a feature if it will be complete OpenSource. Also the server code!