Wibu-Systems Blog

Yet more software license management flexibility

Posted by John Browne on Jul 12, 2012 4:55:00 PM

Time for some how-to.

You don't have to use an API to implement CodeMeter--in fact, you can just use AxProtector (Automated Executable Protection) and wrap your whole executable (or dll or file or what have you, but we'll focus on executables in this blog post) with strong encryption that needs a valid license at runtime. Badda bing, badda boom. You're done.

That was easy.

And you can get a lot of flexibility in your software license management with no more work. Time based licenses, usage-based, network, concurrency, all those things and more are available with no source code changes--just protect with AxProtector and then set the licensing rules when you create the license.

So why mess with the source code? Good question. There are two reasons:

1. You can turn on or turn off individual functions or methods with separate licenses, thus enabling a pay-per-feature business model. This can be really cool if you think about all the possibilities (more later).

2. You can increase the security of your application, since multiple licenses with multiple separte keys are needed for it to run. While cracking CodeMeter is no small feat, this will just make it that much tougher.

How hard is this source code intergration? Pretty basic. We have a low-level API (the "Core API") which you don't repeat do not want to use. If in doubt, please give us a call to ask if you should use this. Normally our customers only use it when they need to implement CodeMeter on a platform we don't yet support. 

These are not the functions you are looking for...

The one you want is WUPI (Wibu Universal Protection Interface). WUPI is a high-level encapsulation of the Core API and by using it you will avoid shooting off your toes the way you can with the Core API. WUPI will do most anything you need to do.

WUPI only needs 15 functions to cover the whole gamut of stuff:

  1. Accessing: allocate and free a license; get a handle to a license
  2. Encryption: Encrypt and decrypt code
  3. Manage: Decrease Unit Counter; Get License Type; Query info; Read/write data
  4. Security: Debugger check and license check
  5. Errors: Get last error

That's it. Most of it you don't need to worry about. All the functions return either a BOOL or an INT, which makes them easy to use in a number of programming languages.

Parking meter

Integration couldn't be easier. There's an include file (we're talking C++ now), and you have to point your linker to some libs. The CodeMeter API guide (accessed from the CodeMeter Start Center, which is part of the Evaluation System) gives you sample code to cut & paste.

Here's an example:

#include <WibuIxap.h>
 int iWupiResult = WupiCheckLicense(0);
 if (!iWupiResult)
{
// License check failed.
}
else
{
// Successfully checking license.

That's it. Pretty simple--you just need to wrap these kinds of calls around the code that does stuff inside your application. 

Suppose, for example (and I know this is a trivial example) you wanted to meter printing. You could wrap your print function with a call to decrease the CodeMeter Unit Counter:

#include <WibuIxap.h>
 
int iWupiResult = WupiDecreaseUnitCounter(0, 0);
 
if (!iWupiResult)
{
// Unit Counter reached 0.
// License isn´t available or already allocated.
}
else
{
// Successfully decreased Unit Counter by the specified units.
// No Units remaining.
}

 If you use some counter in your code for the number of pages as a parameter to the WupiDecreaseUnitCounter() function, you can meter things exactly. Unit Counter values are set at license time, so this would require you to sell "blocks" or pages to be printed; when they get low on available pages (ie UnitCounter value) the system will let them know that they might want to buy some more. When they are gone, no more printing.

Printing is trivial (well, perhaps not if you're a printer) but there are plenty of other things you could wrap in this kind of protection. Perhaps you want to have Bronze, Silver, and Gold versions of your product. The normal way you'd do that is to branch your code or use conditional compiles. But it's a lot of work. With WUPI you can build one monolithic application, wrap that Bronze, Silver, and Gold functionality in separate license calls, and ship the whole thing to everyone. They get the product they paid for (because the correct license turns things on). Nothing more.

One last thought. This API stuff is not needed if you use .NET; because it's managed code you can actually protect individual .NET methods from inside AxProtector. 

photo credit: lakewentworth via photo pin cc

Topics: CodeMeter, License Management, AxProtector, Software Development

Wait to the last minute, then panic

Posted by John Browne on Apr 5, 2011 7:05:00 AM

This post questions why developers can't estimate time. Nice discussion. In the over 30 years I've been working on software projects, I've see few ship on schedule. Unless the "schedule" is the one set 5 minutes before the actual release. Those dates are pretty accurate.

A not-all-that-uncommon call we get here sounds something like this:

Developer: Hello, Wibu? Hi, I need a dongle. Our code is ready to ship and we just need to bolt on some copy protection and license management.

Me: What exactly do you mean by "bolt on"?

Dev: We've implemented our own system, we just need to get the serial number of the dongle and read it back to the application.

Me: Hmmm, you can certainly do that, but you DO know that it can be cracked in like, oh, 10 seconds, right? (Briefly explains CodeMeter)

Dev: Well, that sounds good, but we already implemented this in source code and we're READY TO SHIP. Except for the license thingy.

Me: Sigh.

Imagine if you're building a house and the contractor comes to you and says something like, "Well, we're ready for you to move in as soon as we figure out how to get running water to all the sinks and toilets. I think we're gonna tie garden hoses around the house, drill holes in the outside walls, and snake them in through the holes..."

Some recommendations for best practices:

  1. Include product marketing in the design and planning stages before coding. Adding requirements for how you want to package, market, and yes, license the software is important. You need to Design to Sell.
  2. During the design/architecture phase, make your outside dependency decisions so you know what degrees of freedom you actually have. If you're going to use CodeMeter, you don't need to do any API-level implementation, but you CAN, in order to gain certain flexibility. It's nice to know that up front before you are at code complete.
  3. Find out from support what activation and licensing problems users have experienced on prior releases. Make sure your solution addresses these issues.
  4. Get the sales team bought in. Could be that they have an opportunity to make some sales if you had a different licensing model. For example, they might be able to lease a product if you supported that. Or maybe a subscription could gain some traction in a key account rather than a perpetual license due to customer cash flow concerns. Point is, you won't know if you don't ask them. Again: Design to Sell.

Waiting to the last minute to plan and implement license management may be common, but so is missing your dates. The first will almost guarantee the second.

Topics: CodeMeter, software copy protection, License Management, dongles, sales, Software Development