As described by @JeroenH already: The blobs are for drivers and other functionality and has nothing to do with Google.
This is only āhalfā true, but hard to track down. If you compare the software licences ā¦ (something that is not debated here a lot) ā¦ the bin blobs even for the ānon-Googleā FP2 have the same āGoogleā licences as other Google phones, wording-wise. So I think in the background, Google with their CTS program ā¦ is still āpullingā the strings and making such a licence mandatory. Such as the āMobile Application Distribution Agreementā.
But this is just a guess based on how all the licenses are written. Just check yourself.
Else, I agree with you. Google should not care about the bin bobs. But funny enough all Google roms and bin blobs are āprotectedā by the same license.
I guess as a vendor you can either open source your driver ā¦ or go under the āGoogleā umbrella. This makes it easier for multiples vendor to agree on the same (=most strict) licence so Google is able to pack the roms at all, I guess.
@fp1_wo_sw_updates, I donāt quite understand your post. You might have some key parts of the release process wrong.
Google doesnāt pack the ROMs. The manufacturers pack and release ROMs. Google is only involved in releasing Android source code and maybe testing whether the ROM complies with their license if the ROM includes their services.
Iām sure I do. Thanks for helping me. The problem is, that this process is not described anywhere. I think it works like this:
- There is a ODM that has a contract with a SoC manufacturer.
- This ODM designs a device together with the client based on the SoC manufacturer he works with and the clients ideas
- The ODM agrees to NDAs with other hardware vendors to add non-SoC manufacturer hardware.
- The ODM builds a roughly working Android version and ships it to the client (and Google if wanted for their services)
- The client again modifies the code again if needed (and shipped to Google for testing if it comes with their services)
- The phone and the āGoogle-testedā code/rom is shipped.
The funny thing is, if you compare licences (for the bin blobs, even for the non-Google code) all the Android/bin blob licences look the same. This text comes from Google. Without this text and licences, you will not get a āpowered by Androidā device.
But you are right ā¦ all this stuff Iām just assuming because not a lot about it is published.
Google is not really my problem. Itās the license and that nobody really knows anything about the bin blobs. What I dislike in the end is:
- There is no Changelog for the bin blobs (Who āpacksā those? Is it the ODM, FP?)
- There is no way to switch to more stuff from the mainline kernel, even if features are supported because the ODM prefers an older version that works better for them and the other vendors (as far as I understand the whole thing)
- You cannot offer fixed roms for āfreeā to others or experiment with different setups, build roms is a big waste energy.
- The OpenOS rom build is left behind, but in reality, it is the ābetterā rom. It could also be much easy to debug (if the code/debug settings would be shared).
I donāt know the details of the process either (and we are getting off-topic in any case).
The parts I (think I) do know are:
- Google releases Androide source
- SoC manufacturer adds SoC specific changes (this is Qualcomm in our case)
- ODM* (this is Hi-Pi and/or Fairphone in our case) gets source and license from SoC manufacturer to adapt this to a device.
- The source includes open parts (e.g. AOSP code) and proprietary binaries (e.g. device firmware).
- A working Android ROM can get built from this (e.g. Fairphone Open OS).
- CTS tests are part of AOSP and this ROM can be tested against CTS.
- ODM agrees with Google to license Google Services.
- ODM packs Google Services with ROM (e.g. Fairphone OS).
- This ROM gets sent to someone to run a separate set of tests to verify that the build complies with the license Google gave to include Google Services.
- ODM releases ROM as an update.
*I guess this means original device manufacturer. I use it as if it means this 
Regarding the license: I wouldnāt read to much into that. Just because someone releases code under an Apache license does not mean that the code is owned by Apache. Just because someone releases code under a MIT license does not mean they are researchers at MIT. Just because someone releases code under a Mozilla license ā¦ you get it.
(and you keep on updating your post while Iām answering it 
)
It doesnāt matter who packs those. Apparently Fairphone cannot or must not look into them.
There is a way. Only, it is a lot of work to rebase the code.
Iāve always argued on the forum that community members that build should just share their stuff. If someone really has something against it, those parties will let us know. I deem this very unlikely.
Why is it left behind. Doesnāt it get all the bug fixes and releases as the other ROM?
1 Like
Thanks, that looks pretty good. I agree Iām sorry for the updates, I tried to make myself more clear.
For Qualcomm? I think QC and Sony have already done this for the Snapdragon line. Or are you talking about FP (the software from Portugal/launcher) or the other bin blob vendors?
This would mean they wouldnāt be able to debug issues without the ODM.
Iām not going to test this, not under this licence. The code builds here for me. And itās easy enough for me to fix the small ādifferent versions of softwareā glitches that occur.
I hope so. Iām talking about the release of the OpenOS rom. Itās published later, but it is the āeasierā part (no google tests needed) and the code is already āthereā.
Update for the on-topic-context: Just to get back to āconvergenceā ā¦ I think a lot of the āthin clientā code for smart phones is proprietary and if at all ā¦ lives somewhere at the SoC/Graphics level with some DRM. The best solution for a working ālaptop-phoneā would be a open graphics unit that is able could exchange data quickly through an unrestricted interface. This is something most content sellers will not like.