> In a nutshell, the Apple Developer Agreement is the biggest "problem" preventing a Pidgin build for iOS devices. We won't quote the exact text here, but the Agreement requires that developers allow Apple to impose additional restrictions on applications above and beyond the application's own license. Among these additional restrictions are the well-known "5-device limit" and a prohibition on redistribution of the application. It is also quite clear from the terms of the Agreement that the developer of an application is not the distributor of the application in the App Store--Apple is.
> The additional restrictions required by Apple directly violate the GPL Pidgin is licensed under (Pidgin is licensed as "GPLv2 or later," and cannot transition to GPLv3 for a number of reasons not suited for this topic). GPLv2 forbids adding restrictions above and beyond those included in the GPL's own text, thus any distribution via Apple's App Store is a direct violation of the GPL. This is the root of the problem.
Sorry, but I'm not familiar with this – could you share more please?
It has subsequently been increased to 10.
TIL it's now 10 devices...
I think the idea is that you don't tie all your friends' devices to your account to share apps etc., but I am just guessing.
Quick search reveals that up to 5 devices can be tied to the same Apple account: https://discussions.apple.com/thread/8030144
What is lost when they make Pidgin available on the App Store (under the restrictive App Store license) + under GPL (on their website) as opposed to not having an App Store version in the first place and releasing under the GPL only?
I don't see how the presence of a second, more restrictive license invalidates the GPL given that anyone willing to take advantage of something not allowed under the more restrictive license can still do so under GPL?
It's either GPL with all the rights that entails, or you can't (legally) redistribute it at all.
Now, if you own the copyright you can give out as many parallel licenses as you want. But pidgin & libpurple have been around for 20 or more years and have had many, many contributors, and they have to explicitly give up their copyright or consent to the license change to do what you propose. That's theoretically not impossible, but it's a lot of work.
This is why some projects require you to sign copyright-assignment agreement before they will take your patches—it gives the project more flexibility to change the license in the future.
There are many ways to skin this cat.
It's not a commercial project with a CLA, it doesn't have a single owner, many of the people who contributed major parts have moved on or would object to a license change from copyleft to permissive, so it's not a matter of "just change" the license. And libpurple is the real meat of the project.
I followed a few of the developers for a bit as I really wanted to work there. I believed they got aquired into the g+ team (gchat? maybe?).
For iOS IM to work, a centralized server (and corresponding developer ID) has to send a notification to you, sent first to Apple to be proxied via Apple's push notification service (APNS) to which each iOS device maintains a persistent connection.
This means that some third party service has to know when you get a message (and thus needs to proxy your connections to the IM services, and know your credentials and see your message contents) to be able to know when to send that notification.
This (and Signal now replacing the cryptographically shattered iMessage) is probably the main reason I'm switching to Android; truly decentralized/private notifications aren't really possible on iOS. They have to come from the app developer's own 24/7 online servers, sent from them to you via Apple servers, which means that federated stuff is basically out without providing your login details to the developer (which of course lets them see all your messages). This is also why almost no ActivityPub/fediverse clients can notify you of DMs on iOS either if you run your own instance.
I know there's Background App Refresh now that lets apps wake up periodically to download stuff; I'm not sure if such polling can fire off notifications from the local app. It's probably too much latency for IM, however, due to the fact that Background App Refresh isn't (last I looked) allowed to run continuously (for battery reasons).
the main reason I'm switching to Android
You may be interested in reading this comment then: https://www.reddit.com/r/signal/comments/ap9lin/comment/eg7v...
Likely, iOS version of Signal uses the same “empty ping” technique, so you don’t have to worry about Apple reading your texts, unless you’re concerned with metadata leak. But unless they’re spoofing a websocket with fake packets, it will leak anyway.
First, that “server” is Signal server itself. When a message arrives at it, it simply commands Apple to wake up your app, for it to call home, and that’s it. It is preconfigured to do that (and GCM as well).
Second, all Signal messages are end to end encrypted and neither of Apple, Signal, Google, your ISP, any server on the route of it NEVER know its content, because the only mean of decrypting it resides in a memory of your client app. There is basically no way to see the contents before your client receives the message, by design. Even if that were not the case, various IM servers don’t have to send your texts to Apple, only if they want the text to be shown on a notification itself.
The only theoretical concern here may be that Apple can somehow pick the decryption key out of the app’s memory (because ios is a supervisor, obviously). But that can’t be the main reason someone swithces to android, which is a supervisor itself, and where the same issue exists.
In a centralized system where the mobile app is made by the same people as the IM server, of course the IM server can send a notification to the app (such as is done in e2e stuff like Signal, or in non-e2e such as Telegram).
That falls apart when you're talking about, say, ActivityPub on an instance you run yourself, or one not operated by the vendor of the IM app. The developer's server can't know when to send you a notification without having some knowledge, from your own e.g. IRC, ActivityPub, or Matrix server, that you have received a new DM.
The Matrix/Element people have addressed this by running one centralized notification service for every single client of the Matrix/Element iOS app.
Sorry, I misunderstood that.
The main reason for the restriction to apple-only for notification services is battery life, and they've been proven right by bad behavior demonstrated on android.
Interestingly, if your a VOIP app you can actually circumvent a lot of the background networking restrictions, but it's still hard to do when you don't have an active call in place. You also have to be an actual VOIP app to get approved with that entitlement. Which wouldn't be hard to get approval for if you made a fork of signal for example, since it does have real VOIP capabilities inside.
Either way the battery life of your device would be worse with your custom VOIP app always keeping a connection open vs. apple's native OS notification system.
These APIs were removed a while ago. As an example, pure SIP clients (without a SIP<->APNs proxy operated by the app developer) are no longer possible for iOS.
Android seems to be headed the opposite direction from Apple when it comes to background service execution and network connectivity. I wouldn't be surprised if background network connections are the next thing to go.
> which means that federated stuff is basically out without providing your login details to the developer
It's definitely possible to support federated push, although it's admittedly more work for app/protocol developers: The app developer would have to set up a "push proxy" server that accepts push notifications addressed to a specific iOS device.
It would be nice if Apple was to allow optional sourcing of "anonymous" pushes for such use cases, but that doesn't seem to be in line with their desired level of control.
Could you expand on this? I did a quick search but I don't see anything relevant that's more recent than 2016.
It's still relevant.
You really need push notifications, but AFAIK, push tokens are tied to the app developer; you can't give an random server a token from your app, because they won't be able to push to you.
So Pidgin (gaim for those of us old enough to remember those days) should run fine without a port.
I want to be supportive but holy hell am I frustrated.
The problem is the lack of SoC documentation. There is some progress for the camera though: https://source.puri.sm/Librem5/linux-next/-/issues/44#note_1....
Sure. Was saying that this should work out of the box (at least for the most part) on a linux phone. No port necessary.
I've kept an eye on other phones throughout the years, but nothing quite ticks the same boxes (and by far most things aren't even remotely close).
There are some other interesting phones on the horizon (Librem, PinePhone), but then again things like Maemo Leste are ready to breathe new life into the N900, so I might be using it for very long time yet!
Also, I've used Pidgin as my main mobile IM client back in the day on the Openmoko Neo Freerunner.
Can't have a non-monetised, FOSS, universal application available in the app stores! That's like ... that's like COMMUNISM, or something! /s
Pidgin was great back in the day for convenience, but there is a legitimate argument to be made for privacy here too.
EDIT: It just occurred to me that this would probably work on linux phones. Anyone with a Pinephone or Librem 5 tried this?