.NET class library licencing idea - madness?

Question

Hi I'm currently developing a .NET library (not a control), and considering how to provide a combined "development" and freely run-time deployable licencing scheme to work with it.

I'm thinking for developer licencing, some kind of node-locked will be just fine (file and/or server/web service), but I want to allow developers to freely distribute my software at run-time.

I was wandering if for the run-time licence, it would be a good idea to have as part of say an MD5 hash for the licence key, the calling assembly's (or executable/module - not sure) company info, or perhaps it's own strong name hash key?

It would mean my users would have to generate a run-time licence every time their software was released/distributed, but that shouldn't be too onerous, I think. This could be done from a valid dev/build licenced/node-locked machine, making the process pretty simple and painless.

This is very much an idea at this stage. I'd love to hear any thoughts people may have on this idea.

Answer 1

i have no idear how you could do this but any way dont use md5 its not safe, go with SHA hash instead..

Answer 2

Everyone hates licensing, so why not just use a simple license key that they set on one of your objects in their code?

YourNamespace.Licensing.SetLicenseKey(193421340982384);

I wouldn't require them to recreate the license key for every build, that would be tedious. However you could make it so that the license key you give them can be converted to a public key token, then you can see if that matches the public key token of the assemblies that call your code.

Answer 3

A few thoughts about this:

• I believe it was Joel Spolsky who pointed out that you have to make the aquisition of a licence easier than breaking, sorry, "working around" the licensing mechanism of the software. Having worked with node locked software as a developer, this can be a pain in the backside, especially if you have more than one machine. Maybe look at user-based licensing (ie, my user has a single license somewhere on their profile, and if that isn't in use already you can use it no matter which machine you're on).
• I foresee problems with your dual licensing scheme of having unlimited runtime license, but still requiring a per-seat developer license for the same library. For example, what's stopping developers to 'license' a runtime for their development purposes?
• Enforcement is another problem. How do you find out if your client is violating your license agreement? Having the library "phone home" would most likely rule out its use in a lot of corporate, firewalled environments.
• How much effort would you have to invest into this scheme? Can you buy one? Can you use the time to improve your library so your clients would buy an upgrade instead?
• If there are any comparable libraries out there, check if they have any sort of copy protection. If not, forget about it straight away as you'll be handing sales to your competitors that way.

Answer 4

It would help if you told us what the library actually does! But one way I would suggest is that you inherit your library from the class System.ComponentModel.Component. This will give your library access to the property DesignMode, which allows you to differntiate whether it is running in the visual studio designer or at runtime. Then you could enforce your license only if the component is running in the designer, perhaps in the constructor. .

if(this.DesignMode){
///Do your check here
}

With regards to the licensing itself, you can get a lot of information from this articlelink text

Of course without knowing what your library does it is difficult to know if this is the right approach to take, but if it is something like the DataSet, which is hosted on the designer surface, this approach might bear investigating further

Answer 5

Thanks all for the ideas and comments.

Yes, some good points to consider.

To carry on the discussion;

I'm not trying to develop an invincible licencing system here (likely that's not possible and I don't want to use dongles etc), and I am developing my own one-person project on a shoe string, so paying $3k for an off the shelf solution is never going to happen.

I just want to stop it from being easy to send a licence to another developer or "get away" with one licence instead of 5 for example. Legit users will pay up, but the determined ones will get around it no matter what, so I won't bother trying to stop them. I kind of think there should be a "Developers Honour" vibe anyway - ripping off your fellow developers is bad karma IMO. Niaieve? Probably.

In answer to the developers using a run-time licence for dev. I might be missing something here, but the idea is that a run-time licence key is generated by the customer when their software is ready to ship - i.e. built and ready to go - this then makes the licence application-locked as opposed to the machine-locked developer licence key used for developing the application.

Licence I'm thinking is just a file that gets distributed with the library, so can be switched between dev and run-time as needed. My licence code will be able to tell which licence type it is (dev/r-t indicator in an encrypted block in the licence file?)

The dev licence keys would have to be activated/created by calling in to a key-issuing web service from a tool I supply with the software. The user will supply some info like name and email address. The tool will take something machine specific. All gets sent to the web service, which returns a licence file containing the personal info (raw text copy as well?), and a hash (SHA then, not MD5!)

At run-time, my library loads the licence key file (either dev or run-time), and validates the licence accordingly (verifies node its running on or the app that's calling it). I could allow user code to call in as suggested, passing the licence key file stream.

Will this work or am I really barking mad?

Cheers.