Let me add a few details to explain this. Each Android and Android Open Source Project (AOSP) version supports 3 long-term service (LTS) kernels. For example, Android/AOSP 11 was released on Sep. 8, 2020 and it is able to run on the 4.14, 4.19, and 5.4 kernels. It will be supported by Google until Jan. 2024 or for 3.3 years.
Most of the time the kernel is not upgraded when upgrading the Android/AOSP operating system because the makers of the mobile System-on-a-Chip (SoC) like Qualcomm, MediaTek, UNISOC and Samsung don’t bother releasing drivers for newer kernels. For example, the Snapdragon 855 only has drivers for the Android kernel 4.14, so a Snapdragon 855 device can only be upgraded from Android 9 -> 10 -> 11, but the upcoming Android 12 will only support the kernels 4.19, 5.4 and 5.10, so there is no way to officially upgrade the device after that, and Google will stop offering security updates on Jan 2024 for Android 11, and Qualcomm will probably stop offering firmware updates for the Snapdragon 855 in late 2021, 3 years after it introduced the chip.
Many Android devices never get an Android upgrade, so they are effectively limited to 3.3 years of support, which translates to 2.7 years of support if they are introduced on average of 6 months after Google released that version of Android. If you buy a Pixel, OnePlus, Android One device or a Samsung Galaxy S/Z, you are going to get two years of Android upgrades and 3 years of security updates. With Galaxy S/Z you are probably going to get 3.5 years of security updates, but if you want anything longer, you will have to buy one of the Android Enterprise Rugged phones which claim to offer 5 years of security updates.
The other route is to install on your own an AOSP-derivative. You might get very lucky and buy something like the LG G2 from 2013, that is able to be upgraded to LineageOS 18.1 (AOSP 11), but many phones have little things that don’t work correctly when installing an AOSP-derivative. As long as the manufacturer keeps offering Android upgrades for a model, it is usually possible for the community to figure out how to get LineageOS to upgrade as well, but after that it becomes a crap shoot. If you buy a Pixel or OnePlus, your chances are higher that you will be able to keep upgrading, but there are no guarantees.
Now, let’s compare that to the Librem 5. NXP says that it will sell the i.MX 8M Quad till Jan 2033, so we can probably count on firmware updates till the mid-2030s. All the hardware in the Librem 5 uses open source drivers, so the community can effectively maintain the drivers as long as there is public interest in using the hardware. Purism is working toward getting all the hardware supported in mainline Linux, so that means that it will be possible to easily upgrade to the latest kernel in the future, even if Purism disappears in the future. Likewise, Purism is working to get all its code changes upsteamed to wlroots, GTK, GNOME and the GNOME apps, so future versions of Phosh should be compatible with minimal work. Even if Purism disappears, Purism has been working hard to get its software (libhandy, libadwaita, Calls, Chats and fractil-next) incorporated into GNOME, so the community will be be able to maintain it, and the other parts (phoc, phosh, squeekboard, feedbackd, etc.) are small enough, that there is a good chance that volunteers at Mobian, postmarketOS, etc. will be able to maintain it.
With a replaceable WiFi/BT and cellular modem, I think it highly likely that the L5 will still be a functional phone 10 years from now. Look at how long people kept using the N900 from 2009, and it didn’t have many of the advantages of the L5.
All the drivers in the L5 are open source, but the firmware is not. Firmware is usually stored in the Linux file system in /lib/firmware/
and passed to the components during boot, but in the L5, the proprietary firmware is stored in other locations, like an SPI Flash chip. From a comment by @nicole.faerber a couple years ago, I gather that Purism had to pay Redpine Signals to alter its firmware so the RS9116 could load from a different location to meet the RYF requirements. Faerber also made a comment that there the possibility of using free/open firmware for the microcontroller for the smartcard reader.
ARM, Qualcomm and Samsung claim that their System Memory Management Unit (SMMU) should stop access of memory between the CPU and WiFi/BT, but this article points out that it can be exploited.
It’s worth noting that the cellular modem in the L5 uses USB 2.0 and I2S and the WiFi/BT uses SDIO 2.0, which are communication protocols which don’t allow direct memory access (DMA), so that kind of attack isn’t possible. Despite what madaidan and Daniel Micay may claim, the L5 is safer than Android phones in this regard. However, the USB-C port on the L5 uses USB 3.0, which does allow DMA, so maybe a USB device could be designed to attack the Librem 5 that way, but honestly, I doubt that anyone is going to take that much time trying to figure out how to exploit the i.MX 8M, when there are far better targets like Snapdragon, Helios/Dimensity and Exynos that have millions of phone users.
Android and iOS have better kernel hardening, better sandboxing of apps, and verified boot to prevent modification of the boot files, but they are also have the Google Play Store and Apple Store with millions of apps that they don’t know if they can trust. (By the way, for people who want better app sandboxing and verified boot, you might want to wait for the Ubuntu Touch port to the L5, but who knows when that will come.)
With the L5, you keep out a lot of the bad actors simply by installing apps from the PureOS Store and Debian main. You would have to design a FOSS app that can get past the Debian and Purism developers, which would take some obfuscation on your part to hide what you are doing in the code, and you would have to make any network traffic that you generate look like it is harmless, because there is a good chance that someone might get curious and look at it.
The areas where I think people will notice a difference between the L5 and a degoogled phone is in the cameras, power management and the available apps. The i.MX 8M doesn’t have an image signal processor and hardware video encoding and NXP says that the i.MX 8M Quad can only encode video in software at a maximum of 1080p at 30fps. I’m guessing that it will be a while before we have suspend to RAM and the BM818 and RS9116 will be able wake up the system when getting a phone call. Getting support for the OpenPGP card in all the apps will also take a while. Finally, it will take a while to get apps that can match the functionality for Android/iOS apps. I don’t expect to see a FOSS voice assistant AI to replace Google Assistant or Samsung Bixby any time soon.