And as an OEM, you have the sources for those libraries. It's not the same situation as ripping them from the factory images of another vendor. They don't just get a package of binaries. They get a source tree to build the vendor image which is a mix of open source and NDA repos.
Conversation
Years ago, OEMs even got the source code for the Qualcomm baseband, but they stopped sharing it and allowing modifications. Anyways, SoC vendor choice becomes something in our control if we have our own hardware. It doesn't have to stay the same between generations either.
1
1
We can choose what we think is the least bad compromise and then that choice can change as the situation changes. We hardly have any issues AOSP and it has rapidly improving privacy/security itself. Our issues are with the OEMs (Google as the Pixel OEM) and their hw vendors.
1
1
I don't think targeting devices made by other vendors is viable in the long-term. I haven't thought it was viable after the first couple years working on this in 2014-2015. I quickly realized having our own hardware was crucial. If my business partner hadn't been a sociopathic
1
1
narcissist solely interested in making money via the path of least resistance and with no concern for ethics, perhaps we'd already be in the position where we'd have our own hardware platform. I do not really see much of a path forward ATM. I continue because I have to continue.
1
1
Need a hardware vendor that is security focused and wants to support AOSP with open source drivers. Not going to get that from Purism or Pine64. It will be even harder to accomplish anything of value and provide a secure phone that way. Doesn't get any closer to controlling own
1
1
destiny and not depending on incredibly flawed OEMs with incompatible goals. You're treating the device being made with using open source drivers as a core goal as if that's the hardest and most important aspect. It's one of many aspects, and is far from the hardest thing to do.
2
1
I am not saying purism/Librem5 should be the end goal but I think they are the current best case studies of small companies pulling off open-source-first hardware being very transparent about the process which is huge.
Gotta crawl before you can walk.
1
I don't see it that way at all. They're incredibly dishonest, not at all transparent, and do not really have the goal of making open hardware. They are explicitly anti-security and anti-privacy in many ways too. It's not a good hardware target and they won't ever make a good one.
2
1
They do not share the goals or concepts of GrapheneOS at all. It is a bad target, they will always make bad targets for it, and they are not a viable partner or collaborator with an actual privacy/security focused project. Been burned already, others have too. No thanks.
2
1
You're bringing it up at the same time as Pine64 which has similar technical issues but without nonsense from the company / leadership including lots of harm. It's also a bad target, with no sign of ever wanting to make a good one, but at least they don't lie and cause harm.
IMO Librem5 has better hardware but the marketing and misrepresentation of it is a black eye to be sure.
Still if forced to pick between them or Google right -now- while we spend a few years making long-term sustainable/secure hardware I take Purism.
2
Right now we have to pick reverse engineering around a massive survelliance cspatilisim company vs a company with dishonest marketing that at least has a fully open source reference that boots and works.
I'll gladly take the latter in the very short term.