As you are going to run a open source OS, attestation will not work as reliably. The TPM will be able to attestate up to the loader of the OS, but after that, attestation becomes difficult as open source software is easy to modify.
I would suggest using the attestation identity key, to create a remote attestation signature (TPM_Quote) and then use a cloud service to host most parts of your application.
The client app just acts as a "dumb interface" to the cloud server, and the TPM_Quote is sent to the server as a "login". This can also be used to negotiate a "session key" that only the TPM and your server, can use to encrypt/decrypt.
This means that a cracker can copy your application until the cows come home, it wont matter, as your server will not accept a TPM_Quote from a tampered system.
This also makes it easy to revoke licenses if they are misused, for example if a customer is for example abusing a personal license by lending out RDP/VNC access to the computer to individuals outside of the customers premises.
Note that unencrypted application still needs to be available to the host OS, so regardless of which TPM features you use, it will still be crackable as long as the verification is done locally. Even if you use attestation with sealed storage and curtained memory, a cracker will still be able to crack the application, as sealed storage and curtained memory can only contain data, not executeable code. (yes, you can have executeable code in for example curtained memory, but for the host OS to be able to execute it, you need to move it outside of curtained memory).
Thats why you need to use a cloud service, so you can enforce the non-tampered state of the client computer from a central location that a cracker cannot physically access, and then host the application on this location, so even if the cracker has complete access to the client-side source code, they cannot take advantage of the service in question.
