Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make Telegram code FOSS friendly #76

Open
wants to merge 3 commits into
base: master
from

Conversation

@slp
Copy link
Contributor

commented Feb 4, 2014

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!

slp added 3 commits Feb 3, 2014
Remove binary blobs.
libtmessages.so is generated from sources using ndk-build, and
Gradle is able to grab HockeySDK from its repo if needed.
Create two Gradle flavours, "standard" and "foss".
This change creates two different Gradle flavours:
  - standard: Telegram as was before this change.
  - foss: Telegram without HockeyApp and Google Play Services.

To make future maintenance easier, I've implemented two service
wrappers (HockeyServiceWrapper and LocationServiceWrapper), intended
to remove build time dependencies without maintaining separate copies
for both ApplicationActiviy and ChatActivity.
@amunizp

This comment has been minimized.

Copy link

commented Feb 5, 2014

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 notifications@github.com 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:

#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:
#76

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

@lucianodato

This comment has been minimized.

Copy link

commented Feb 6, 2014

+1 This must happen!

@slp

This comment has been minimized.

Copy link
Contributor Author

commented Feb 7, 2014

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

This comment has been minimized.

Copy link
Owner

commented Feb 7, 2014

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

This comment has been minimized.

Copy link
Contributor Author

commented Feb 10, 2014

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

This comment has been minimized.

Copy link

commented Feb 11, 2014

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

This comment has been minimized.

Copy link
Owner

commented Feb 11, 2014

Because all my commit history looks like this:
screen

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

This comment has been minimized.

Copy link

commented Feb 11, 2014

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

This comment has been minimized.

Copy link

commented Feb 11, 2014

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

@Basaah

This comment has been minimized.

Copy link

commented Feb 20, 2014

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.

@blackleg

This comment has been minimized.

Copy link

commented Feb 20, 2014

+1

@mvdan

This comment has been minimized.

Copy link

commented Feb 20, 2014

@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

This comment has been minimized.

Copy link

commented Feb 21, 2014

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

@sucotronic

This comment has been minimized.

Copy link

commented Feb 21, 2014

👍

@XayOn

This comment has been minimized.

Copy link

commented Feb 21, 2014

+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

This comment has been minimized.

Copy link

commented Feb 21, 2014

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

This comment has been minimized.

Copy link

commented Feb 21, 2014

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 notifications@github.com:

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//pull/76#issuecomment-35725895
.

@jonnius

This comment has been minimized.

Copy link

commented Feb 22, 2014

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

@func0der

This comment has been minimized.

Copy link

commented Feb 22, 2014

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

@DrKLO DrKLO referenced this pull request Feb 24, 2014
@ManuelSchneid3r

This comment has been minimized.

Copy link

commented Feb 24, 2014

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

This comment has been minimized.

Copy link

commented Feb 24, 2014

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

@ManuelSchneid3r

This comment has been minimized.

Copy link

commented Feb 24, 2014

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

This comment has been minimized.

Copy link

commented Feb 24, 2014

Where?

@ManuelSchneid3r

This comment has been minimized.

Copy link

commented Feb 24, 2014

@jonnius

This comment has been minimized.

Copy link

commented Feb 25, 2014

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

@mythsunwind

This comment has been minimized.

Copy link

commented Feb 25, 2014

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

@ghost

This comment has been minimized.

Copy link

commented Feb 28, 2014

Sorry then...... So... There is nothing to do... What does not have a fix it is already fixed....
Like "koem" said: Let's fork this and make the server side too!

@ManuelSchneid3r

This comment has been minimized.

Copy link

commented Feb 28, 2014

Can somebody make/redirect to a platform where we (the open source community enthusiasts) can communicate? I dont know what and where. But this is indeed the wrong place to talk about this. I think of a github organization or mailing list or something like this. I would propose to fork the S Edition. The author of the S Edition maintains its own repository, too, and the sources are published with the release of the app in the store too. Hence too late. So a community driven fork would be fine. Who volunteers for the head of the organization? (Who has a the most spare time?)

@AlisterAmo

This comment has been minimized.

Copy link

commented Feb 28, 2014

just joined telegram S.
but, if they stick to the last statements, telegram official project needs to rework its marketing and PR strategy. losing the support of the open source community is a very bad trade

@DrKLO

This comment has been minimized.

Copy link
Owner

commented Feb 28, 2014

When I took part in Durov's Android challenge I was not going to publish the source code. When I won and app became official our team decided to publish source code, so that people can build them own version if they don't trust to version released in market. S version developer released source code by the same decision.
Sorry if I was rude, we didn't expect so much contribution of community. In our team always was like this: one project - one developer.

@AlisterAmo

This comment has been minimized.

Copy link

commented Feb 28, 2014

@DrKLO I think you feel a bit overwhelmed and the usually high standards of open source community are pushing you forward, therefore you feel uncomfortable because you start to feel how much hard can be developing "fully opensource" projects, including best coding practices, coding style that helps teamwork and longterm maintainance (for youw own future benefit too), etc.

I know that being closely observed feels hard sometimes. I dont need you to defend from this fact, this is not an insult, but we feel you are still on early stages of you learning curve regarding collaborative development and project management. this has nothing to do with you pure coding and problem solving skills, which I totally believe you have, since you have made an interesting work so far.
I think we all should breath a bit and work our way towards the benefit of both parts, trying to respect all the positions and being cristal clear regarding licences, business model and marketing strategy, etc. (telegram has full right not to make the server code public, for example, and they still can state that the client is secure because is open source).

@DrKLO, in my experience, the free software community returns a lot more than they demand, so I suggest you to let ourselves enhance a bit your repo management strategy and structure, while we could try to be more flexible regarding other aspects of the projects (guys, remember, in the end this is a commercial project so they need some warranties) and being more tolerant with the amount of information that we have bombarded you with (I understand you need to process and you will need time to slowly integrate into your workflow... provided that you want to live a 100% free software experience for the good of the project

what's your opinion, people?

@koem

This comment has been minimized.

Copy link

commented Mar 1, 2014

@WhiteHatAlister @DrKLO - yeah, I absolutely support that idea - DrKLO, just let someone help you to manage THIS project here and make it fully GPL. It really would harm the reputation of this client and Telegram itself if there would be a spin off because of lack time to organize it.

When c:geo (Geocaching App) was given to some other developers because the original maintainer didn't have time anymore ... it gained so much speed and great feedback! There were so much features developed and so much refactoring done we had a new major version every some weeks.

You don't have to give away your baby, but you do have to make it totally open source or keep it to yourself completely - there is no such thing as "a little open source".

@AlisterAmo

This comment has been minimized.

Copy link

commented Mar 1, 2014

I think we can easily correct the problem of the api keys and such in drklo's private repo with not much effort; ignore files and some medium/advanced use of git. the rest of work is a matter of time, communication, and slow and team oriented learning and practising. I think we all could learn a lot :)

@nukeador

This comment has been minimized.

Copy link

commented Mar 10, 2014

Ey guys,

I've just read this issue. May I suggest you to open a doodle, draft and agenda and set a meeting (irc, hangouts.. whatever) to talk more calmly with @DrKLO about his governance vision for this project and how that can fit with the open source community willing to contribute to it?

Real time communication can help to understand each side view better :)

@DrKLO

This comment has been minimized.

Copy link
Owner

commented Mar 16, 2014

I'm trying to configure gradle build file like this:

buildTypes {
        debug {
            debuggable true
            jniDebugBuild true
            signingConfig signingConfigs.debug

            sourceSets {
                main {
                    manifest.srcFile 'src/main/build/debug/AndroidManifest.xml'
                }
            }
        }

        release {
            debuggable false
            jniDebugBuild false
            signingConfig signingConfigs.release

            sourceSets {
                main {
                    manifest.srcFile 'src/main/build/release/AndroidManifest.xml'
                }
            }
        }
    }

and also tried to add foss configuration, but gradle always take last sourceSets. If it foss configuration, it takes manifest.srcFile 'src/main/build/foss/AndroidManifest.xml' and there are a lot of compilation errors

Any help?

@AlisterAmo

This comment has been minimized.

Copy link

commented Mar 16, 2014

I'm asking my android mates right now, DrKLO

@DrKLO

This comment has been minimized.

Copy link
Owner

commented Mar 22, 2014

Finally dev brash on github https://github.com/DrKLO/Telegram/tree/dev. Now i will commit all daily changes to it. I started implementing FOSS configuration, but it's not finished yet. It should be done without changing package name of release version, any help appreciated.

@func0der

This comment has been minimized.

Copy link

commented Mar 23, 2014

This is amazing.
Thanks, @DrKLO.
Keep on going :)

@XayOn

This comment has been minimized.

Copy link

commented Mar 23, 2014

+1, keep up the good work DrKLO.

2014-03-23 16:12 GMT+01:00 Lars notifications@github.com:

This is amazing.
Thanks, @DrKLO https://github.com/DrKLO.
Keep on going :)

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

Gracias,

David Francos Cuartero (davidfrancos.net)

Software developer - Neodoo Microsystems (neodoo.es)
President - Dlabs Hackerspace (dlabs.co)

@korg91

This comment has been minimized.

Copy link

commented Mar 23, 2014

Really happy to read that! Thank you for this choice, you won't regret it ;)

@AleixDev AleixDev referenced this pull request Mar 24, 2014
@slp

This comment has been minimized.

Copy link
Contributor Author

commented Mar 27, 2014

This is great news, thanks @DrKLO.

Have you considered implementing gradle flavors as I did in this pull request? To be able to build Telegram without Google Play Services, alternative versions for some source files will be needed.

I can make a newer pull request to your dev branch with this feature, I you will consider merging it.

@DrKLO

This comment has been minimized.

Copy link
Owner

commented Mar 27, 2014

@slp i see that build flavors change package name, is this correct?

@dalb8

This comment has been minimized.

Copy link

commented Mar 29, 2014

Changing package names is optional with gradle flavors e.g. dschuermann/ntp-sync.

If it's a different flavor shouldn't it have a different package name? Unless something goes horribly wrong if the two are installed together?

@DrKLO

This comment has been minimized.

Copy link
Owner

commented Mar 30, 2014

@dalb8 if it's optional, is there other way to use different files for some classes in compile time? Because in this patch different files were placed folders according to package name.

@slp

This comment has been minimized.

Copy link
Contributor Author

commented Mar 31, 2014

@DrKLO The directory structure changes a bit, but the package name (in Java hierarchy sense) is kept intact. If you look at source files moved to "foss" and "standard" directories, you'll see they still preserve the same package declaration.

@saijsw

This comment has been minimized.

Copy link

commented Apr 7, 2014

When i visited #my.tekegram.org i created new build with api dev options . It throughs some ID and DC config . so wgats next .. I mean how to configure with server ?

@saijsw

This comment has been minimized.

Copy link

commented Apr 7, 2014

When i visited #my.telegram.org i created new build with api dev options . It throughs some ID and DC config . so whats next .. I mean how to configure with server ?

@func0der

This comment has been minimized.

Copy link

commented Apr 9, 2014

@saijsw
On a 99% chance you will be completely ignored here, because this is not the place to ask such question. It is completely off-topic and you double posted. There is a option to edit comments and a place to ask such questions.

@digidalla

This comment has been minimized.

Copy link

commented May 22, 2016

I tried and followed all the instructions in this telegram project and still cant get it to build, and the first time i got it to build it crash right after opening up on my HTC

@sedrubal

This comment has been minimized.

Copy link

commented Jan 30, 2017

@DrKLO are there any plans to open the project to the community and to update the code on github? So that this and the other pull requests can be merged?

@AntonBoch1244
Copy link

left a comment

Update conflicting files!
TMessagesProj/build.gradle
TMessagesProj/src/main/AndroidManifest.xml
TMessagesProj/src/main/java/org/telegram/ui/ApplicationActivity.java
TMessagesProj/src/main/java/org/telegram/ui/ChatActivity.java
TMessagesProj/src/main/java/org/telegram/ui/LocationActivity.java

@BO41

This comment has been minimized.

Copy link

commented May 30, 2019

@DrKLO How about taking over the unofficial foss version of the Telegram app?
It is working perfectly. Also it is already on F-Droid.

I am pretty sure @Telegram-FOSS-Team and contributors are happy to transfer ownership to make it official.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.