Hacker News Reader

Comment by shakna | Hacker News Reader

The bigger problem of Linux for Google is that:

a) Linux doesn't have a stable driver ABI.

b) Manufacturers will not upstream their drivers. It's been years and they simply won't.

Google have been beating against this for years and getting absolutely nowhere. It's the same thing that Linux has ongoing issues with, and have made significant inroads with, for things that aren't tablets or phones. But manufacturers do not want their drivers to be public.

The reasons no longer matter, decades of compromise has resulted in the hardware partners shifting not a single ioata.

View on HN

couldn't Google issue a statement that as of date X any new android licening agreement will stipulate that manufactures release the drivers source code and submit them to the Linux kernel team and threaten to revoke access to the google marketplace and other google services if they don't release the drivers. the manufacturers lost the leverage when they switched to android and the other major non iOS mobile os's died (palm, blackberry, whatever it was call mozilia tried ubuntu mobile etc). now there is only a market for android and ios with sub 1% other.

They're already getting in trouble for licensing restrictions, this probably wouldn't help.

Then there'll be a forked Android ecosystem from AOSP.

there already are but unless you have the CPP forcing its use no one will use it as the apps arent there. googles now go the smae vendor lock in that MS does wit windows. no one will wan to pay for all their apps again on another platform.

Getting patches sent upstream isn't a big problem.

Patches that are acceptable to and accepted by upstream is a different story.

It's not only about releasing the "driver".

It's committing the time and resources to get it in a good enough shape to at the very least be submitted upstream.

Embedded device drivers are often developed by cutting a lot of corners, copy-pasting huge amount of code, using magic register addresses that are undocumented and targetting old kernel versions.

Even if they make the code available, there is not much the kernel maintainers can do.

By the time the device hits the market, the driver developers have moved on to the next project in the pipeline. There is never the time to clean up, rebase on top of master, submit upstream properly, and address code review (of you are lucky to get a maintainer to even look at your code).

Why would Google being risky when they can develop a new OS instead?

They had that opportunity with Treble and decided not to enforce it.

Couldn't Google force (b) relatively easily by saying that starting at some date in the near future, newly released phones are only allowed to ship with GApps if all of their drivers are upstreamed?

IMO a better/more subtle option: mandate at least 5-7 years of security patches for each device including for the kernel. Manufacturers will figure out real quick that their current practices are unsustainable in the long run.

Not better because I don’t think the drivers should be upstreamed, to be clear. Better because it leads the manufacturers to that conclusion on their own.

How do you mandate future behavior? If the device shipped, it shipped, and if Google revokes the Play license four years from now when security patches still haven't been applied, what does the company care? The phones are already sold, Play services aren't going to uninstall themselves, and they can claim they pinky swear to do it this time. Google's only recourse at that point would be to cut out their own market share with no real path to settling the dispute (how can you tell if this time Samsung or whoever will follow through?). At least with a simple upstream requirement, there's an immediate resolution: you can ship the phones with Play once you're done with the upstream merges. Not saying that's in any way likely to happen -- making your terms contingent on the whims of Linus Torvalds does not sounds like a wise strategy IMO -- but it at least makes more sense than after-the-fact requirements.

Licensing terms that have some financial penalty if the device does not receive security updates for the full term?

The more likely scenario is Samsung and others running on their own, in that case. They already have their own store, and crap clones of many Gapps.

Google has suggested that they were leaning in that direction in the past, and the response was not encouraging. Think about how many manufacturers don't ever release updates. The software is seen as a neccesary evil, not as part of the marketing equation.

> The more likely scenario is Samsung and others running on their own, in that case. They already have their own store, and crap clones of many Gapps.

Consider the usual suite of apps that need SafetyNet to work (Snapchat, Netflix, Pokemon Go, Super Mario Run, McDonald's, etc.), then throw in a few more that need Google Play Services for some reason, and don't even work with microG (Hyundai BlueLink, EnelX JuicePass, Lime, PayPal, Roblox, etc.), and there'd be a lot of unhappy customers who want to use those apps but can't.

Yes... But these companies are still unlikely to give a damn. Software is an expense. It isn't seen as a value add, which is also why you won't see software in any of their advertising.

If the ecosystem is large enough, app developers will be motivated to support Samsung's counterparts of SafetyNet.

> The more likely scenario is Samsung and others running on their own, in that case. They already have their own store, and crap clones of many Gapps.

And did that work for... anyone? Ever? At all?

No. There is no contract with upstream Linux. Patches existing does not mean they're accepted by upstream.

They'd just be sued for monopolistic practices (again)

Are these kernel modules?

Doesn't modprobe/insmod of a driver bring it into a strict GPLv2 environment?

If so, the Software Freedom Conservancy needs to "busybox" the recalcitrant OEMs.

Yes, no, and this is beyond SFC. Linus himself authorized proprietary kernel modules decades ago.

That scoundrel! :)

Linus is only one copyright holder. Only a court can decide that.

If Conservancy win their latest court case, you wouldn't even need to be a copyright holder to sue for GPL compliance.

https://sfconservancy.org/copyleft-compliance/vizio.html

One problem here is the difference between “complies with GPLv2” and “upstream”.

I can dump a bunch of ugly driver code into an old version of Linux, backport some features that I care about from newer kernel versions, and then give you a tarball with the sources and a GPLv2 license. Is that compliant? Yes. Is it gonna get upstreamed? No.

Exactly; it's my understanding at least that most vendors do release their code - it's just that the code tends to be awful and will never get upstreamed as-is, so it's not as useful as you might wish. Still has some value, still complies with the GPL, but nowhere near "lets the phone run on mainline Linux" (which is super rare except for IIRC some Sony phones).

Wasn't project treble the name of their policy to keep a stable ABI?

Kind of, OEMs aren't forced to provide Treble updates, so everything stayed the same.

Let's not forget, when Google introduced Project Treble they made it optional for OEMs to actually push updates of Treble drivers anyway, so they didn't.

If the issue is just a stable ABI, why not just fork linux and maintain a stable ABI?

https://xkcd.com/927

Reply on news.ycombinator.com