F-Droid is cool but will lack lots of applications, even open source ones. I recently checked what it would require to publish my app there -- alas, can't do that since my app includes an API key that can't be published (according to the rules of the service in question), and F-Droid would need that[1].
I dont get all that API key nonsense, you can search this board for our opinions on API keys. I’ll keep this short:
If your app requires an API key and you withhold it (because you entered an agreement with the service provider), this basically makes it not buildable for 3rd parties in a useful manner. F-droid will not sign an agreement with whatever service provider you use nor will we withhold build information.
There are actually only two solutions:
1) Provide a way for the user (!) to enter API key or account information at runtime.
2) Provide a way for us to get the key at buildtime, e.g. there was one app where I had to download a pre-compile APK file, extract the key from it and re-use that key in our builds.. which sucked. Anyway, I dont see what’s the difference to just providing the API key. If you distribute an APK, you distribute the API key (in one form or another) — since without it the app would not work… sigh.
That's a very technical viewpoint. The API agreement tells not to share the key, which obviously does not mean you can't include it in the app binary. I interpret that as not being allowed to publish the key with the source code though.
That's pretty weird and questionable interpretation, since if I have a binary — I have the key, even if in some obfuscated form (even that isn't usually true with APKs though), but whatever, if it works for you — fine, then I have a solution to your problem.
Don't include API_KEY in the published source, include rot13(API_KEY).
You have to consider the intention of the service provider, which in this case is more geared towards mobile clients than web services. It's perfectly clear that binaries will include the API key, no interpretation needed on that part.
It's the source code part that is open to interpretation. I could of course just ask for explicit permission for that.
I never developed an app so I dont know, but if you cant include in the APK because people can decode it, how do you distribute keys and secret strings?
You distribute user-specific secrets after a user has logged in over a secure channel.
You don't get to have app-specific secrets - since anybody can get and run the app (and modify it!), nothing in it has a reason to be secret. This means that you don't get to have an API that's available only through that app and with limitations set by that app. If you use a third-party API that requires you to enforce limits on its use (e.g. that end users can't redistribute access to that API), this means that you can't meet the requirements of that API licencing.
Yeah, BTW the good thing about these stores is that they install apps normally, by launching the system APK install dialog, instead of the rootkit-style thing Google Play does.
It uses special privileges to run the installation in the background. Google Play Services is frequently called a "rootkit" because of stuff like that.
You can build the app, and to make it functional you could request your own API key, so I think it satisfies the label. Requesting API keys as a regular end user isn't anywhere near being realistic though, so that's not an option for distribution.
From pawadu's response above it sounds like your app would satisfy the requirements if you have a build parameter or similar that lets them specify the key.
There's another discussion thread [1] which takes a strict stance more explicitly: "I don’t see how something that contains a ‘secret’ key [...] can be Free Software. So we just don’t publish such applications."
F-Droid has several apps where they download a built APK, decompile it automatically, extract the API key, and build the open source app with that key.
[1] https://f-droid.org/forums/topic/what-to-do-with-private-api...