3 ms·
At one of my jobs we used a 3rd party library for .NET to do our licensing but then we decided to roll our own. By rolling our own we got the benefit of doing t
by jetti 10y ago
At one of my jobs we used a 3rd party library for .NET to do our licensing but then we decided to roll our own. By rolling our own we got the benefit of doing things that wouldn't be available in commercial solutions. For instance, we sold our software in modules and you bought each module separately but they each fit into the product. With our homemade system we could disable or enable modules at will from our system and have the user refresh. They had to connect once a year but if they bought a new module they could just go to the help menu and refresh their license and the module would unlock immediately. Not sure if you can do that with other commercial products or not.
- ezekg 10y agoYou're one of the first developers I've talked to that actually implemented feature-licenses (modules, add-ons, etc.). That's something I'd love to know more about. How do you handle toggling features within the codebase? I'd imagine that you'd handle it kind of like you would with feature flags?
- duncan-donuts 10y agoI am as thinking it might involve a lot of ACLs. I'm curious too
- jetti 10y agoNot as complex as ACLs, in the strict sense. Take a look at my response here: https://news.ycombinator.com/item?id=13500058 https://news.ycombinator.com/item?id=13500058
- jetti 10y agoI'm going to preface this with the fact that it has been a couple years since I implemented this and so my memory may be a bit hazy but here we go... We sent XML that was signed with public/private keys and we just used XPath to figure out what modules were allowed. We would load the file into memory from disk on application start up and then would persist to disk any time they updated their license. We stored a bunch of information in that XML document such as trials, machine name, machine hash (which took a combination of factors) and sent those all back to our server on registration/update. We were able to track the number of licenses used as well as the number of machines and which machines had licenses. Then comes the issue of non-internet connected machines. We had our program calculate the signed data based on the factors listed above and then had them paste it in a special section on our website. We then generated our key for them and told them to paste it into the application which then persisted to disk. They would have to do that every time they wanted to update but it was very easy and low friction. Was it the most effeicent way of doing things? Probably not. Was it the most secure? Definitely not. But it was easy to implement, easy to use and provided, what we thought, was a great UX for the end user while still maintaining some sort of licensing controls. *EDIT: On the server backend we had just a simple database that had each module, customer, machine name, and access (probably some more info, it's been a few years since I've looked at this as I've moved on). EDIT 2: I've actually thought of taking what I learned from that and starting a licensing as a service that will provide the flexibility of what I implemented so that you could provide fine grain access in your product fairly easily. I'm not sure if there would be enough interest though.
- ezekg 10y agoThanks for the in-depth reply. I hope you don't mind, but I sent you an email with a few additional questions. (I used the email from your HN profile.) I'm actually developing a licensing SaaS (in closed beta, currently), so I'd love to chat more if you have time.