Hacker News

Are you sure, I got one and I'm in Central Europe.

They did it for many years with 0 delay because they pushed the tags to AOSP. It was moved to Google Drive with a Google Forms setup to request access with manual fulfillment of the request. It was deliberately done to make it into a hassle. The delays are by design through making it a manual system regardless of how much of a delay was intended as part of this change. They could be automatically handling the requests especially from people who have already been given sources for a product. They're deliberately making it take substantially more work on their end to make it into more of a hassle.

A reasonable interpretation would be that they had a previous process that eliminated delivery latency and required no manual manpower for responding, so changing it has been done to induce artificial friction, against the intent of the license.

Not that the intent of a license can be enforced.

In the US? Under the current political and economic circumstances? Against Google's legal department? I wouldn't get my hopes up...

What will you purchase instead? It sucks that the modern smartphone OS market is a duopoly.

Only Pixels, most other device are ironically locked down a lot more (not allowing custom keys for verified boot) or lack modern security features (like hardware security modules).

So you'll have to wait for the mentioned Motorola Flagship

> they are making the source available

Not in the preferred form for modification expected by the build system and not in a reasonable amount of time. It's artificially delayed with no legitimate reason.

> And the number of people who buy new Pixels to immediately install GrapheneOS on them is (no offense) negligible

Nearly all of our current users bought a device specifically to install GrapheneOS. Our current userbase is around 500k and many of those are users had one or more earlier devices with GrapheneOS. Our userbase is rapidly growing. Look up how many Pixels are actually sold in a year. It's not negligible at all.

There are also many large companies wanting GrapheneOS devices with official support from the OEM.

> so you can't even realistically sue them

Genuinely asking: are you a lawyer?

Sounds to me that going from "it works easily and rapidly" to this deserves a big big fine. That's the only thing they understand.

what does the license say? provide source when asked or publish source?

OSI is not clear on this either. ("Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost, [...]")

GPL doesn't require them to publish the source in git. FWIW, Google can be compliant and publish the source in Physical Medium too if they opt too.

Also, the OP did mentioned that Google also squashed the git commit to a single commit for whatever reason.

No, and it doesn't even have to be provided for free as long as the price is reasonable with regard to the delivery costs. The GPL was made when mailing disks was a common way of delivering software and it is still a valid way to do it.

But the most important part is that once you have that source code, no one can stop you from redistributing it in a cheaper and more convenient way. It means that in theory, only a single person has to request the files, that person can then publish them in a public repository.

No. In fact, the GPL states that the actual cost of delivery can be charged (consider this is from times when people still post-mailed floppy disks).

As far as I understand, they could send it to you printed and bound and charge you for the paper and postage if they want to.

If distributing under 3(b) then it's legitimate to only supply source on request. Historically source has been distributed without revision control history or metadata and been considered acceptable (the source tarballs on gnu.org are snapshots, for instance) so I think the preferred form argument is also tricky. I agree that there's huge value in having the individual commits, but from a GPL perspective we had this argument when Red Hat started flattening all patches in the RHEL kernel source 15 years ago.

It's an impossible stretch and also a bad idea. Insisting on that interpretation opens up other issues. Revision history may not be available in some cases for various reasons, such as if one pays someone for a large contribution. We could get into arguments about how granular commits need to be to comply with publication requirements. Digital achives containing source code files are certainly customary and easy to use, as opposed to reams of printouts. It would be just as customary and modern to publish on CD and mail the stuff out to anyone who demands the code. Continuous or timely delivery is not guaranteed by the license. One week of wait time is actually reasonable for a process like this, though I expect it might gradually get worse in line with their long-term objective of making the entire thing painful for outside developers.

> We didn't have git tags when GPL was written in 1989

The GPLv2 requires "a medium customarily used for software interchange", not "a medium customarily used in 1989 for software interchange". Customs are the customs of the time someone is releasing the work.

GPL says we need to be provided with the preferred form for modification. Those are the Git repositories for Android source code.

For Pixel kernel drivers, Google is converting the source code from the preferred form of dozens of Git repositories to a massive monolithic tarball. The build system used for this code expects it to be a bunch of Git repositories and spews out errors without it. It does build the code but it isn't the build process they used to do it themselves which is non-compliance. We need to be provided with what is needed to build it in the same way they built it.

It's about the Pixel kernel drivers and build system. The source code for the base kernel tree itself is still part of AOSP. Everything related to Pixels is no longer being pushed to AOSP.

They stopped pushing tags for any of the Pixel kernel or userspace driver repositories to AOSP. They also stopped pushing AOSP releases specific to Pixels which is why AOSP now only gets yearly releases, QPR2 releases and security backports to both of those. Other OEMs are meant to use the yearly and QPR2 releases along with the security backports to those so that's all they push. The monthly and QPR1/QPR3 releases aren't used by their OEM partners so they stopped pushing them to AOSP. Those no longer being pushed is because of them deciding AOSP doesn't support Pixels anymore.

GitLab is MIT licensed, but also has also parts which are source available but not MIT licensed. Contributions to both are possible.

> The basic requirement is whether the source code is available - and made available. Are you certain that Google's solution here is ensuring that the source code is easily made available?

The word “easily” sure did sneak into this sentence

"And what exactly does that mean? I don't know what your words mean here. More source open than open source? Is that a tautology?"

I'm sure this means the source happens to be open rather than following the spirit of open source.

We said artificially delaying it for weeks or more is how they're violating it, not using Google Drive. It's also not provided in the preferred form for modification. It isn't in the form expected by the build system and causes it to not function in the way it did for their own builds.

It's paying a bill in pennies.

It can be also a temporary obstacle until they get rid of Linux kernel and replace it with kernel from Fuchsia or something.

Any inconveniences with Linux phones are less annoying to me than what Google is doing to AOSP. My next phone will run postmarketOS.

It doesn't apply to GrapheneOS.

Google's upcoming change means Google Mobile Services operating systems will show a warning for apps from unverified developers. Bypassing the warning will require a one-time 24 hour wait via the regular user interface. It can be immediately bypassed using Android Debug Bridge instead.

Developers with Play Store apps are already verified. It's counterproductive for app developers with existing Play Console accounts considered verified to refuse to register their apps distributed outside of the Play Store. That would encourage users to stick to the Play Store.

The problem is for developers without a Play Console account who would need to register and verify their identify to avoid their apps showing a warning. If people are already registered, they might as well list their apps distributed outside the Play Store to avoid the warning.

> Any word as to whether this will apply to GrapheneOS? If I had to choose, I'd block apps that did comply with this BS.

I doubt it, considering Android developer verification will go through Google Play Services, which GrapheneOS has siloed off from most of the OS as far as I'm aware.

The difference is that Apple always did it with iOS and Google did not. Many chose Android because of that.

I specifically use Android because of this, among other requirements, that Apple imposes on software development on their platform.

I do not own general purpose computers that I am not allowed to develop software for without permission. I have always avoided consoles for that reason as well (Steam Machine and other similar platforms would be fine, but I've been avoiding consoles for long enough that it's not something I really look for any more).

I was a major Apple fanboy up until the iPhone. Left the ecosystem after the iPhone and macOS started moving in that direction as well.

I'm going to miss having a smartphone that I can use with my banking and EV apps, but probably for the best to get out of Google's ecosystem. Hoping that GrapheneOS will still allow me to use some of the apps that I like.

Yes, and this is the reason that many of us have not, and will not, ever buy an Apple product. They are the ultimate technodictators, and their products are only for people who like to trade their freedom for moderate convenience.

Does it matter that Apple does the same?

> Doesn’t Apple do the same

yes and Apple does it for the 30% lock-in. Apple does it to protect their ecosystem. Apple also does not care about their customers, their developers, their suppliers or their employees. Closed systems do not help the populous. This is about money, captive audience and subscription revenues.

Did Apple claim iOS is open source?

Android is built on the linux kernel which uses GPLv2

GPL not defining a time limit to comply also doesn't mean there isn't a reasonable limit on compliance time. Google is more than capable of quickly complying. It comes down to whether a judge would think what they're doing is reasonable and we don't think they would.

The software also isn't in the preferred form for modification. The build system which runs Git commands and doesn't work as intended without it. You have to make a Git repository for it to work and there's meant to be a separate one for each separate component. It spews out errors.

I mean, the only way to test this is to require of Google here to release the source code. And then look at how a court will evaluate it. For instance, what if Google never sends the source code? What if they claim that no request made it in? Though I guess this can be ensured, e. g. via letter that is registered being sent and then looking at Google's response to it.

So right now I think we all probably do not know. Google MIGHT refuse to release the source code, but it could release it - we don't know yet. Someone has to test that.

But google already built a tool to do exactly that: https://github.com/google/copybara

> I don't think they are?

If filling out the source code request form via Google Forms and/or accessing the download link via Google Drive requires the requester to run non-free (or at least non-GPLv2) JavaScript, then maybe it is in violation of section 6 of the GPLv2 ("You may not impose any further restrictions on the recipients' exercise of the rights granted herein") since the requester is then required to accept an entirely different set of licensing terms and conditions.

There's an easy way to put them into compliance violation:

Get a large brigade of android users to request access to source on each security update.

I assume Linux.

I am very thankful linux is gpl. Because of GPL these tech giants are forced to release source code.

> How slow is "very slow?" The answer can be found two replies after: > Initially, Google would usually provide access to the tarballs within a couple hours. Lately, they're often taking weeks to get back to us. They're the ones who chose to use this archaic system instead of pushing Git tags and it's their responsibility to handle requests promptly.

> What is "certain source code"? The OP seems to be GrapheneOS, which heavy patches AOSP. I guess the context is Android source code and its security patches.

> Why is the OP being so coy about describing the problem? Not sure what you mean, I think they are explicit enough. I guess it's clear enough for developers how an upstream update should go. If people depend on big projects like AOSP, devs should be prompt in delivering source code, especially when it is mandatory by license.

Can you give us more details on how/why you think the OP is being coy?

It applies to anything Google releases based on Android without pushing tags to AOSP for that fork of the code. It isn't a limited set of products but rather everything they make based on it. It applies to Android Wear, Android TV, Pixel phones and anything else not pushed to AOSP. We aren't being specific since we don't know everything they release based on Android. If they release a Beta emulator image for an upcoming version of Android without pushing tags, it applies to that too.

Google used to push all of the Pixel code from AOSP to it every month. They now only push AOSP releases intended to be used by other OEMs. That means they went from pushing each monthly, quarterly and yearly release of Android shipped by Pixels to only pushing 2 major releases per year (yearly release and QPR2) which are the only major releases used by other OEMs. They also provide security backports to those 2 major releases. They're still obligated to give us the GPL/LGPL licensed code for each Pixel OS release.

Google sold the Pixel 6 through Pixel 9a as being AOSP reference devices with 5-7 years of support from launch. They should be pushing the AOSP releases for those devices each month to fulfill their update commitment. GPL compliance is a clear legal requirement, but we think there's more than that too. Pixel 10 and later were not launched as AOSP reference devices since this changed was already made, so sure they have no obligation to provide anything beyond GPL code for those.

We didn't want to explain all this in our thread but we did explain it has to do with Pixels. It isn't only the kernel drivers. It's also the assorted set of stuff within the OS that's GPL/LGPL beyond that. There's more than there used to be since they moved to the OpenJDK libraries during the Oracle lawsuit.

>Both. Google has plenty of government contracts, they are undoubtedly pushing for more surveillance,

I don't get it, are the government contracts somehow contingent on them oppressing users and stifling open source?

>we are now in an age where users can create their own apps to do whatever they want within a few hours, sothis risks their Google Play Store profits

If that's the reason, they're doing a pretty poor job, since it's trivially bypassable by running "adb install".

It's not AOSP but rather Pixels. Pixels are no longer support by AOSP. They went out of the way to no longer push any of the Pixel specific repositories or releases to AOSP. The impact is mainly that Pixels are now harder to support than a lot of other devices rather than easier. They'll sell far fewer Pixels over time because of these decisions.

https://news.ycombinator.com/item?id=49369087

So all the non-pixel-specific stuff is in a publicly accessible repo? So the pixel team just decided that they wanted to keep their kimono mostly closed?

GrapheneOS

HarmonyOS?

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_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.

Yes, but that person still needs to file a request and wait several days

Seriously, if we keep this up they'll be sending us pallets of punch cards before you know it.