Thoughts on license management, licensing, selling etc.

When we build our business model on selling licenses (# of seats, time period) and renewals, we need to think hard about a few (additional) points:

 - tenant model (a company who does run MAMAS service for mutliple their-customers)
 - upgrades
 - cheating licensing by copying it multiple times (the MAMAS server does no online check)

The cheating licensing could be especially handy for a customer using multi-tenancy as it is very easy for her to copy the licensing file over several times, effectively having the same license on every MAMAS server. This can be battled on two fronts: introducing a "mother" license OR making this copying cumbersome and costly compared to a comfortable "license management" approach.

The idea is that the tenant-manager would be able to store all the licenses owned by the tenant customer, and their assignment to particular end-customers (of which each would have a separate MAMAS server running). Thus the tenant customer would have a clear overview of how many licenses are free to use, how are assigned and ideally what is the state (how many devices does each customer have - this can be read from the individual MAMAS server deployuments DB). We could also allow a handly "free-license" assignment for end-customers that would have a very low number of devices (say, 5 or something alike (NOTE: the default licensing policy (free license) must be changed appropriately). If we pack into the multi-tenant app also the functionality to start/stop/monitor individual MAMAS servers, if sould offer a nice package for the tenant customer, bringing hopefully enough of value to discourage from license cheating. Of course, this must be backed up with reasonable monetization strategy to both get some value for us but also do not make it too costly for the tenant-customer. NOTE: tenant-customer subscription could also be a model here once the number of licenses grows over some watermark.

Potential new flags for licenses: "beta", "upgrade", "version"

We should be able to limit license to a type of build - e.g. allow more devices (30 like now) for beta builds but at the same time, make this license defunct on production and also do not allow upgrades over some version etc... This way we limit cheating/abusal of development licenses on production and also copying new free licenses / old free licenses to old / new MAMAS deployments.

The cost policy should also help to reflect the multi-tenant type of customer. How?

 - we can think what are going to make money on (the most)
   - selling licenses to individual customers?
   - SAAS / subscription from individual customers? (complete service package inclusive, not just license)
   - selling licenses to tenant-customers
   - subscription to tenant-customers (not SAAS, but subscription allowing for a not-fixed but limited number of licenses - e.g. "any number of up to 10 device customers" etc...)
   - SUPPORT
      - note that we can diversify license costs on multiple points: # of seats, time period validity, features, support type
      - especially for multi-tenant customers, we need to comprehend they are effectively shielding us from the end-customers, taking some of the support burden on their own backs and enabling us to sell to a segment which would be otherwise non-profitable to us (e.g. handling a large number of small customers)
      - because of that, it may be appropriate to relax some of the costst for multi-tenant customers. By e.g. allowing discounts on small deployments (licenses for small deployments), we may structure costs on the total number of end-customer / devices -> which effectively bring us to a support costs aligned more to that than to a number of license sold.

To be continued...