Hi Thomas. I did actually read that a few days ago and found it very helpful but it seems to be based around a license file system and I want to base my licensing purely around a serial number given to a customer at checkout from a previously existing list of serials. Or could AP be modified to help achieve what I need?
Markus, because validating against the list would require web app communication each time. I only want web app communication for the initial activation or final deactivation. App launch after that needs to validate within Xojo app alone.
Maybe you are stressed out because you overthink it.
I crypt the user name and format it so it looks like most license numbers around : C7D6-EAE7-A852-992E-7D4C
The user can unlock his product with simply his name, and that license number. It is simple to implement in my software.
No need to call home for a predetermined list of numbers.
A time limit is just as simple to implement by incorporating it into the encryption key.
Tying a license to a particular machine with the UUID is another matter. I am not quite sure it is acceptable in this modern world anymore, but that is your call.
Online validated → create SHA512 Hash of serial + computerID + salt and store that to validate against locally. Can run on THIS computer with the validation file but not on another computer.
Overall I agree with Michel though. Better spend the time working on your app.
Markus: Ahhh…that’s clever!
Michel, I guess I could either tie time limit into serial or the validation file Markus proposed.
The thing is, I frankly believe tying a license to a computer nowadays when we all have several devices is a thing of the past. Most of my customers have a desktop and a laptop. I don’t think I can force them to stick to one, or even to buy an extended license.
Michel: I usually grant 2 or 3 activations per product so that never normally becomes an issue, especially if they are allowed to deactivate one machine and activate another using the same serial.
The issue is : how much friction does managing activations/deactivations and user frustration is worth it ?
For myself, I have elected to give users freedom, which in turn means a lot less work for me, leaving me more time to develop and market my software.
But that’s me. Each one his own.
No, AP is based on NOT using (cyphered) serials but putting everything in the open. And I yet have to see a single license being distributed illegally as a “free for everyone”. In my most successful app, Find Any File, it’s even simpler: All you need to know is a “secret” click that is the same for EVERYONE. And yet, despite having several 10.000s of installations, I never found a website that would reveal this info openly (I use a saved Google search to get updated on anything related to my app, and while it regularly finds new web sites mentioning the app).
However, my apps are in the price range from $5 to $15, so it’s not a big deal for people staying honest.
If you’re selling a $100 product, it’s more likely people try to get around its licensing protection.
But still - experience shows that software that’s widely available is more likely to generate real sales. Even pirated software adds to its popularity, as free advertising.
Using the AQ approach, with including the buyer’s name and email into the license file (which can’t be modified without invalidating the license file) is enough of a deterrent for most. And if one gets out into the wild - I’d simply blacklist them in the next release, or instead “congratulate” the user of a pirated license to ■■■■ me off 
Also, like Michel points out, the AQ method does generate hardly any support efforts for me. No one needs to deactived their license, with all its complications etc. Have a little faith and support your loyal customers by not making it too hard on them.
Thomas: I do understand you and Michel’s argument but I do support my loyal customers in many other ways, sometimes more than developers who offer the unrestricted activation model so really in my particular case it’s just down to preference and for me I prefer an activation restriction model … which is especially required when it comes to site licenses for schools etc.
I am still a little confused by AQ approach though because it still sounds like I can’t use it on the restriction model I require and on a pre-existing list of serials that aren’t in any way tied to a user name or email etc. If I am mistaken could you please clarify a little more how I could use AQ to suit my specific needs?
You can have additional fields for validation in Aquatic Prime. For instance a date or a machine ID. You can deliver a license as a file or as long serial number where you could add your SKU. Different products have different keys.
As for implementing it Thomas website has all the examples. There is a simple app “Aquatic Prime Developer” where you define private and public keys. In the app you load the license and validate it against your fields.
Fastspring is very good but also very expensive. If I wanted to jump the ship I’d do a small webapp to handle the license delivery with AQ.
Thanks, Beatrix. That helps and is good advice. In the method you suggest can AQ use your method to deliver a serial in the form similar to XXXX-XXXX-XXXX-XXXX etc or would the serial be very long and annoying to the user? Also, does AQ rely on anything such as dll/dylib or another library that might require a third-party to update it in the future or is it pure code that I can handle?
The serial would become very large. This is a typical license file, where the xxxx part already is in base64:
[code]<?xml version="1.0" encoding="UTF-8"?>
Email xxxxxxx Name xxxxxxxxx Signature xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx [/code]This is the problem. I just want to distibute a serial number to a customer that already exists in a list and is not auto-generated upon purchase etc as per Markus’s suggestion.
Hang on. Can’t I just generate a random list of serials (as per Markus) and then this can be used by AQ as the unique identifier (instead of email address and name etc) and then from this AQ creates a license file that is stored on the user’s system and then the app checks this for validation?
To clarify: With AQ, you would deliver a file. Or your website or delivered email would have a special URL scheme link like “yourappname-license://xxx”, which xxx being the base64 encoded file content, for instance. That way, a user would then click the link, and if your app is already installed and therefore has registered this URL scheme with the system, clicking the link would launch your app and it would get the data from the clicked URL, which it decodes and stores as a license file.
I mean, if you deliver a long code, how do you think people will use that? You don’t want them to type it in, right? So they have to copy and paste it. With that, the link idea works better (which, of course, you could also use if you’d not use AQ but just want to deliver that serial to your app without the user having to copy and paste it).
Also, you can embed your pre-generated serial number into the AQ license file. Though that’s kind of redundant, assuming you’ll use a direct internet connection to validate the serial then? But if you don’t do live validation, then embedding the serial in the AQ file is a way to verify that the serial is valid. But if you do that, you might as well generate your serial in a way that only certain values are valid. Of course, AQ provides all the tools for verification already, so that takes you off the task of having to come up with your own “tamper-proof” serial numbers. But either way, include the customer’s idenfitication regardless - it’s always a good extra deterrent if they see their name in it.
Thanks for clarifying Thomas.
How to register the URI scheme (for those like me who wondered):
http://blog.xojo.com/2016/05/09/let-your-os-x-desktop-app-react-to-custom-uris/
https://blog.xojo.com/2016/08/16/custom-uri-schemes-on-windows/
Thanks Markus.