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

flaviendelangle · 2022-04-25T16:58:38Z

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

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

flaviendelangle · 2022-04-25T16:59:03Z

packages/x-license-pro/src/useLicenseVerifier/useLicenseVerifier.ts

@@ -27,7 +28,11 @@ export function useLicenseVerifier(
      return sharedLicenseStatuses[packageName]!.status;
    }

-    const licenseStatus = verifyLicense(releaseInfo, licenseKey);
+    const acceptedScopes: LicenseScope[] = packageName.includes('premium')


This logic would have to become smarter if we release other plans

So to be sure that I understand it - the goal here is to if you have premium you also get pro right?

Yes
I first did a scale const scopes = ['community', 'pro', 'premium'] and then compare the index of the current plan with the one of the license
But it would not work with more granular scopes if we have some in the future
Right now it's a very basic check so both options work fine.

flaviendelangle · 2022-04-25T16:59:19Z

packages/x-license-pro/src/verifyLicense/verifyLicense.test.ts

-  });
+  describe('key version: 1', () => {
+    const license =
+      '0f94d8b65161817ca5d7f7af8ac2f042T1JERVI6TVVJLVN0b3J5Ym9vayxFWFBJUlk9MTY1NDg1ODc1MzU1MCxLRVlWRVJTSU9OPTE=';


We don't have the v1 generation anymore but it's worth testing it
This key is the doc key

mui-bot · 2022-04-25T17:11:19Z

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 🚫 dangerJS against 336bd21

DanailH · 2022-04-27T12:14:50Z

packages/x-license-pro/src/utils/licenseScope.ts

@@ -0,0 +1 @@
+export type LicenseScope = 'pro' | 'premium';


To be honest I was thinking to rework this to an enum because we are also using the strings themselves and it would be nice to avoid typos. It will also help if we have more licenses in the future. What do you think?

Not sure

Here we type the value, so we are sure that TS will complain if we put scope = "pri", just like for the enum.
And it will be obvious that a change to the type is breaking.

But if we use an enum, the typing is on the key of the enum, not its values.

So if by mistake we switch from

enum LicenseScope { pro = 'pro', premium = 'premium' }

To

enum LicenseScope { pro, // defaults to 0 premium, // defaults to 1 }

Then all our code will still work, but we will have done a breaking change for the licenses generated.

With that being said, I think both are viable as long as we follow the rule that an enum whose value can be stringified in any way must have its keys equal to its values.
In my previous company we had a ton of them on the plan generator specification and it never caused any issue.

mbrookes · 2022-04-27T18:09:56Z

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 · 2022-04-28T07:58:49Z

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 · 2022-04-28T08:03:36Z

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 · 2022-04-28T08:06:23Z

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 · 2022-04-28T08:09:52Z

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 · 2022-04-28T08:11:14Z

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 · 2022-04-28T10:36:19Z

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

mbrookes · 2022-04-28T16:00:01Z

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

PLAN = 'perpetual' | 'subscription'

What's SCOPE=${scope} ?

flaviendelangle · 2022-04-28T16:02:03Z

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 · 2022-04-28T16:03:02Z

TERM = 'perpetual' | 'subscription' ?

mbrookes · 2022-04-28T16:25:33Z

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

flaviendelangle · 2022-04-28T17:13:54Z

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 · 2022-04-28T17:57:45Z

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).

DanailH · 2022-05-02T09:58:42Z

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 · 2022-05-02T09:59:53Z

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

joserodolfofreitas · 2022-05-02T11:15:28Z

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 · 2022-05-02T11:18:07Z

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 · 2022-05-02T11:33:43Z

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 · 2022-05-03T09:31:23Z

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 · 2022-05-04T01:12:42Z

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 · 2022-05-04T09:38:17Z

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 · 2022-05-04T09:40:24Z

VALIDITY_DURATION ? VD in the license

joserodolfofreitas · 2022-05-04T09:49:39Z

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 · 2022-05-04T09:56:54Z

SALES_MODEL is fine for me

mbrookes · 2022-05-04T16:49:17Z

@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 · 2022-05-05T13:40:38Z

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

oliviertassinari · 2022-05-15T23:43:10Z

packages/x-license-pro/src/generateLicense/generateLicense.ts

+    throw new Error('MUI: Invalid sales model');
+  }
+
+  return `O=${details.orderNumber},E=${details.expiryDate.getTime()},S=${


Without this change, a v2 license key is not usable by < v5.11.0 of the software. It's not backward compatible. It surfaced in https://groups.google.com/a/mui.com/g/x/c/Nkq2fQbGkn0/. Time will tell if this causes trouble with more users, I suspect it will. If the intent is to shorten the string key, I doubt it's worth the breaking change. If a breaking change needs to happen, then I think bundling with #4892 could be great.

How about?

We revert the breaking change:

Suggested change

return `O=${details.orderNumber},E=${details.expiryDate.getTime()},S=${

return `O=${details.orderNumber},EXPIRY=${details.expiryDate.getTime()},S=${

We add support for both E and EXPIRY as license key prefix

We add support for [x-license] Use a simpler checksum for the license key #4892

We release and wait 6 months.

We replace EXPIRY -> E, md5 -> simpler checksum.

@joserodolfofreitas we are one week in, how are the upgrades support cases going? I haven't seen new ones, so maybe it's fine.

…i#4651)

flaviendelangle added 3 commits April 25, 2022 17:40

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

aca1806

Merge branch 'master' into license-plan-check

daf89fd

Work

85e74e1

flaviendelangle requested a review from DanailH April 25, 2022 16:58

flaviendelangle self-assigned this Apr 25, 2022

flaviendelangle commented Apr 25, 2022

View reviewed changes

Work

c39c2cf

flaviendelangle added package: x-license Specific to @mui/x-license. plan: Premium Impact at least one Premium user labels Apr 25, 2022

flaviendelangle added this to the Launch Premium Plan milestone Apr 25, 2022

flaviendelangle requested a review from oliviertassinari April 25, 2022 17:03

flaviendelangle added 3 commits April 25, 2022 19:13

Work

d06402a

Work

0ed09b9

Merge branch 'master' into license-plan-check

c7dd1b9

DanailH reviewed Apr 27, 2022

View reviewed changes

flaviendelangle requested a review from DanailH April 27, 2022 15:49

Work

1e18b49

flaviendelangle requested review from joserodolfofreitas and mbrookes May 3, 2022 09:31

Work

4b8f75f

flaviendelangle added 4 commits May 4, 2022 14:25

Merge branch 'master' into license-plan-check

d348529

Work

2cd8f7c

Work

f78817c

Work

9af2a9d

Work

501769c

DanailH approved these changes May 5, 2022

View reviewed changes

Rename sales model into license model

336bd21

flaviendelangle merged commit 1748bd3 into mui:master May 6, 2022

flaviendelangle deleted the license-plan-check branch May 6, 2022 08:44

oliviertassinari mentioned this pull request May 12, 2022

[x-license] Improve the error messages #1364

Open

10 tasks

oliviertassinari reviewed May 15, 2022

View reviewed changes

oliviertassinari mentioned this pull request May 18, 2022

[core] Upgrade MUI X dependency mui/material-ui#32824

Merged

alexfauquette pushed a commit to alexfauquette/mui-x that referenced this pull request Aug 26, 2022

[license] Allow to limit some packages to a specific license plan (mu…

8396a4e

…i#4651)

	return `O=${details.orderNumber},E=${details.expiryDate.getTime()},S=${
	return `O=${details.orderNumber},EXPIRY=${details.expiryDate.getTime()},S=${

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

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

Conversation

flaviendelangle commented Apr 25, 2022 • edited by oliviertassinari Loading

flaviendelangle Apr 25, 2022

Choose a reason for hiding this comment

DanailH Apr 27, 2022

Choose a reason for hiding this comment

flaviendelangle Apr 27, 2022

Choose a reason for hiding this comment

flaviendelangle Apr 25, 2022

Choose a reason for hiding this comment

mui-bot commented Apr 25, 2022 • edited Loading

DanailH Apr 27, 2022

Choose a reason for hiding this comment

flaviendelangle Apr 27, 2022 • edited Loading

Choose a reason for hiding this comment

mbrookes commented Apr 27, 2022

flaviendelangle commented Apr 28, 2022

DanailH commented Apr 28, 2022

flaviendelangle commented Apr 28, 2022

joserodolfofreitas commented Apr 28, 2022 • edited Loading

flaviendelangle commented Apr 28, 2022

DanailH commented Apr 28, 2022

mbrookes commented Apr 28, 2022

flaviendelangle commented Apr 28, 2022

mbrookes commented Apr 28, 2022 • edited Loading

mbrookes commented Apr 28, 2022

flaviendelangle commented Apr 28, 2022

DanailH commented Apr 28, 2022

DanailH commented May 2, 2022

flaviendelangle commented May 2, 2022

joserodolfofreitas commented May 2, 2022 • edited Loading

joserodolfofreitas commented May 2, 2022

flaviendelangle commented May 2, 2022

flaviendelangle commented May 3, 2022

mbrookes commented May 4, 2022

joserodolfofreitas commented May 4, 2022

flaviendelangle commented May 4, 2022

joserodolfofreitas commented May 4, 2022 • edited Loading

flaviendelangle commented May 4, 2022

mbrookes commented May 4, 2022 • edited Loading

flaviendelangle commented May 5, 2022

oliviertassinari May 15, 2022 • edited Loading

Choose a reason for hiding this comment

oliviertassinari May 23, 2022

Choose a reason for hiding this comment

flaviendelangle commented Apr 25, 2022 •

edited by oliviertassinari

Loading

mui-bot commented Apr 25, 2022 •

edited

Loading

flaviendelangle Apr 27, 2022 •

edited

Loading

joserodolfofreitas commented Apr 28, 2022 •

edited

Loading

mbrookes commented Apr 28, 2022 •

edited

Loading

joserodolfofreitas commented May 2, 2022 •

edited

Loading

joserodolfofreitas commented May 4, 2022 •

edited

Loading

mbrookes commented May 4, 2022 •

edited

Loading

oliviertassinari May 15, 2022 •

edited

Loading