4 ms·

I think we're missing some information here. The supplied link says that the applications have been renamed due to legal threats. This seems completely reason

I think we're missing some information here. The supplied link says that the applications have been renamed due to legal threats. This seems completely reasonable to me. The names of the apps are trademarks and for a security product, who builds it is important to the integrity of the mark. I'm trying to remember how Android works, but I seem to recall that you need to sign the packages differently on Play and Fdroid. So you literally can't redistribute the same Play package with Fdroid (someone correct me if I'm wrong). This means rebuilding... and hence rebranding. It seems that MM was asked to provide a build for Fdroid. He decided not to. That's completely his right. He doesn't go into a lot of detail about why he has decided this, but it's completely up to him. So all I can tell is that there is an Fdroid version, which has a different name. You can't switch easily between the Play and Fdroid versions because of code suckage... which sucks, but isn't a GPL violation. Is this just a tempest in a teapot, or am I missing something?

kuschku 11y ago
> I'm trying to remember how Android works, but I seem to recall that you need to sign the packages differently on Play and Fdroid. So you literally can't redistribute the same Play package with Fdroid (someone correct me if I'm wrong). This means rebuilding... and hence rebranding. You can distribute the same build on F-Droid and Play, and also signed with your own key, if you use proper reproducible builds (And not the TextSecure variant of "let’s download this huge image and let it compile the app", because that opens you to evil compiler issues).
neerdowell 11y ago
> He decided not to. That's completely his right. He doesn't go into a lot of detail about why he has decided this, but it's completely up to him. He doesn't like how F-Droid uses centralized signing keys which are stored online: https://github.com/WhisperSystems/Signal-Android/issues/127#issuecomment-13339504 https://github.com/WhisperSystems/Signal-Android/issues/127#...
- mikekchar 11y ago
  Thanks for that link. It is much more informative than the other one. I can see where he's coming from. Some of the things he wants as a developer are things that I don't personally want as a user (automated updates), but then I can build and install the thing myself, as he says.
- jb613 11y ago
  except Android devices trust Google keys
  - neerdowell 11y ago
    What? APKs are signed by the developer before they uploaded to the store and the signatures are verified by PackageManagerService which is a part of AOSP.
    - jb613 11y ago
      whether implicit trusts such as for example Google Play Licensing[1] or explicit trusts such as for example the set of Certification Authorities Android devices ship with, you are trusting Google in many ways. [1] https://support.google.com/googleplay/android-developer/answer/186113 https://support.google.com/googleplay/android-developer/answ...
      - sigmar 11y ago
        In the example you provide, you are trusting google in the same way you are trusting every SSL cert authority. What you are responding to is a reference to the signing of the APK, which is not (and cannot be) done by google even if the security of the transport layer is compromised.
- pureIDEOLOGY 11y ago
  Except that they aren't. Read the responses in that thread from the actual FDroid devs.
patcon 11y ago
MM actually does go into a lot of detail (at least the first dozen times he was asked), and it's quite reasonable.
- mikekchar 11y ago
  Thanks. Yes, someone else posted a better link with the rationale. Essentially he wants the user experience for the average person to have auto-upgrade so that he can fix bugs, etc reliably. For those that have more tech experience and can judge whether or not they should upgrade, they can build their own very easily. Since he signs it with his own key, nobody can force an auto-upgrade except him. So you either have to trust him for this version and all future versions, or not trust him and build your own. You can package and sign your own version, but apparently (I haven't actually seen the reported twitter comments) he doesn't want you to name them the same (which is clearly a reasonable trademark issue since any build not signed by him could contain anything). I personally don't have a problem with that and it certainly isn't a GPL violation.

kuschku 11y ago

> I'm trying to remember how Android works, but I seem to recall that you need to sign the packages differently on Play and Fdroid. So you literally can't redistribute the same Play package with Fdroid (someone correct me if I'm wrong). This means rebuilding... and hence rebranding. You can distribute the same build on F-Droid and Play, and also signed with your own key, if you use proper reproducible builds (And not the TextSecure variant of "let’s download this huge image and let it compile the app", because that opens you to evil compiler issues).

neerdowell 11y ago

> He decided not to. That's completely his right. He doesn't go into a lot of detail about why he has decided this, but it's completely up to him. He doesn't like how F-Droid uses centralized signing keys which are stored online: https://github.com/WhisperSystems/Signal-Android/issues/127#issuecomment-13339504 https://github.com/WhisperSystems/Signal-Android/issues/127#...

mikekchar 11y ago
Thanks for that link. It is much more informative than the other one. I can see where he's coming from. Some of the things he wants as a developer are things that I don't personally want as a user (automated updates), but then I can build and install the thing myself, as he says.
jb613 11y ago
except Android devices trust Google keys
- neerdowell 11y ago
  What? APKs are signed by the developer before they uploaded to the store and the signatures are verified by PackageManagerService which is a part of AOSP.
  - jb613 11y ago
    whether implicit trusts such as for example Google Play Licensing[1] or explicit trusts such as for example the set of Certification Authorities Android devices ship with, you are trusting Google in many ways. [1] https://support.google.com/googleplay/android-developer/answer/186113 https://support.google.com/googleplay/android-developer/answ...
    - sigmar 11y ago
      In the example you provide, you are trusting google in the same way you are trusting every SSL cert authority. What you are responding to is a reference to the signing of the APK, which is not (and cannot be) done by google even if the security of the transport layer is compromised.
pureIDEOLOGY 11y ago
Except that they aren't. Read the responses in that thread from the actual FDroid devs.

patcon 11y ago

MM actually does go into a lot of detail (at least the first dozen times he was asked), and it's quite reasonable.

mikekchar 11y ago
Thanks. Yes, someone else posted a better link with the rationale. Essentially he wants the user experience for the average person to have auto-upgrade so that he can fix bugs, etc reliably. For those that have more tech experience and can judge whether or not they should upgrade, they can build their own very easily. Since he signs it with his own key, nobody can force an auto-upgrade except him. So you either have to trust him for this version and all future versions, or not trust him and build your own. You can package and sign your own version, but apparently (I haven't actually seen the reported twitter comments) he doesn't want you to name them the same (which is clearly a reasonable trademark issue since any build not signed by him could contain anything). I personally don't have a problem with that and it certainly isn't a GPL violation.