@guylouis here, I am also a contributor to to keycard and shell!

You're actually right, it's a bit confusing to say the secure element is open source, we will change the line on the website. Thanks for this. The correct assertion is that the secure element has 'open source software'. Just like we did in our detailed comparison table here

Also Keycard is using javacard because we considered javacards were the most open way to do a programmable secure element nowadays. It's an open platform with standard API and runs on a lot of different hardwares from a lot of different vendors. But indeed there is a trust assumption on the hardware (in keycard case: NXP JCOP4).

100% open source secure element based on RISC-V will come but they are not ready yet (see tropic square) and will come in non-programmable versions first. We believe a hardware wallet should never let the secrets keys get out of the secure element and thus be programmable (if it's not programmable, it will have to export the keys out, to a not so secure MCU to do the signing, because non programmable secure element can't perform natively all the crypto primitives of a bip32 wallet like deriving etc.).

Based on our study the only ones who use programmable secure element are ledger and shell (happy to be proven wrong and complete our comparison table on the link above)

Also on the front page of the website the idea we want to convey when we say hardware is fully open is that we provide everything (schematic, bill of material, gerber files for pcb manufacturing) to manufacture it. In that sense only fundation passport (to our knowledge) has the same approach as Shell (see the comparison table). We don't want to convey the impression that each component is open source down to the sillicon level, it wouldn't be possible (MCUs, Asics are not for instance)