Hacker News Reader

Comment by kartan | Hacker News Reader

> Problem: The Firebase Android client library is proprietary, meaning FOSS apps can not use it. Apps that do not comply are reported to the user as "using too much battery".

This is a standard on the industry. From 1999: https://www.theregister.co.uk/1999/11/05/how_ms_played_the_i...

It doesn't matter how much money Google is going to have to pay in the future as a fine for this practice. The amount of money that they will get for kicking out the competition is going to be way higher. That is a learned lesson from Microsoft (and probably others before them).

View on HN

> It doesn't matter how much money Google is going to have to pay in the future as a fine for this practice. The amount of money that they will get for kicking out the competition is going to be way higher. That is a learned lesson from Microsoft (and probably others before them).

The competition in this case is Apples iOS, for which even HackerNews users love to harp over and over and over again how amazing it is and how little battery it uses because it doesn't allow apps to use anything but APNS, run anything in background or even include GPL source code.

This is what's Android competing against - an completely locked down operating system which cannot deliver any kind of GPL code. And every time it allows more freedom to developers it's punished in the market by losing against iOS and mocked on this very website about how it allowes their app developers to drain battery and access data.

What exactly do you expect Google to do here?

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.

The difference is Apple has been the same from the beginning. There was no bait and switch. People who bought Apple products knew what Apple was and will be and what the terms were.

With Google there is a bait and switch (and it doesn't really just apply to this particular story). They came to market defining themselves as the open alternative to Apple to get market share and developer interest (and evangelism), and now that they've achieved dominance the terms are changing.

There's no surprise that there's going to be massive pushback (and probably antitrust implications).

Exactly. We see the same pattern with Chrome and the new course it's taking.

The reverse is also true: whatever sufficiently good product that doesn't generate money is basically doomed by them no matter how many users depend on it. (Reader, Inbox, Talk, ...)

Apple has the majority market share in the US. I think they need to be forced to open up for alternative app stores.

This data says that Android is bigger.

https://www.statista.com/statistics/266572/market-share-held...

Who exactly is buying Android phones based on the premise of openness vs "they're cheaper", "it was a subsidized new phone from my carrier"?

Personally I've always bought Android (and while it lasted Firefox OS) phones because of the option to easily tinker with the phones. If/When pure linux phones make a come back I'll be moving on to them. Of course nerds being nerds is an outlier.

An ideal platform would use a foss compatible framework. It would allow the user to configure which server to use to push notifications(one server for all apps, since that is needed for battery reasons). Notifications would be encrypted with the apps key.

>allow the user to configure

This may be an ideal solution for you but its really not for most people.

That something is configurable doesn't negate the ability to have sane defaults that most people won't touch.

Often times even having configuration options creates surface for security issues.

A good example of this is that there were scams that involved having people paste some script into their chrome devtools and steal data. This worked fairly effectively. Facebook ended up doing some magic to show a warning message in the devtools console to tell people that no, you really shouldn't paste random stuff here, it will do bad things.

Configurability does come with a cost. And "the ability to reroute all push notifications through an arbitrary MITM" is a security cost that I expect wouldn't be worth it.

Is the solution to begin, to a degree, treating adults as children?

To answer the question shortly: Yes

But I actually think you are mis-portraying the situation is because I don't think the average adult has the ability to comprehend these things. It's not the difference between adults and children, but adults and expert adults.

Here are some analogies to other parts of society that we don't have a problem with:

Seat belt laws Hard hat required construction area Safety guideline in Handling of hazardous materials

We basically said society doesn't trust you to decide for yourself about your safety - you just have to follow the rule.

>It's not the difference between adults and children, but adults and expert adults.

Part of me wants to challenge the existing groupings of adults and children where all that matter is if you have been around the sun 18 times or not. This is but one weakness in the existing grouping that furthers my questions, such as why do we allow the non-expert adults a vote over laws, but deny a 17 year old the same?

I think if you take the groups of children, adults, and expert adults you will find upon reducing them to only two groups based on similarity that you are left with experts and non-experts.

Except a large portion of society thinks seat belt and hard hat laws are bullshit and shouldn't even be legal to enforce. Hazardous materials handling is completely different though.

Hence why I said encrypted.

The impulse to protect people from themselves is a dangerous one. In the article itself we see that in practice it is used to push inescapable spyware.

"But our spyware is better than their spyware!"

Google says they will protect you. But the truth is they are just concern trolling to shut down marginally worse competitors.

For kids and elderly that can't make decisions on their own it could be default -locked to some entity contractually bound to good ior. Locked with an administrator password. That would be a reasonable compromise.

Google actually released Capillary, which makes E2E encrypted FCM messages easier to implement: https://security.googleblog.com/2018/06/end-to-end-encryptio...

But yeah, if you want to avoid Google's servers, then it's not enough. But in that case, you're probably on Google-free LineageOS anyway right?

I very much doubt that Google is making the GCM push code proprietary for these reasons.

No the truth tends to be more banal - making everything replacable in configurable means more (paid) engineering work for Google engineers for what's, essentially, building infrastructure for competition. What would be the compelling business case for Google to do more work to enable removal of their own product?

This is possible to build on Android right now and something I've thought about myself. There is nothing stopping you or me from implementing it, and I've always thought that Amazon should have done it to make it easier to port applications into their ecosystem.

I use an iPhone currently but I'm wishing for an Android instead, precisely because Android allows some Free Software apps that have no equivalent for iPhone.

But yes, I agree, Android's competition is iOS and that's freaking sad.

Two things:

1. According to the reddit post the firebase library makes no difference to battery life

2. It is perfectly possible to provide strong guarantees around battery usage and resource consumption with open source code

I would like a choice between consistent and curated vs open and free with both respecting privacy.

Unfortunately, the choices today are limited.

Good thing Huawei is cut off, we might get some much needed options that are not tied to Google Play Services.

Have you considered those two groups aren’t the same?

I did, but then I'd expect the GPL group to actually comment with the same zeal on Apple articles... but Apple criticism seems very muted in comparison.

The GPL group has given up on Apple, whereas they adopted Android because it was pitched as an open source platform.

> What exactly do you expect Google to do here?

Let app developers and users have a choice.

That was exactly the state of the Android until 6.x or so and I've had multiple frustrating hours of mentoring Android developers on how to do notifications respectfully just to be ignored with "eh, I'll poll every 10 minutes, it's easy and it works!".

And this has been my experience constantly:

- "Eh, I'll just demand full storage access for my game, it's easier to unpack files in root of sd card" - "Eh, I'll just constantly reconnect HTTP no matter what the current device state is" - "Eh, I'll just download 600mb on mobile, it's easier than checking"

There are some developers that did right by users, but enough Android devs are constantly ignoring the best practices of development and users privacy because it's "easier" and requires less code.

Because of that I fully understand Google's new stance: developers haven't proven themselves trustworthy and it seems Apple's way is the only way to defend users against abuse.

I do believe you when you say a lot of devs are taking the easy way out and wasting device resources. But some devs do things right. And those devs are the ones being penalized. Perhaps worse, the user's choice of apps has been constrained.

It would have been so much better if the Play Store and SDK and Android platform could have features that clearly highlight these resource-hogging apps as bad actors. That's the kind of killer feature I expect from Google. I don't feel like they're living up to their reputation for hiring brilliant programmers. Instead they're taking out a really large hammer and hitting everyone with it.

Defending users by actively lying about battery usage is not acceptable. Battery meter in 8 was accurate and flagged battery eating apps accordingly. This new thing is actively lying when you don't use Firebase, as if nobody can ever correctly implement push notifications.

> This new thing is actively lying when you don't use Firebase

It is lying, alright.

That said, I don't think that this lying notification is the best example of Android designers being nefarious jerks. The notification lies to user about non-existing "battery drain", but it only does so when developer tries to get around the requirement to show notification with foreground Service. It is shown when you set notification to be hidden via low-priority. I have also seen it when notification icon was fully transparent. It is basically a retaliation against developer misconduct (when developer tries to run persistent background process without telling user). Ideally, this should encourage developers to show a proper foreground Service notification, which the user may consequently hide via notification settings.

I'm not sure what you're talking about exactly? What's the "new thing" in your post?

(Btw, the on-device battery meter is horribly inaccurate and always has been. Multiple values, like screen power use, are hardcoded by OEM and tracking app power use is not reliable in any case because those graphs are incapable of measuring cascading power efficienty effects coming from using the radio or Play Services.

Use Battery Historian if you want more useful battery use debugging.)

It's really really really hard to attribute battery usage correctly when it comes to push notifications.

So, if I understand correctly, the GPL prevents you from using a non-free library in your code? (Asking honestly: I have tried to find this elsewhere but the FSF page on the GPL is rather ... convoluted).

If that is so, then this is obviously a killer and quite seemingly arbitrary requirement. Your MS example is quite good.

The GPL requires that all code with the software under the license to also comply with the GPL, which includes libraries. Therefore, it's simply not possible (legally) to use non-GPL compatible libraries with GPL software. A lot of open-source licenses are compatible, such as the MIT or BSD license, but proprietary licenses are not obviously.

> A lot of open-source licenses are compatible, such as the MIT or BSD license

And, it should be noted, the LGPL license, which exists for exactly this purpose!

Could an argument be made that this falls into the system library exception?

Talk to a lawyer to be sure, but this would fall under the system library exception to the GPLv3 (though maybe not v2)

If you are the creator of the GPL software you can do what you like, link Firebase to it, distribute the app and release your code as GPL. You're effectively 'granting yourself' a proprietary license to use your code and a GPL license for everyone else to use it.

However it means nobody else can release their own apps (with notifications) on Android based on your code, or anyone else's GPL code. As soon as they link to Firebase and distribute they will violate the GPL by distributing a binary of someone else's GPL code with a proprietary library attached.

You cannot however use anyone else's GPL code while doing this, because those library authors didn't give you permission to relicense their code. It closes off the entire Play Store to the GPL. This is the same thing that caused the FSF to declare Apple's iTunes store as incompatible with the GPL. Curiously, I think the iTunes TOS clause that disallowed copyleft has since been removed, but I haven't heard anyone more qualified than I offer an opinion on whether you can now publish GPL iOS apps.

Yeah I'm confused too. I run an open source Android app used by a bunch of Universities, I'm not sure what this means? Surely you can still open source apps that use Firebase to send messages, you kind of don't have a choice.

I guess the question resides mainly on the GPL. Other licenses like BSD/MIT do not care what you do with the code or what you use to run it, AFAIK.

I don't get it. The Telegram GitHub says: "Since one can't use Google's push messaging in a FOSS app", but I can't work out why? Lots of FOSS apps on GitHub, mine included, use Firebase. It had never occurred to me it might be an issue.

If you use a gpl library, what you make with it must be distributed under the gpl.

You cannot distribute firebase blobs under the gpl. Ergo, you have used a gpl library to make something not gpl.

Which is illegal.

A GPL app can absolutely link to proprietary software and still be covered under the GPL.

From the GPLv3 itself.

> The “System Libraries” of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A “Major Component”, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it.

Now you can't just go and include random proprietary jars in your app for whatever reason but but linking to the jar for the purposes of using the system notifications and background services seems to me like it would definitely count.

But Firebase is not a "kernel", "window system", it is just third-party proprietary library (not essential part of Android as I understand).

I personally would consider notifications and the ability to run in the background to be essential but there's a better test which is the reason that this exception exists in the first place.

From copyleft.org:

> The system library exception is designed to allow copylefted software to link with these libraries when prohibition of that linking would hurt software freedom more than it would hurt proprietary software.

This is really the core of it -- who is hurt more by disallowing this linking: Google or FOSS apps?

As a daily reminder, this piece of junk will be countermanded by Samsung, Lenovo and Huawei and whoever deploys AOSP as they use their own push platforms.

That sort of wishy-washy legal foundation is why people are afraid of the GPL.

All law has a certain degree of human judgment involved.

Note the GPLv2 doesn't allow the exception to apply if the library is distributed with the app. GPLv3 doesn't draw a distinction between distributing with the app or linking to something already on the system. But IANAL.

How does Signal work around this, since it uses FCM and it is GPL licensed?

Thanks. That is what I wanted to know.

Your code is no longer completely FOSS when you do that. It depends on a binary blob that you can't see into.

Yes, yes, but I guess BSD-licence-using developers do not care too much about it.

You absolutely can do this - this is how the Nvidia shim driver works after all.

What you can't do is write code which depends on GPL, then distribute it with those GPL components and insist the resulting package is not GPL.

In fact, it's not so much 'dependent than derivative. GPL is a copyright license, and copyright restrictions can only only flow to derivative works.

Dependencies are different than source code. You can write FOSS that runs on Windows, which is a dependency and not FOSS.

As long as it doesn't require linking to a proprietary Windows library to interface with the NT api. That would violate at least the GPL 2. Though you could do it yourself, and release your own code as GPL (and the combined work as proprietary), no one else could distribute the full work under the GPL because of the incompatibility.

You can ship so long as it's not statically linked.

It should also be added that the whole backend is proprietary (and was for GCM as well) and is being maintained and paid for by Google.

Having said that, making firebase-messaging GPL-compatible library seems to be something that should make a lot of sense for Google to allow GPL apps to be released on the platform.

Probably LGPLing or MITing it, so closed-source apps can still use the library too.

Doh, yes, of course. Reworded the post :)

> Problem: The Firebase Android client library is proprietary, meaning FOSS apps can not use it. Apps that do not comply are reported to the user as "using too much battery".

This is simply not true. These two points don't even make a coherent argument, as it's plainly discernible that lots of apps don't use the Firebase Android client library but aren't "reported to the user".

Furthermore, "using too much battery" is not what the notification says. It simply says "is using battery", and even this is avoidable.

Windows 8.1 was absolutely determined to convince me that my brand new i5 was incompatible with Windows 8.1. MS hasn't stopped with the incompatibility garbage.

In a world where CPUs now require microcode updates to run securely, it's not very obvious that this is bad behavior.

Maybe erring on the side of safety here makes sense?

Reply on news.ycombinator.com