Software Development Kits (SDKs) are a great way to give your users the ability to build on top of the functionality offered by your library/package. From a licensing perspective, desktop apps and SDKs are quite similar, which we will go through in this article. We will first take a look at the applicable licensing models and then skim through some example code. You can jump directly to the tutorial here.
SDK licensing is special since the developer of the SDK (the customer) is not its end user. Instead, it’s their customers that will be the end users. In this article we focus on “node-locked” and “pay per install” licensing models (you can read about all applicable licensing models here).
Node-locked is equivalent to “pay per machine”, which essentially means that each time a new machine activates the license, this is recorded so that it can be taken into account when you charge the developers (your customers). Each user will be able to re-install the app that uses the SDK any number of times, without affecting the counter.
Pay per install is similar to “pay per machine”, with the only difference being that fingerprints of the end user machines are not recorded. Instead, a counter is used that increment whenever the SDK is first launched. With this model you get a bit less control of end user instances, but since the fingerprints (aka machines codes) are not tracked, the subscription cost for Cryptolens will reduce significantly (since you are only paying per license key).
In both of the models above, you could create multiple plans for your customers that depend on the actual usage of the SDK. Eg. 1-10 could be a testing tier, 10-10,000 could be another pricing tier, and so on.
From a developer standpoint (eg. your customer), the license key will have to be specified to unlock functionality of your SDK. You could potentially have different pricing tiers depending on the methods that your customers will use. Below is an example of class initialisation that requires a license key to work.
var math = new MathMethods("FULXY-NADQW-ZAMPX-PQHUT"); Console.WriteLine(math.Abs(5)); Console.WriteLine(math.Fibonacci(5));
To see all the code, please take a look at the entire tutorial.
If you have algorithms in your SDK that you want to be 100% secure from reverse-engineering, we would recommend to create an API endpoint for them hosted in the cloud. Most of the cloud providers support “server less” functions, eg Azure Functions and AWS Lambdas. These are quite simple to setup. Your server less functions would require a license key and potentially a machine code to return a successful response. On the client side, you could use libraries such as RestSharp to access your API endpoint. We will cover this in a future article.