Simple licensing solution?

Commercial / Licences
1

Hi all!

For quite a long time now, I have been trying to search for a simple licensing solution for my first commercial plugin. However, the more I learn about the subject, the more questions I have. I know that everything worthwhile will get cracked someday by someone, so I wouldn’t want to spend too much time trying to come up with a perfect copy protection solution. I’ve found few threads about the subject, but they are all more or less discussing the pros and cons of each approach.

I will be using Easy Digital Downloads as a distribution solution, which has a software licensing addon. However, it is created mainly for WordPress plugins, and such not quite matching my needs. I have seen many companies using a key file system, where you download a file to your computer to license the plugin, but I have no idea how it works and can’t find any information on the web. Restricting the usage on other computers would require creating a unique machine id for each user, but this too has many pitfalls. Machine properties like MAC addresses, CPU and motherboard models, HDD serial numbers, etc., are either easy to change or commonly shared. Furthermore, generating keys from the user’s machine attributes seems highly case-dependent and frankly vague. In one forum, someone said this:

“A simple hashed code tied to their email or similar is probably good enough. Hardware-based IDs always become an issue when people need to reinstall or update hardware.”

Due to my lack of knowledge in cryptography, this too is too general for me to start implementing anything.

I could go on and on about my concerns on this subject. For example, if the user downloads an updated version of the plugin, how can you identify that this guy already has a license for the product?

If anyone is willing to share how you handle licensing, I would be super grateful. Also, if you know of any books or other resources about the subject, please let me know.

1 Like
2

I’m currently exploring the topic as well. The easiest way would be an offline scheme, where you generate a serial number that is verified by the plugin internally. You’d usually use an asymmetric encryption scheme like RSA, where your keygen has the private key and the public key is embedded in your plugin to decrypt/verify the serial. That’s quite easy to do and you can use basically any shop system that lets you upload a list of keys. But this way there’s nothing stopping anyone from sharing the key widely. However you can tie it to a user name and display the user name in the UI like u-He does. Nobody wants to be the name that shows up on every k’ed install. :wink:

My currently preferred, but much more complicated solution, is to build a simple licensing backend server that handles serial generation and online activation. The server then is the one to verify the serial number and activate the plugin (see the JUCE tutorial on this for a basic understanding of that communication). The nice thing about that is that you can limit check the number of activations per serial and thus detect if it is shared widely, and then blocklist it. Or limit the number of activations.

You can set up payment services like 2Checkout or FastSpring so they request a new serial number for a purchase from the server via an API request. That way you can record the customer and purchase data in the database along with the serial key, and also bake some of that information into the key. However, be very careful about the exact policies and user experience around that. You want to keep the risk of frustration and support tickets as low as possible, so the policy should be as permissive as reasonably possible (in my opinion).

But you need to maintain a server and database for the whole scheme. So it’s only viable if you plan to build a sustainable business around it. It’s far too much effort if you just want to sell a plugin on the side.

I’m probably stupid for going down that rabbithole, especially as I’m not very experienced in web development, but I also think it’s fun and interesting. :nerd_face:

1 Like
3

Thanks so much for your answer. I would be more than happy with the first approach. I only need something that can be easily managed and doesn’t annoy honest customers. I understand the basic concept of RSA encryption, but I still don’t quite get how you would go about implementing this. I mean, do I have to create a license key for each user manually? What against does the plugin then compare the user-entered serial? When the plugin has confirmed a valid key, does that build stay forever activated and can be copied and shared indefinitely? Although that wouldn’t matter that much if you display the license owner’s email, for example, in the plugin. When the user downloads an updated plugin version, would she have to enter the key again?

4

An activation doesn’t change the actually installed bundle (that’s impossible nowadays anyway due to code signing etc.). You save the licensing information somewhere (OS’s preference store or a file in an appropriate and accessible location). It’ll still be there after installing an updated version, so the plugin will still find it.

5

Exactly. This is enough for me to discard that idea completely. And if somebody posts a serial number you can be sure it was sold to Bart Simpson or Amanda Hugandkiss with a throw away email.

There is no serverless solution. For the reinstall problem I would indeed use the registered email where you send activation codes on request that work only on that machine (put some hardware ID in the request).

6

I see. I have pretty much no knowledge at all of Linux servers, let alone an amount to implement a backend server for licensing. How did you guys learn the necessary skills? There is hardly anything about audio plugin licensing from the developer’s perspective on the internet.

7

To be perfectly honest: even though I wrote a few servers and even implemented once a complete activation process using django (python) on the server and JUCE/libsodium in the plugin, I never put it into production, because I find it scary to handle all the possible support cases and maintaining the server as an individual.
How could you even go on holiday when you need to monitor that your server is running?

So I am working for clients now where they deal with that part themselves.

2 Likes
8

That indeed sounds way too much work. I mean, If the software gets big enough, someone will crack it anyway. What do you reckon are my options then? I don’t want to spend too much time thinking about licensing since I am just getting started selling plugins.

10

I have, but I don’t want my customers to have a similar experience I had many years ago when I bought an already expensive piece of kit and found out afterward that I need some additional 50 buck dongle. Also, my plugins are pretty affordable, so I don’t know if it would be worth it.

12

Thank you for your input. Maybe I’ll shoot PACE an email to inquire about different options.

13

If you enter your thread title into the forum search you find some alternatives, e.g. volko under the name keyzy.io. I haven’t used his service though.

Personally I still find it a bit pricey when starting out and you don’t know if your product will fly or not, but there is always a price to pay.

14

Yeah, that is a little bit pricey for me. Atleast for now. Thank you for your help anyway.

15

I have been using https://cryptlex.com/ for 8 months and quite happy with the solution. It is very easy to integrate into Juce. Costs nothing to try out, but can get pricey…

1 Like
16

My advice:
Keep your licensing solution simple and stupid.
Focus on your product, take care about your costumers.

3 Likes
17

This is probably what I am going to do. Creating effective licensing on my own seems somewhat impossible, and paying big money for a commercial solution so early doesn’t make sense either.

18

Personally I’d stay away from PACE, especially for small plugins. Without going into too much detail, but i had to go to quite a lot of trouble in the past.
The effort you’ll need to put into your licensing system mainly depens on how honest you think your customers are, and how much you want to bother them about it.
There will always be some cracks out there, so me personally wouldn’d spent too much time designing a clever scheme.
If you need offline support but don’t want to design your own licensing server, something along these lines should probably work fine:

  • Generate a RSA-Key-pair, compile the public key into the plugin, keep the private one for yourself
  • Let the plugin generate a machine-id (see juce docs)
  • Let the user send you the id string
  • Encrypt the id string using the private RSA key, send the encrypted string back to the user
  • Let the plugin verify that when applying the public RSA key to the string you sent back the same machine id is obtained

If the strings match, than this means that you personally approved that this device is allowed to use your plugin. It also means that every device must be approved by you, and there isn’t any token or license key that could be copied to another device. Since the plugin can save the encrypted id on disk, it doesn’t need internet connection to re-check whether it is licensed.

Possible attack vectors are that plugin binary is modified to simply skip this check (which is a very high bar), or maybe some methods to spoof the machine id.

19

Just my two cents: really happy with keyzy so far. You can limit the number of registered devices and you only need to be online for activation/deactivation. Also it was easy to integrate with JUCE and the price is ok for us. You can try it for free too.

2 Likes
20

Another pennies worth of opinion:

when starting small either just don’t bother with licensing at all (trust your users to be honest) or implement a trivial licensing system to at least stop the casual sharing of your products (still requires trust that users won’t just share the activation key).

I went with the 2nd option, then all my plugins recently got cracked by R2R, I take it as almost a badge of honour that they were deemed worthy to crack!

I’m not a fan of needing an internet connection in order to activate, it makes it a PITA if you prefer to keep your audio computer offline.

3 Likes
21

I agree with all said here.
If I were to start with plugins again, I would simply add a nagging screen to buy, that appears after 30 seconds and reappears every 5 minutes or so. The user needs to click that away, and has to buy a “pseudo secret” code the users have to buy and enter.
That code will be shared eventually, but at least you get something from the honest users. This also helps to gauge interest without investing too much. You will see how much use there will be.

Pro-Tip: add some analytics (anonympous counter, careful with GDPR) and a field to signup to your newsletter, that might turn out to be even more valuable than the income…

22

Thank you so much, everyone, for your valuable insights. I am probably going to go with some simple solution that would only prevent casual sharing. I had this one idea with Easy Digital Downloads’ licensing addon. The addon would provide the license-key generation and an API for activation, validity checking, and things like that. By design, the API call to activate a license takes an URL, since WordPress plugin licenses are website tied. You can, however, pass any identifier you want. I’d use a machine-id from the user’s computer. The license key and machine-id are then stored somewhere in the user’s computer. Every once in a while, the plugin would check if the stored machine-id is still the same or similar enough. This way, even if the user copies the key file and the plugin to another computer, the machine-id won’t match, and the plugin would require reactivation. Although this approach won’t prevent someone from bypassing the checking, it should be good enough for me. Anything I missed? This way, only the initial activation would need internet access.