ITT: People making assumptions based off the tagline without reading the article
Basically not much changes, they’re just gonna wait to post their code until it’s done instead of letting it be viewed in progress
That’s a huge change. Reviewing one years’ worth of code at once is practically impossible, this significantly reduces the chances of a third party spotting malicious changes in the code.That’s already how it functionally worked for each major release
Here’s their previous strategy: https://web.archive.org/web/20220917195332/source.android.com/docs/setup/about/codelines
Google works internally on the next version of the Android platform and framework according to the product’s needs and goals
When the n+1th version is ready, it’s published to the public source tree
The source management strategy above includes a codeline that Google keeps private to focus attention on the current public version of Android.
We recognize that many contributors disagree with this approach and we respect their points of view. However, this is the approach we feel is best and the one we’ve chosen to implement for Android.
As far as I can tell, this would really only affect QPRs, since the public experimental branches that get made after they throw the next release over the wall is going away
oh, got it, thanks. feel so bad about people having read my incorrect comment haha
Meh, reasonable. Thanks for posting the clarification.
To summarize the article: they will deliberately open-source any updates several years later, or whenever they feel like, to ensure Stock Android is the only OS you use and new features available for people who pay Google money, which also includes security updates.
This is not at all a summary of the article. They’re moving to trunk-based dev to reduce merge conflicts coming in from the public on AOSP.
I don’t like it, because those few devs who contribute to AOSP without an agreement currently will have lagging code, but what you describe is just plain wrong. Is it possible? Sure. But it always has been, that doesn’t mean that’s what is happening.
Is it possible? Sure.
Even then, not really. Not legally, anyway. Open source licences require that the user be provided with the source code (if requested) alongside the binaries. If they roll out an update to Android (to code which is under an open source licence), they have to release the code at essentially the same time. Rolling out an update and then withholding the source code for an unnecessarily long time would be against the terms of the licence.
It’s an Apache license with a contributor agreement. At any point they could close source. People could fork from it at that point, but any new features/updates/breaking changed from then out would be behind the scenes. There’s no GPL poison pill in this one, I’m afraid.
Note: I don’t at all expect this extreme of a direction.
For as long as it’s still under the Apache licence, they’re still obligated to release the source under the terms of that licence. They’d need to change the licence to stop providing code; which as you say, they could do, but that would also kill AOSP entirely overnight so is a bit of a bigger problem than the one described in the OP.
Exactly. I don’t think they’d ever go down this road, but the big players like Samsung have agreements in place where they will continue to get access to
mainor some trunk. No reason they couldn’t change license and require all players to do the same thing, though O doubt that would happen given the massive security PR implications. So many Android devices would end up with vulnerabilities, tarnishing the image.There’s also just no real incentive for them to do it. The number of devices running fully de-googled Android forks are miniscule in the grand scheme of things. Everyone running devices with non-standard Android but which still uses Google Play Services and the rest are just as valuable to Google as the ones running stock. And it suits Google to have the small ultra-privacy hobbyist market still running Android forks, even de-googled ones, rather than moving on to something else entirely.
Good clarification. It’s also worth clarifying that choosing hidden trunk based development instead of public trunk based development makes it clear that community contributions aren’t one of their priorities.
Ahhh yes very very true. Also a great addition.
Is it possible? Yes
Is it likely given Corpo take over of civilization? Also yes…
Wow never would have I tought that a company releasing an Open Source project was only to privatized a few years later, how strange. Not like this has happened long ago and we already have a licence specifically made to counter this bullshit…
People does not understand why we specifically denote Free Software by their name and we do not aggregate them in the Open Source term. Companies always try to change the concepts of change to their own interests, they will always do. Adapting the free software to a much more controllable Open Source, not using GNU when has GNU, etc.
Small details that with time change the whole meaning of concepts.
Now we have a whole community of individual developers that have helped with Android development and which work will be wasted. Just because some intrinsic concepts about software freedom. Wasted resources that cannot be used anymore. Just as what happened with BSD and UNIX with the whole AT&T litigation and stuff. But with Android we already had the Free Software movement. I guess companies are so smart in making concepts for the most of the population.
Sounds like good news for mobile linux!
Right after Linux on desktop takes off, which is sure to happen any day now.
I don’t need desktop linux to “take off”, I’ve happily used it for a decade. I don’t need mobile linux to become mainstream. I just need it to be a bit better than it currently is.
time to switch to graphene or e/os?
graphene is a fork of stock android, so wouldn’t this affect them?
This is terrible news. I don’t think anyone can replace Google’s contributions.
We’ve had this fear about Unix and various database engines, in the past. But we managed.
How does this affect custom ROMs like lineageOS?
Platform developers, including those who build custom ROMs, will largely also see little change, since they typically base their work on specific tags or release branches, not the main AOSP branch. Similarly, companies that release forked AOSP products rarely use the main AOSP branch due to its inherent instability.
