3 ms·

If you're like me and struggled to parse the title, my understanding is, "To obtain certain source code from Google, you could previously reference git tags, bu

by hatthew 1mo ago

If you're like me and struggled to parse the title, my understanding is, "To obtain certain source code from Google, you could previously reference git tags, but now you have to fill out a form and wait for a human to give you a google drive link."

aleph_minus_one 1mo ago
> "To obtain certain source code from Google, you could previously reference git tags, but now you have to fill out a form and wait for a human to give you a google drive link." Couldn't simply someone mirror these Google Drive folders?
- mjg59 1mo ago
  Yes, but that person still needs to file a request and wait several days
  - aleph_minus_one 1mo ago
    But after one person does this, the source code access is a solved problem.
    - mjg59 1mo ago
      But nobody has done this, which is why it's a problem for Graphene
      - beanjuiceII 1mo ago
        Maybe should someone should do it then?
        mjg59 1mo ago
        They are, which is how they know how long it's taking.
        gruez 1mo ago
        Submitting the form isn't too hard, so there's not much to be gained by getting a non-affiliated volunteer to do it. Also if they're not the ones requesting it, it becomes hard to ascertain the authenticity of the links (eg. it doesn't contain a backdoored kernel).
    - urbnspacecowboy 1mo ago
      No it's not, because "one person" has to keep sitting up and begging for access, every time there's a new release, over and over and over and over and over.
      - petre 1mo ago
        Maybe we colld getan AI agent to pester them with forms?
        voakbasda 1mo ago
        What consequences do you imagine if they (rightfully) choose to ignore it?
  - grapheneos 1mo ago
    It was initially taking under a business day for them to respond, but our recent requests have often taken weeks for them to get back to us. We want the code for all the Beta releases and are entitled to it. This is the relevant code for Android 17: https://gitlab.com/grapheneos/kernel_pixel/-/tree/17-base https://gitlab.com/grapheneos/kernel_pixel/-/tree/17-base https://gitlab.com/grapheneos/kernel_pixel_muzel/-/tree/17-base https://gitlab.com/grapheneos/kernel_pixel_muzel/-/tree/17-b... There are other branches there with it for Android 17 QPR1 Beta and Android 17 QPR2 Beta. Google could save everyone including themselves a lot of hassle by simply publishing it to GitHub. If they don't want to push it to AOSP for weird organizational reasons as part of saying AOSP doesn't support Pixels, fine. Taking weeks or more to get back to us isn't reasonable for one the largest tech companies in the world. It's also questionable whether what they're providing is truly the preferred form for modification considering the build system is quite unhappy about the lack of Git repositories. They had to provide a repo manifest metadata file to work around part of it.
    - mjg59 1mo ago
      I wholeheartedly agree. Making it more difficult to obtain GPLed source code than it was before is fundamentally a dick move.
      - grapheneos 1mo ago
        It also isn't only them pushing the boundaries of the GPL. Pixel 9a and earlier were sold as the official Android Open Source Project (AOSP) reference devices. They made a commitment to providing 7 years of updates for the Pixel 8 and later. Android 16 declared Pixels were no longer AOSP reference devices and stopped providing any support for them. From our perspective, Google hasn't fulfilled their update commitment for the Pixel 6 through Pixel 9a. It's fair to say the Pixel 10 and later weren't sold as AOSP reference devices and didn't have any commitment to providing sources as part of the updates, but that isn't the case for the earlier devices.
- grapheneos 1mo ago
  Yes, and we do mirror their source code on GitLab. We put the upstream 17 code in the 17-base branch and our code on top of it in the 17 branch: https://gitlab.com/grapheneos/kernel_pixel/-/tree/17-base https://gitlab.com/grapheneos/kernel_pixel/-/tree/17-base https://gitlab.com/grapheneos/kernel_pixel_muzel/-/tree/17-base https://gitlab.com/grapheneos/kernel_pixel_muzel/-/tree/17-b... We also have mirrors of the QPR1 Beta and QPR2 Beta code there too. It's not meant to be distributed as a tarball or a single Git repository. The build system runs Git commands to determine the revisions of each component. It's supposed to be in dozens of Git repositories. They provide repo metadata as part of the tarballs on Google Drive which you can see there but it's not a full replacement for the Git repository layout expected by builds. It's somewhat convenient having it in a monorepo but it's not the way it's meant to be and the build system makes it clear that it isn't happy about it despite running. It would be nice if Google would simply push it to the Git repositories still available on AOSP again. The repositories still exist both internally and publicly but they're making it a hassle instead of simply pushing tags. We publicly complained about these and other Pixel changes as they were ongoing and that directly led to our Motorola partnership. It was in Google's financial interest to work with us so we continue using Pixels and that's still the case. They're welcome to reach out to us and start collaborating again. We made a lot of upstream contributions and aren't their enemy. Google should want more people to use their devices, apps and services. It shows how heavily they're violating antitrust laws by using monopolies to protect other monopolies when they sacrifice revenue for their devices and apps/services for it.
  - hedora 1mo ago
    Doesn't their change break supply chain security on Google's end? With git tags, presumably people spoke in terms of cryptographic hashes. Now what prevents them from serving different Google drive contents to different accounts?
    - CBLT 1mo ago
      It doesn't break supply chain security for anybody with power to change the situation.

by hatthew 1mo ago

aleph_minus_one 1mo ago

> "To obtain certain source code from Google, you could previously reference git tags, but now you have to fill out a form and wait for a human to give you a google drive link." Couldn't simply someone mirror these Google Drive folders?

mjg59 1mo ago
Yes, but that person still needs to file a request and wait several days
- aleph_minus_one 1mo ago
  But after one person does this, the source code access is a solved problem.
  - mjg59 1mo ago
    But nobody has done this, which is why it's a problem for Graphene
    - beanjuiceII 1mo ago
      Maybe should someone should do it then?
      - mjg59 1mo ago
        They are, which is how they know how long it's taking.
      - gruez 1mo ago
        Submitting the form isn't too hard, so there's not much to be gained by getting a non-affiliated volunteer to do it. Also if they're not the ones requesting it, it becomes hard to ascertain the authenticity of the links (eg. it doesn't contain a backdoored kernel).
  - urbnspacecowboy 1mo ago
    No it's not, because "one person" has to keep sitting up and begging for access, every time there's a new release, over and over and over and over and over.
    - petre 1mo ago
      Maybe we colld getan AI agent to pester them with forms?
      - voakbasda 1mo ago
        What consequences do you imagine if they (rightfully) choose to ignore it?
- grapheneos 1mo ago
  It was initially taking under a business day for them to respond, but our recent requests have often taken weeks for them to get back to us. We want the code for all the Beta releases and are entitled to it. This is the relevant code for Android 17: https://gitlab.com/grapheneos/kernel_pixel/-/tree/17-base https://gitlab.com/grapheneos/kernel_pixel/-/tree/17-base https://gitlab.com/grapheneos/kernel_pixel_muzel/-/tree/17-base https://gitlab.com/grapheneos/kernel_pixel_muzel/-/tree/17-b... There are other branches there with it for Android 17 QPR1 Beta and Android 17 QPR2 Beta. Google could save everyone including themselves a lot of hassle by simply publishing it to GitHub. If they don't want to push it to AOSP for weird organizational reasons as part of saying AOSP doesn't support Pixels, fine. Taking weeks or more to get back to us isn't reasonable for one the largest tech companies in the world. It's also questionable whether what they're providing is truly the preferred form for modification considering the build system is quite unhappy about the lack of Git repositories. They had to provide a repo manifest metadata file to work around part of it.
  - mjg59 1mo ago
    I wholeheartedly agree. Making it more difficult to obtain GPLed source code than it was before is fundamentally a dick move.
    - grapheneos 1mo ago
      It also isn't only them pushing the boundaries of the GPL. Pixel 9a and earlier were sold as the official Android Open Source Project (AOSP) reference devices. They made a commitment to providing 7 years of updates for the Pixel 8 and later. Android 16 declared Pixels were no longer AOSP reference devices and stopped providing any support for them. From our perspective, Google hasn't fulfilled their update commitment for the Pixel 6 through Pixel 9a. It's fair to say the Pixel 10 and later weren't sold as AOSP reference devices and didn't have any commitment to providing sources as part of the updates, but that isn't the case for the earlier devices.
grapheneos 1mo ago
Yes, and we do mirror their source code on GitLab. We put the upstream 17 code in the 17-base branch and our code on top of it in the 17 branch: https://gitlab.com/grapheneos/kernel_pixel/-/tree/17-base https://gitlab.com/grapheneos/kernel_pixel/-/tree/17-base https://gitlab.com/grapheneos/kernel_pixel_muzel/-/tree/17-base https://gitlab.com/grapheneos/kernel_pixel_muzel/-/tree/17-b... We also have mirrors of the QPR1 Beta and QPR2 Beta code there too. It's not meant to be distributed as a tarball or a single Git repository. The build system runs Git commands to determine the revisions of each component. It's supposed to be in dozens of Git repositories. They provide repo metadata as part of the tarballs on Google Drive which you can see there but it's not a full replacement for the Git repository layout expected by builds. It's somewhat convenient having it in a monorepo but it's not the way it's meant to be and the build system makes it clear that it isn't happy about it despite running. It would be nice if Google would simply push it to the Git repositories still available on AOSP again. The repositories still exist both internally and publicly but they're making it a hassle instead of simply pushing tags. We publicly complained about these and other Pixel changes as they were ongoing and that directly led to our Motorola partnership. It was in Google's financial interest to work with us so we continue using Pixels and that's still the case. They're welcome to reach out to us and start collaborating again. We made a lot of upstream contributions and aren't their enemy. Google should want more people to use their devices, apps and services. It shows how heavily they're violating antitrust laws by using monopolies to protect other monopolies when they sacrifice revenue for their devices and apps/services for it.
- hedora 1mo ago
  Doesn't their change break supply chain security on Google's end? With git tags, presumably people spoke in terms of cryptographic hashes. Now what prevents them from serving different Google drive contents to different accounts?
  - CBLT 1mo ago
    It doesn't break supply chain security for anybody with power to change the situation.