Which license model suits for my application getting deployed in Customer private cloud

[ganesh-bhanage]

Hi,
I am trying to explore options for licensing for one of our customers. Here we are going to share our docker images as artifacts with them. They are then going to deploy it in their private cloud.
I was wondering if Offline licensing methodology would work here. Please share little more insight on the same. As this is a new domain for me.

[ezekg]

For Keygen EE, we use license files. These are a cryptographically signed and encrypted "snapshot" of a license that can be decrypted and their authenticity verified in an offline environment to pull in license and entitlement data, e.g. license expiry and feature flags in our case.

[ganesh-bhanage]

So this Offline License verification can be done periodically in my application to check if the license is not expired correct? Also is it possible that Org receiving this license can further pass it on to another Org with same license file, and now tow Orgs are using my application as 2 instances but with same license file?

[ezekg]

Keygen can handle 1-3. This is exactly how we license Keygen EE to customers using license files. We have lots of implementation examples on our GitHub. Number 4 is less about Keygen and more about the contract on your end. But again, a license file will be locked to a particular license and customer, so given your software is proprietary and not open source under e.g. MIT — they won't be able to resell it, legally. And if they do, it can easily be traced back to them if they're reselling their own license file.

To sum up, license files are:

1. a secure tamper-proof snapshot of a license, and a license can have an expiration date. In addition, the license file itself will have its own expiration date. In your case, these should roughly match, i.e. the license should have a 1-year expiry, configurable via the policy, and the license file should have a 1-year TTL, configurable during checkout. For example, for Keygen EE, we typically do a 1-year license and 1-year license file. Sometimes we do 2 or 3 years, or perpetual, dependent upon contract.
2. able to include entitlements embedded inside of them. You can attach entitlements to a license, or to its policy, to associate feature flags and other entitlement information. To include entitlement information, you can ?include=entitlements during checkout. For example, in Keygen EE, we have several entitlements like PERMISSIONS and ENVIRONMENTS that we check before allowing those features to be used.
3. not locked to a particular node. They can be, but that's known as a machine file, and the implementation for those are a little tough for a container-based environment like you're describing. So you're on the right track here, and you're doing exactly what we do with Keygen EE.
4. a snapshot of a particular license, which can include customer name, etc.

Hope that helps? Let me know.

[ganesh-bhanage]

Can i try and set this up in my local machine, just to get a hang of it. Also would like to know pricing for this model?

[ezekg]

License files are available on all tiers. Pricing is here: https://keygen.sh/pricing/

[ganesh-bhanage]

@ezekg , BTW in general which license model is the best solution for an application whose artifacts are docker images?

[ezekg]

That's a loaded question lol. It depends on many factors, most chiefly being your business model. What I mean by that is, do you want to bill per-container? Flat-fee for unlimited containers? Are the environments the containers run in online or offline? Do you want to control concurrency i.e. not just number of containers but also number of processes? Or do you just want to validate license keys?

Lots of variables. But there's flexibility to do almost everything.