No to be harsh, but this is largely useless.
The biggest issues with in-app licensing is
(1) Binding licensing to the machine (or the user!)
(2) Making sure that your licensing check can't be NOP'ed by a l33r haxxor within 5 minutes of the release.
Tangential to that is (3) which is an ability to tolerate minor changed to the machine and OS reinstalls without invalidating the license.
(1) and (3) aren't hard to solve, just need to decide which machine/OS properties a license should be to "latched on". Popular choices are MACs, HDD serials (from the ATA IDENTIFY block), SMBIOS IDs, MachineGuid on Windows, etc. Better yet, it's not a bad idea to bind to a _set_ of machine properties and then tolerate a change of _some_.
(2) is a domain of its own. Basically that's an anti-reverse-engineering task. It's not terribly hard to roll out something on your own, but you do need to know what typical hacks look like. From exe patching to process training / API hooking, there is a substantial learning curve, but it's a quite interesting one.
That is the biggest part of any "license key verification" is not the actual "license key verification", but rather all the nuances that make sure it actually works as designed and doesn't affect users' experience in normal-use cases.