Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I don't think you're focusing on the entire picture.

Some people here like iOS for the reasons you described. However I'm willing to bet, unless you can show me otherwise, that it's a vocal minority. I don't know of anyone personally who is happy that Apple disallows GPL code.

Comparing Apple's digital Fort Knox with Google's unsupervised free-for-all is a false dichotomy.

There exists a happy medium, where power users get all the freedom they want but apps are still by default beholden to certain restrictions. And this is orthogonal to a proprietary API.




> There exists a happy medium, where power users get all the freedom they want but apps are still by default beholden to certain restrictions. And this is orthogonal to a proprietary API.

Is this not the happy medium Google is trying to hit?

Power users can unlock their bootloader and do whatever they want. This is still officially supported, with vendor blobs officially provided.

By default things are restricted to deliver a happy user experience in the context of the average person that just wants a product that works. But you're free to do whatever you want. There's (usually) even controls to remove restrictions from apps manually without doing the custom ROM route, but there is always the ultimate power user toggle there of "flash a custom ROM"


That's what I thought when I bought my Sony phone. Except when you unlock it you run a crippled version of the phone.

Huawei recently stopped allowing bootloader unlocks.

Unlocking the bootloader is becoming increasingly rare.

To be honest, ignoring the back and forth between the discussions here, am the only one that doesn't get WHY the firebase library isn't open source? It could just be GPL right? Most of the interesting stuff happens in the backend anyway, so what's the issue.

Am I also the only one that thinks this gives google the chance to lock out/cripple third parties like huawei or other non certified android vendors from distributing Android apps that were built for the play store.


> Unlocking the bootloader is becoming increasingly rare.

This is a bit of "you get what you buy" territory. Google's devices have official bootloader unlock capability and always have, with instructions here: https://source.android.com/setup/build/running - already updated for the Pixel 3a & 3a XL even. You take your risks when you buy something that doesn't advertise that.

> Most of the interesting stuff happens in the backend anyway, so what's the issue.

I think most of the interesting stuff on the device is even in Google Play Services and not in the firebase library. I have no idea why the client SDK can't be open source, but how much does that even matter?


I just bought a new Pixel 3a only to find out that my cell provider locks the bootloader until I've paid for 3-4 months service with the phone, despite previously having an account with them.

This was not mentioned at any time during the purchase and they would not take my phone back.


Unfortunately that's the problem with getting any phone via a cell provider. You are typically beholden to them in some fashion for a few months.

Buying unlocked phones from the start can be an expensive downside, but being free from contracts and carrier bullshit can be a huge upside.


I don't know the ins and outs of this, but wouldn't that still mean that the app would have to rely on google infrastructure to do push notifications? That might be a fix for the licensing problem, but it wouldn't address the problem that that would move virtually all remaining google-free (-ish) messengers into googles direction, with the potential for centrally siphoning of (meta-) data


No, the app can continue to use third party push notifications if the OS allows it to.


For completeness' sake: even power users cannot really do with their devices as they please, if they don't happen to be kernel hackers with a few months' worth of time to spare.

If google was trying to hit some sweet spot (I'm not willing to give them the benefit of the doubt here any longer) then they would not spout such obviously wrong BS to scare users into submission. Conversations and telegram both put the work into doing push notifications The Right Way (TM) so scaring users about this is stupid at best.


> even power users cannot really do with their devices as they please, if they don't happen to be kernel hackers with a few months' worth of time to spare.

You don't have to be a kernel hacker to build & flash AOSP. Google has a guide on it: https://source.android.com/setup/build/running

But whether or not you consider this a "power user" or not is obviously less clear cut. How you define "power user" does of course change things. The point is just that there is the ultimate escape hatch of flashing a custom ROM, and it's not THAT hard to do, especially with all the tools out there to flash things like LineageOS super easily. You may not understand what it's doing, but it is at least sitting on officially supported things for the devices Google sells.


Not sure why you are bringing this up. The point of this thread is the misleading warning or other OS level changes that are forced upon you if you don't use FCM. Changing that behaviour needs changing AOSP.


Then it's a real shame they haven't paid attention to the documentation for NotificationBuilder, because there's a straightforward solution to the problem they're complaining about.


> Power users can unlock their bootloader and do whatever they want. This is still officially supported, with vendor blobs officially provided.

A bit of a tangent but I'm a "power user" and still can't get rid of the stupid warning in the beginning. Definitely not a happy medium.


Please forgive me for being unnecessarily obtuse this early on a Monday morning.

Where does Apple say that GPL code isn’t allowed on the App Store? I ask entirely out of my selfish need to avoid unpleasant surprises later on.


It's what I've heard rehashed around HN, but afaik the actual policy is more or less as described here:

https://forums.developer.apple.com/thread/18922

Essentially it works like it should anywhere else: If you don't publish source code and someone complains, you're out. In an ideal world Google Play would hold itself to the same standards.

However, the App Store does impart restrictions which are incompatible with GPL, so it's not so much that Apple doesn't allow it as it is that GPL doesn't allow it.

Apple has no official statement on this of course, but we know how they feel about GPL code given that they've removed every bit of it from their OS over the last few years.


They haven't been removing GPL code actively, they decided not to take the risk of using GPL version 3 software, so they've let the respective versions of bash, rsync etc. linger at their last released GPL version 2 releases.

E.g. Git is on GPL version 2 still (and probably forever), and Apple continues to update that in a relatively timely fashion.


Apple just switched to zsh, which is not GPL other than a few optional shell functions. Expect this trend to continue.


The App Store came after the GPL. Also, Apple could let developers opt out of the restrictions.


But they don't, and that's what this conversation is about.


You attributed the incompatibility to the GPL. Apple created the incompatibility. Apple could easily fix it. The FSF can't change existing versions of the GPL.


Apple doesn't say it directly, but the way how they deliver apps to devices incompatible with GPL licensing terms.

See for example https://apple.stackexchange.com/questions/6109/is-it-possibl... .


Free Software Foundation says that GPL is not allowed in AppStore and they may request GPL software to be removed from App Store. https://www.fsf.org/news/2010-05-app-store-compliance


Apple has been slowly phasing out GPLed software from their own software, such as Catalina's migration from Bash to Z Shell, but even writing third party apps with the GPL has apparently been problematic in the past: https://thenextweb.com/apps/2013/07/18/vlc-for-ios-will-retu...


The issue is that the Apple dev ecosystem creates encumbrances that prevent users of GPL binaries from relinking them. That is a GPL violation and such binaries are not compliant with the license.


Someone should probably tell VLC if GPL is disallowed, since they have been shipping across tvOS and iOS for years.


I think VLC core had a large amount of code rewritten, to change the license (https://news.ycombinator.com/item?id=4787965), which required a large effort from the VLC team.


They don’t- it’s the FSF restricting developers freedom. Not Apple.


How? I'll debate FSF ethics as much as the next guy, but they clearly state they want end user freedoms such as the freedom to modify the application you use. Apple clearly doesn't want that if you use specific GPL versions.

This is an Apple problem, not FSF.


End user freedoms but not freedoms for the person who actually creates the code.


I don't know of anyone personally who is happy that Apple disallows GPL code.

And this is what you call a geek bubble. In the grand scheme of things most people don’t know what the GPL is and out of those, only a minority care about it running on their phone.


Most of my friends are not "geeks", and do not exist in the technological space that I do. I'm not speaking from within a bubble.


So you have friends that are not geeks who know about the GPL and care? This is the opposite of the “No True Scotsman”. Anyone who knows about and cares about the GPL is s geek.


> Anyone who knows about and cares about the GPL is s geek.

No, that would be a regular No True Scotsman.

> So you have friends that are not geeks who know about the GPL and care?

Did I say that? No, I didn't say that. I said I don't know anyone who is happy that Apple disallows GPL. This includes people who have no idea what the GPL is.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: