The bootloader comes up regularly in the discussions about alternative OSes, as it is a major determinant to whether you can run custom code (which can do basically anything). The security model for the bootloader specifies that when the bootloader unlocking process is performed, data on the phone needs to be wiped to avoid unauthorised access to any data.
Individual vendors may also implement other measures in the bootloader to avoid untrusted code being run. Whether the primary reason is device security or something else (e.g. not wanting to deal with warranty claims caused by messing with the system) is something only the company will know.
Regarding bootloader unlocking, two comments come to mind:
- If I recall correctly, motorola devices require an IMEI-dependent unlock code that you can request from their support. The portal that allows you to request the code makes you agree to certain terms that include acknowledging that your warranty is void. When the device is unlocked, the boot animation changes to clearly indicate that the device may have been tampered with and that data may not be secure. No secretly changing things on someone else’s device (although I’m not sure that can’t be worked around), but it also looks like they want to make it clear they take zero responsibility from that point onwards and that you’re on your own. It will be interesting to see how Fairphone will act in this regard (as the unlock codes for Fairphone appear to be IMEI-dependent as well, the idea may be for support to log the IMEIs in requests for unlock codes).
- There have been some reports by people who visited a Fairphone community event that the bootloader would be locked as part of licensing conditions for Google components, with a fee payable for each unlocked device. Apparently this fee was factored into the FP2 price, but is being handled differently for the FP3 as the vast majority of users has no need for an unlocked bootloader. If all this is true, we don’t know whether this means that Fairphone intends to charge for unlocks, or whether they’ve accounted for e.g. 10% of users requesting one and will hand them out free of charge when requested.
Side note:
See also the debate on encryption on phones and whether or not backdoors should exist for law enforcement.
If you return the device stating that the device is not in conformity with the contract of sale, the onus is then on Fairphone to prove that device either is, in actual fact, in conformity with the contract of sale, or that the non-conformity is the result of misuse or such if they intend to contest. As to what conformity is, that’s set out in article 2 of the EU directive you linked to (here’s a link to the English version for those who prefer that). I find it surprisingly difficult to argue that not knowing whether the code supplied corresponds to the binary on the device causes the device to be non-conformant to the contract of sale in manner defined in the directive. What’s worse is that for customers who purchased the device when the source code wasn’t available, it could be argued that they could reasonably have known about source code issue, which precludes claiming non-conformity (Art 2.3). If the legal owners of the GPLv2 code start legal action and the outcome is that the kernel needs to be removed from devices, I’m sure that would render the devices non-conformant.
If anyone wants to go down the route of returning the device because they believe the device isn’t conformant with the contract of sale, note that some European countries have variations in consumer law that require you to notify the seller of the defect within two or three months of discovery. When discovery actually took place or will take place, I find a difficult concept.