And I'm glad they didn't. Protecting the installer keeps honest people honest. Protecting the runtime after installed means reduced performance and/or support headaches. That said I hope the developer didn't pay too much for this copy protection when some bespoke checks on the installer would have sufficed.

I'm just glad they didn't use iLok. It's been a pain for me as a legitimate user of a few iLok protected plugins.

I'm confused, then why does your article throw shade at both the protection software and the VST?

It sounds like you didn't find any issues with either of them, except that the VST vendor chose not to protect the thing you were hoping to crack?

Question: Why go through the effort of removing most of the key throughout the article just to have it in a chunk of code in the article anyways? I'm not trying to throw shade here, I am legitimately curious about the reasoning

Runtime checks aren't an impossible effort to defeat either. If you're into this stuff, you should build a plugin with them yourself and then figure out how to crack it. It's a great learning exercise.

As another commenter wrote, the protection is there to keep honest people honest, like locking the front door of your house.

It's not foolproof and doesn't need to be. It's role is to make sure respectful users know that you'd genuinely prefer they not steal your stuff (not everyone actually does care about that).

Or maybe they knew about the runtime checks, but made a decision not to add them? As others have pointed out, this plugin can be used during live performances. The last thing a plugin author wants is a reputation for their software being flaky at really bad times. A runtime copy protection check might fail for spurious reasons, who knows.