[license] Allow to limit some packages to a specific license plan

[flaviendelangle]

• [x] Handle KEYVERSION=2 in verifyLicense
• [x] Handle both perpetual and subscription sales models
• [x] Do not accept pro licenses for premium features
• [x] Change the doc demonstration license to be a v2 license with the premium scope*
• [x] Check salesModel and scope value validity both on license encoding and decoding to avoid typos

Close #3925

https://deploy-preview-4651--material-ui-x.netlify.app/x/advanced-components/#license-key-installation

[mui-bot]

These are the results for the performance tests:

Test case	Unit	Min	Max	Median	Mean	σ
Filter 100k rows	ms	262.1	468.3	375.6	357.78	72.723
Sort 100k rows	ms	447.3	865	651.4	661.42	133.248
Select 100k rows	ms	111	195.3	161.5	156.74	34.419
Deselect 100k rows	ms	105.7	208	164.7	162.44	39.975

Generated by :no_entry_sign: dangerJS against 336bd216f6c6d960025e91e94f237039cdd232cc

[mbrookes]

We need to be able to distinguish between Pro perpetual and Pro subscription, and display the appropriate console message/watermark when the license is expiring soon/expired. (Existing perpetual customers will be able to renew their perpetual license.)

[flaviendelangle]

We need to be able to distinguish between Pro perpetual and Pro subscription, and display the appropriate console message/watermark when the license is expiring soon/expired. (Existing perpetual customers will be able to renew their perpetual license.)

@DanailH that's information we currently don't have I think

[DanailH]

Nope, we don't have that info in the license. When I was updating it I didn't know what this was a requirement.

[flaviendelangle]

Me neither @mbrookes, here is the current v2 format:

ORDER=${orderNumber},EXPIRY=${expiryTimestamp},KEYVERSION=2,SCOPE=${scope}`

We would need to add a TIMEOUT_STRATEGY: 'perpetual' | 'annual' (if you have a shorter key name that would be great @DanailH) If there are other information we need to add ?

Do we switch the TIMEOUT_STRATEGY to annual for all new licenses after the next release ?

[joserodolfofreitas]

Do we switch the TIMEOUT_STRATEGY to annual for all new licenses after the next release ?

No, I thought that'd be the case, and then we could simply use the expiryDate. But renewals from perpetual plans will remain perpetual as well. So we'll need an extra attribute for those cases.

[flaviendelangle]

But renewals from perpetual plans will remain perpetual as well. So we'll need an extra attribute for those cases.

Yes, otherwise we could have said "if license creation date > XXX then if's perpetual".

[DanailH]

How about DURATION='perpetual' | 'annual' instead of TIMEOUT_STRATEGY?

[mbrookes]

How about DURATION='perpetual' | 'annual' instead of TIMEOUT_STRATEGY?

PLAN = 'perpetual' | 'subscription'

What's SCOPE=${scope} ?

[flaviendelangle]

PLAN = 'perpetual' | 'subscription'

We use the term "plan" to differentiate "pro plan" and "premium plan" so I would not use it to describe the duration during which the license is valid.

What's SCOPE=${scope} ?

SCOPE currently contains the plan I think @DanailH and @oliviertassinari went for scope instead of plan in the license to be more abstract and be able to add scopes that are not plans (maybe an additional license for one specific very high value data grid plugin).

[mbrookes]

TERM = 'perpetual' | 'subscription' ?

[mbrookes]

The alternative is that we continue to use the v1 key format for perpetual licenses.

[flaviendelangle]

The alternative is that we continue to use the v1 key format for perpetual licenses.

We dropped the algo so we would need to re-add it But that would work yes

@DanailH @oliviertassinari what's your opinion here ?

[DanailH]

I think it would be better to just use the new version. I guess even if we use v1 for perpetual licenses we would still have the problem of not knowing the SCOPE unless the Premium plan can't be perpetual (initially it was PLAN but as we can have addons in the future we thought that SCOPE is more appropriate).

[flaviendelangle]

@DanailH I updated it with TERM

[flaviendelangle]

By the way, the encoded license if becoming long, should we use initial for keys ?

With full keys: 5abdc6ddfa0eec6e04e57360c6bc5997T1JERVI9TVVJLVN0b3J5Ym9vayxFWFBJUlk9MTY4Mjg0NDU0MjQwNixLRVlWRVJTSU9OPTIsU0NPUEU9cHJlbWl1bSxURVJNPXN1YnNjcmlwdGlvbg==

With initial keys: 1076e2f8a8dea8d320e2298048600169Tz1NVUktU3Rvcnlib29rLEU9MTY4Mjg0NDY3OTY5NCxLVj0yLFM9cHJlbWl1bSxUPXN1YnNjcmlwdGlvbg==

With initial keys a 's' | 'p' instead of 'subscription' | 'perpetual': 4b5b5c1f296ded5427a6aed095790731Tz1NVUktU3Rvcnlib29rLEU9MTY4Mjg0NDkyNzE2OCxLVj0yLFM9cHJlbWl1bSxUPXM=

In which case I would update the licensedecode to return the full keys of course

[mbrookes]

@flaviendelangle

We dropped the algo so we would need to re-add it

We have numerous Pro customers who have license keys in v1 format, so we we need to continue to support it regardless. Even if they don't renew, the license is by definition perpetual, so it will need to be supported for the foreseeable future so that they get a meaningful message if they try to upgrade in a year's time with a then out-of-date v1 license key.

Or was this with reference to key generation rather than check?

@DanailH

I guess even if we use v1 for perpetual licenses we would still have the problem of not knowing the SCOPE unless the Premium plan can't be perpetual.

• Premium will be Subscription only*.
• Pro can be perpetual (customers who purchased before the change), or Subscription*.

*As far as right to develop and use new versions goes. The right to use in production will perpetual for versions released during the license period.

[mbrookes]

should we use initial for key

Yes. No reason to have the full key in the license string.

[mbrookes]

I updated it with TERM

A quick web search suggests that "model" is the accepted term. Sorry!

[flaviendelangle]

Or was this with reference to key generation rather than check?

Yes just the key generation We still have the algo to decode it, not the algo to encode it

[flaviendelangle]

A quick web search suggests that "model" is the accepted term

model is not very explicit to me, is this something most dev would understand just by ready the key ? If we do use the initial for keys, I would use very explicit keys like VALIDITY_DURATION (VD)

[DanailH]

I updated it with TERM

I'm ok with this. One thing - shouldn't the default be perpetual as that is the default for pro as far as I understood it? That way it won't be breaking for already existing licenses (it's the same thing that we did for the scope).

[flaviendelangle]

That way it won't be breaking for already existing licenses

Why would the other default break the existing license ? Are you talking about the default in encoding or decoding ?

For me we are updating the store to pass this value (so that the store can decide to pass "perpetual" when the user is expanding a perpetual license). So the default value in encoding, like for "plan" is temporary and just impacts the 1st licenses created before we update the store. For those first licenses, should we set them to perpetual or to annual ? If we do "annual", then we must not do any renewal before updating the store If we do "perpetual", then we should update the store quickly because our terms saying that our licenses are annual will be wrong.

In both cases, I think that we should already have an open PR on the store to update it just after the release. Otherwise, we will stay in this migration phase for to long.

[DanailH]

Ok, breaking is probably not the correct term but rather if we do it like this then you should also update the Pro product on the store. With the other approach, one only needs to handle the Premium product in the store.

[flaviendelangle]

The new pro licenses will be perpetual ? I thought they were going to be annual just like the premium licenses.

[joserodolfofreitas]

What about PERPETUITY = 'production' | 'development' ? After all, licenses will still be perpetual, but in production only. And we'll need to "advertise" that (Not to say that this is an argument per se).

We may also consider, in the future, removing the console warning from test environments (and leaving the watermark). We have complaints on zendesk about the annoying volume of log messages related to the license. In this case, we could later expand the implementation with: PERPETUITY = 'production' | 'development' | 'test'

We might not need to expand it though.*

[joserodolfofreitas]

The new pro licenses will be perpetual ? I thought they were going to be annual just like the premium licenses.

New Pro licenses generated for a previous customer will still be perpetual in development. But for new customers, it will be perpetual in production only.

[flaviendelangle]

New Pro licenses generated for a previous customer will still be perpetual in development. But for new customers, it will be perpetual in production only.

Can we call the "annual in dev but perpetual in prod" just "annual" for simplicity ?

[flaviendelangle]

PERPETUITY = 'production' | 'development' PERPETUITY = 'production' | 'development' | 'test'

Not a huge fan tbh If we set `PERPETUITY=test", it's not obvious if it means "test" + "development" or just "test". I would prefer to keep the abstraction and let the code choose on which env to do the check rather than trying to describe the env on the license itself.

And if we decide to remove the warning on test, I guess it should be retroactive, not just for the new licenses. Otherwise we would basically be saying to the user complaining "ok you are right, you will get the fix in one year".

[mbrookes]

PERPETUITY = 'production' | 'development' PERPETUITY = 'production' | 'development' | 'test'`

Not a huge fan tbh

Me neither, sorry, just for the name alone.

Can we call the "annual in dev but perpetual in prod" just "annual" for simplicity ?

That would be "subscription in dev, perpetual in prod", and its proposed to just call it "subscription", so sounds like that's agreed.

[joserodolfofreitas]

PERPETUITY = 'production' | 'development' PERPETUITY = 'production' | 'development' | 'test'`

Not a huge fan tbh

Me neither, sorry, just for the name alone.

Ok, np. But I think "term" is not really exact either. I think it's going to be confused with the "License Term" we'll use to define how many years the license will be valid.

License Term means the period of time during which Licensee is authorized to use Program(s) in accordance with the applicable license grant.

[flaviendelangle]

VALIDITY_DURATION ? VD in the license

[joserodolfofreitas]

Validity and duration kinda mix two concepts, but I like the idea of using very explicit keys.

But I'm pondering, and model seems indeed the best name that we could use for this situation.

If you think model is not clear, what about: SALES_MODEL: 'perpetual' | 'subscription' TERM: number (int) ?

p.s.: TERM doesn't need to be accounted for on the key generation as it will receive a correct expiry date based on the license term picked in the UI

[flaviendelangle]

SALES_MODEL is fine for me

[mbrookes]

@flaviendelangle

model is not very explicit to me

It's "licensing model". I used "model" for short as we were looking for short words.

https://www.10duke.com/software-licensing-models/ https://cpl.thalesgroup.com/software-monetization/software-license-models https://www.google.com/search?hl=en&q=licensing%20model

Now that we're using initials instead, it isn't a problem.

SALES_MODEL is fine for me

A sales model is something different.

[flaviendelangle]

I will name it licensing model / lm, has been approved by the team during the product meeting :+1: