I suppose there could be a challenge token from the product that compares the server response token to an internally generated token, but at the end of the day the product is in the hands of the user, and someone determined to steal it is going to steal it. The only way to really ensure the license is not broken is to do essential work on the server. What am I missing?
In this case, I don't know what Gumroad could do given that it's ExtendScript. But I can totally see Gumroad making a library for more supported ecosystems and an api endpoint that makes use of public/private key encryption to create a "signed" response. Naive possibility:
Gumroad receives request from app -> Gumroad crafts response, encrypts with private key (could be Gumroad key or a dev generated key), base64 it, returns to app -> Local library decrypts with public key and then verifies response.
This of course doesn't stop someone from messing with source code and "cracking" the app, but in the case of a binary based app, that's not as straightforward.
That said, another commenter did mention that pirates are gonna pirate, so friendly easy DRM for the dev also makes sense.
At the end of the day the scripts being sold are extend script which is interpreted, so pirates can always just open the script with a text editor, go to the "verifyLicence" function and trucate it to "return true". I think it's just not part of the threat model.
