Thats clearly not what the OP is suggesting as per "Why do we have to have /e/OS instead of a better supported LineageOS, because /e/ is a 1:1 copy anyways?". Both cases are android. /e/OS is not librephone.
There's little point in "partnering" with postmarketOS, because the project is literally about clean room reversing the proprietary blobs found in android devices: https://librephone.fsf.org/site/ - there are no commercial phones using postmarketOS with blobs to reverse engineer.
You can install postmarketOS on it (just as you can install lineageOS, etc on a Samsung galaxy, etc), but it ships with PureOS. "The Librem 5 is a phone built on PureOS" - https://puri.sm/products/librem-5/
The project is to reverse engineer proprietary blobs - so it makes sense to go where those blobs are and reverse to match the functionality that is exposed commercially instead of guessing at a subset for base implementation on a non-official OS?
> See also my other comment
It seems you are just as confused about this project as the OP, which is ironic given your name.
Why does it matter? Yes, I would prefer that FSF collaborated with PureOS directly, but collaborating with postmarketOS also seems possible. There are enough blobs in Librem 5, which don't depend on the OS.
> which is ironic given your name
Indeed I'm quite surprised about the FSF actions lately.
Because to reverse it you need to have a functionally complete baseline to compare it to. For the Librem that baseline is what it ships with (PureOS). For nearly every other device on the planet, that is Android.
By them focusing on creating fully functional free drivers to swap out with the non-free driver blobs on Android, they will have created a reference source that can be adapted for any other OS.
You're right about the drivers, but you don't need to reverse engineer them for Librem 5: They are already free. You only need to do it for the firmware, which AFAIK doesn't depend on the OS.
"Non-free driver blobs" in the librephone context means anything needed to drive the hardware. i.e. kernel drivers, HAL modules, firmware images, user-space vendor libs, etc.
But sure, librem5 probably has most of that already.
Because they aren’t focusing on a specific piece of hardware… I’m really not sure what you are expecting? The librephone project to be focused on librem5 instead of the hardware used in thousands of other devices?
I wanted to mention that back then when Mozilla announced its FirefoxOS based devices with the "ZTE Open" as a developer device, I realized how broken the ecosystem actually is. The ZTE Open wasn't actually open source and you weren't even able to compile FirefoxOS completely, and only the Gaia (UI) parts could be flashed or changed. So much for open source as a branding, it was a pretty useless device in terms of development.
I realized that there will never be a vendor that actually open sources their firmware blobs. We need better legislation or a complete rewrite of our judicative system to fix this, which realistically is never going to happen.
It's an anti-model in their business world, given how contracts and licensing works from upstream ARM or NXP or MediaTek. It doesn't matter really where the vendor sources their chips from. They all have similar NDAs and contracts and royalty fees.
That's why I was so disappointed by my Librem phone, again, because they, again, promised that the NXP related firmware blobs were open sourced, which honestly was a very overpriced lie to begin with in comparison to the Pinephone devices that were sold at self-cost.
I have no idea how the FSF could recommend Librem devices, because they are literally just as free as every next door Qualcomm or Snapdragon chipset.
