I'll tell you how, I think, my library can be cracked. Of course, disassembling and deobfuscating. Then, I (adversary) have to find the is-license-valid method. Then make it return... not true, but an entity containing the corresponding information. (Which means I have to examine the structure of library.)
It's all, in the current version. I don't think it's enough, so I have a task to inject license validity checks into multiple places of the library. It'll cause headache after patching the is-license-valid method because there are other checks.
(Oh, yes, after patching I have to recompile the library.)
But in other licensing libraries the process is the same! My lib (at least when I'll "split" the license check) is not worse. Do you agree?
What does my lib do better than others? Let's start with the fact I couldn't find any "others" on GitHub. All licensing libraries I saw there work with "license files" (JSON/XML/something). I challenge you to find a competitor of mine there!
Then, what does it do better than the libraries working with license files? Such libs have one serious weakness. Someone payed for a license and got a signed file. Then he gives it to 10 friends, and they have activated program with no pay. This can't occur with my lib because each license activation is registered on the remote server, and it doesn't allow you to activate a license when there are too many previous activations.
What about "I didn't identify the audience of my library" — maybe I didn't catch it? Isn't it obvious?
I see no need to continue this discussion since you apparently feel your simple library built without understanding about actual real-life need, is better than the various battle tested ones out there.
I'd suggest you focus less on hubris and more and understanding.
I'll tell you how, I think, my library can be cracked. Of course, disassembling and deobfuscating. Then, I (adversary) have to find the is-license-valid method. Then make it return... not true, but an entity containing the corresponding information. (Which means I have to examine the structure of library.)
It's all, in the current version. I don't think it's enough, so I have a task to inject license validity checks into multiple places of the library. It'll cause headache after patching the is-license-valid method because there are other checks.
(Oh, yes, after patching I have to recompile the library.)
But in other licensing libraries the process is the same! My lib (at least when I'll "split" the license check) is not worse. Do you agree?
What does my lib do better than others? Let's start with the fact I couldn't find any "others" on GitHub. All licensing libraries I saw there work with "license files" (JSON/XML/something). I challenge you to find a competitor of mine there!
Then, what does it do better than the libraries working with license files? Such libs have one serious weakness. Someone payed for a license and got a signed file. Then he gives it to 10 friends, and they have activated program with no pay. This can't occur with my lib because each license activation is registered on the remote server, and it doesn't allow you to activate a license when there are too many previous activations.
What about "I didn't identify the audience of my library" — maybe I didn't catch it? Isn't it obvious?