(Removing the EF dependency would also let you ship a .NET Standard 2.0 version suitable for .NET Framework apps.)

On the licensing service side as they have to lock down a database server to allow safe A.C. access by arbitrary clients…

And requires end users to carve out firewall/network security rules to allow outbound connections to an arbitrary database server, which is a pretty significant data exfiltration vector and I’d be extremely concerned about enabling this even at the best of times…

The mitigation would have been trivial, gRPC, gRPC Web(which has excellent support in the .Net world) , or a regular HTTP API would have been completely adequate and this database driven solution is the sort thing I’m not surprised to see from a .Net developer, as along with Java devs seem to be the last remaining pockets where it’s obvious that a developer can go their entire career without knowing anything about code outside the corporate Network. Since that’s the only place this is even close to safe, 100% inside the corporate firewall. To clarify this is to say that the only two developer communities where I would not be surprised to see this are Java and .Net, because they contain enough developers who lived inside the corporate walls and have yet to gain enough exposure to wider community practices, not because of anything about the languages themselves but because if the social dynamics involved in the developer population that work with these languages.

There's significantly more involved in managing this sort of thing that a simplistic library such as this can manage.

Companies concerned with licensing usually do it because they're protecting their assets from software piracy. Something like this would be horribly easy to circumnavigate.

You're using a simple pseudo random number generator as well (as opposed to a cryptographic one), which is incredibly weak, and, as others have made clear, making a direct DB connection is an absolute no-no: Your methodology of requiring a directly connecting to a remote database server, that is also required to be accessible 100% of the time, is critical point of failure.

I can't imagine anyone (outside of the really big name vendors) that'll have customers that'll be "forgiving" enough to be blocked simply because there's an issue with the remote database.

Not used them myself, but something like https://licensespring.com/ seems to provide significantly better license management.

https://wyday.com/limelm/

Generate a key pair, embed public key in your executable, keep private key private.

A license is some JSON or XML or whatever, signed with the private key. If your licenses are permanent, and you don't need different license types, a license is just a signature of some computer ID (like hard drive serial), with that private key.

Unlike the older RSA, ECDSA results in very small signatures, even for very strong curves like NIST P-521. These signatures only take couple lines in Base64 text format.

AutoDesk software and quite a few other creative tools do that.

So whilst they are fairly easily cracked its quite hard to use that software in a commercial setting.

Quick crack: takes 5 minutes

Find the is-valid-license method and make it always return true.

As someone who has spent a considerable amount of time "on the other side", it's amusing to see things like this being open-source, because being closed-source --- and sometimes obfuscated --- is almost entirely what most DRM relies on for its strength.

I would use this for products that are mostly used by businesses. Some businesses will happily run pirated software, but any potential customer will just pay for the license. All you need is a way to turn a trial version into an activated version to make the popups/watermarks go away.

Any .net app not compiled to native code can be disassembled if one is prepared to put any time to it.

Back when the .net Framework first came out, I was all over using the full Dotfuscator app thinking it would protect my apps. I was even more excited when I observed reflector giving up on it.

Right up until a friend of mine used a different app and showed me the deobfuscated code. I gave up at that point and realized it wasn't worth the effort.

Whilst your willingness to tip a toe in these waters is a good thing, I'd not hold out much hope of this library being used by many, if any people when there are some far better, more resilient and battle hardened versions out there.

Secondly, what do you want? I could inject the license check into multiple parts of the library, but this is a dubious way.

Your library addresses issues that you personally have perceived exist with licensing software.

What you haven't done is ascertain what issues actually exist.

For example, what problem does your library alleviate?

There are other examples out there that can also be used for free, so it's not that.

There are examples that work natively across multiple environments, like Mac, Linux and Windows. Again, your library doesn't help there.

Java, C++, Swift etc.? Nope.

Centralized auditing? Cryptographically secure? Battle tested?

Sadly your local library strikes out everywhere - it's very core sadly let's it down because you didn't actually identify a problem to address, so your "solution" isn't really going to move a needle.

Multiple questions have been asked of you but nowhere have you really identified the audience for this library.

Why should someone use it over something else?

There's 100s of similar packages available on Nuget - many of them seemingly unmaintained.

For your library to be of use, you need to offer value over the cruft and crud.

Open source is a blessing and a curse. I've multiple packages out there that I thought were pretty neat at the time - and filled a niche spot. Few folk felt the same but that's fine by me as well.

Rather than try to iterate on this, I'd step back and ask yourself the hard question: what does your lib do better (or at least equally as well) as the competition?

And be severely critical. Given the stated purpose of this library, put yourself in the mind of an adversary: how quickly could you defeat it? If it's mere minutes then it's not good enough.

Look for all the weaknesses, look how other libraries fix the weaknesses.

In the end you may decide to give up. That's fine as well. Don't treat it as failure though, just use it as a stepping stone and try, try again.

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'd suggest you focus less on hubris and more and understanding.

Goodbye.

Think of it like locks on doors in the professional world of business software. Helps to keep the customer honest because at the end of the day they don't actually want to violate any rules. It can be hard to keep track of all the instances of things in some enterprises. The scale of our average customer has informed us that integrated licensing functionality is ideal for some of our products.

The credentials can be taken from the disassembled source code, but I've already taken it into account. The next versions will use an HTTP API.

Anyone can easily proxy the server DNS call, put up their own server, etc.

A client app connecting to a public facing database server with no authentication is a huge security risk, aside from anything this whole library is doing.