It's because Fairphone doesn't fulfil GOS's hardware requirements. If Fairphone addresses that, there's no reason for GOS to not support a Fairphone device.
Device support code updated to new monthly, quarterly and yearly releases of AOSP within several months to provide new security improvements (Pixels receive these in the month they're released)
Fairphone's hardware and software is developed by a Chinese ODM (T2Mobile), who even have difficulty pushing out monthly patches very timely. They don't even do QPR2s, major Android updates are very late (usually almost a year), they rarely do driver firmware or kernel updates. There is no way they could fulfill this guarantee unless they started doing software development in-house and paid Qualcomm for monthly firmware updates.
Forking GOS and porting it to a new device is a huge and unreasonable ask for an individual user. Even less so when you include the fact that you'll need to keep it up to date.
I wonder if fable or astra could wire everything up.
You are dependent on Qualcomm for hardware firmware updates and apparently they charge quite a bit extra if you want continuous monthly security updates [1]. This is possibly one of the reasons that smaller OEMs like Fairphone do not update firmware regularly and instead choose to keep their customers vulnerable to many known CVEs.
> It's not as though we're talking about a device with hardware specs locked behind an NDA and drivers that only support outdated kernel versions.
Fairphone 5 and earlier have an end-of-life Linux kernel. Fairphone 6 is approaching the same fate. None of their devices keep up with the incomplete security backports to older releases, let alone the full security updates via new major releases. All of their devices are missing important hardware security features which should be standard. They're repeatedly said they don't consider any of this a significant issue and have no plans to significantly change it.
I didn't realize fairphone was stuck on an EoL kernel. I guess that means that even if the build can be made to work right now (far from certain given an old kernel) it would likely break in the future.
An OS without the core features and updates of GrapheneOS clearly isn't GrapheneOS. It's not permitted to refer to it as such.
> That's kind of the whole point of FOSS, right?
No, the point of FOSS is that you can take all of our code and use it for other purposes. Calling an incomplete port to another device GrapheneOS is misleading users. It isn't GrapheneOS and must have a unique name.
Honestly while grapheneos is a useful thing that I'm glad exists you're being absolutely insufferable.