5 ms·

Disgusting move by Google to further reign in what hardware and software you can use, how you use it and how quickly you have to upgrade your device. If they o

by 0xedd 4y ago

Disgusting move by Google to further reign in what hardware and software you can use, how you use it and how quickly you have to upgrade your device. If they only wanted to cut ties with Oracle Java and have an unrelated OS, they'd adapt Linux. A number of companies are already working on it. But, that won't let Google own the entire chain from hardware to software in order to screw over customers. Zero innovations in the mobile world for easily a decade. Because companies like Google are too busy running VMs on mobile.

shakna 4y ago
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.
- chasil 4y ago
  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.
  - wmf 4y ago
    Yes, no, and this is beyond SFC. Linus himself authorized proprietary kernel modules decades ago.
    - chasil 4y ago
      That scoundrel! :)
    - TingPing 4y ago
      Linus is only one copyright holder. Only a court can decide that.
      - pabs3 4y ago
        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 https://sfconservancy.org/copyleft-compliance/vizio.html
  - klodolph 4y ago
    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.
    - yjftsjthsd-h 4y ago
      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).
- josephcsible 4y ago
  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?
  - ryukafalz 4y ago
    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.
    - tga_d 4y ago
      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.
      - bpye 4y ago
        Licensing terms that have some financial penalty if the device does not receive security updates for the full term?
  - shakna 4y ago
    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.
- smegger001 4y ago
  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.
  - foota 4y ago
    They're already getting in trouble for licensing restrictions, this probably wouldn't help.
  - azurezyq 4y ago
    Then there'll be a forked Android ecosystem from AOSP.
    - smegger001 4y ago
      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.
  - raggi 4y ago
    Getting patches sent upstream isn't a big problem. Patches that are acceptable to and accepted by upstream is a different story.
  - smashed 4y ago
    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).
- jiggunjer 4y ago
  Wasn't project treble the name of their policy to keep a stable ABI?
  - pjmlp 4y ago
    Kind of, OEMs aren't forced to provide Treble updates, so everything stayed the same.
- pjmlp 4y ago
  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.
- dm319 4y ago
  If the issue is just a stable ABI, why not just fork linux and maintain a stable ABI?
  - neilalexander 4y ago
    https://xkcd.com/927 https://xkcd.com/927
chasil 4y ago
As far as I know, OpenJDK is unencumbered by commercial license concerns; I think it is GPL. The last time I looked, RedHat was packaging a version for Windows. Yes, my corporate IT stagers won't use it, but the Java corporate licenses are not as necessary as you might think.

by 0xedd 4y ago

shakna 4y ago

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.

chasil 4y ago
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.
- wmf 4y ago
  Yes, no, and this is beyond SFC. Linus himself authorized proprietary kernel modules decades ago.
  - chasil 4y ago
    That scoundrel! :)
  - TingPing 4y ago
    Linus is only one copyright holder. Only a court can decide that.
    - pabs3 4y ago
      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 https://sfconservancy.org/copyleft-compliance/vizio.html
- klodolph 4y ago
  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.
  - yjftsjthsd-h 4y ago
    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).
josephcsible 4y ago
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?
- ryukafalz 4y ago
  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.
  - tga_d 4y ago
    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.
    - bpye 4y ago
      Licensing terms that have some financial penalty if the device does not receive security updates for the full term?
- shakna 4y ago
  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.
smegger001 4y ago
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.
- foota 4y ago
  They're already getting in trouble for licensing restrictions, this probably wouldn't help.
- azurezyq 4y ago
  Then there'll be a forked Android ecosystem from AOSP.
  - smegger001 4y ago
    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.
- raggi 4y ago
  Getting patches sent upstream isn't a big problem. Patches that are acceptable to and accepted by upstream is a different story.
- smashed 4y ago
  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).
jiggunjer 4y ago
Wasn't project treble the name of their policy to keep a stable ABI?
- pjmlp 4y ago
  Kind of, OEMs aren't forced to provide Treble updates, so everything stayed the same.
pjmlp 4y ago
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.
dm319 4y ago
If the issue is just a stable ABI, why not just fork linux and maintain a stable ABI?
- neilalexander 4y ago
  https://xkcd.com/927 https://xkcd.com/927

chasil 4y ago

As far as I know, OpenJDK is unencumbered by commercial license concerns; I think it is GPL. The last time I looked, RedHat was packaging a version for Windows. Yes, my corporate IT stagers won't use it, but the Java corporate licenses are not as necessary as you might think.