Date: Fri, 29 Mar 2024 06:35:34 +0100 (CET) Message-ID: <42842552.5360.1711690534437@confluence-server> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_5359_1655065275.1711690534437" ------=_Part_5359_1655065275.1711690534437 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The in= formation on this page refers to v5.1 and newer, which banned sharing both = tokens and their dependencies at the same time. For documentation applicable to earlier versions= , see documentation for previous versions.= |
There are many different ways you = can use token-based licensing, as described in the following examples.
One primary use for token-based li= censing is to let users purchase a number of pseudo-features that each requ= ire one or more real licenses. This gives users a "pool" of licenses they c= an draw upon for license checkout requests, providing the flexibility to us= e various combinations of features as their needs require.
For example, say that the product = suite MySolutions consists of three individually sold features: MyDraw, MyW= rite, and MySpreadsheet. ABC Corp purchases 20 token-based licenses of MySo= lutions, including all three applications. Whenever there is a checkout req= uest for one of these three applications, a particular number of licenses i= s taken from the 20-license pool for the MySolutions suite: MyDraw requires= 5 licenses for each checkout; MyWrite requires 2 licenses, and MySpreadshe= et requires 1 license.
As you can see from the two differ= ent scenarios below, a pool of token-based licenses gives customers signifi= cantly more flexibility than purchasing a specific number of licenses for e= ach feature. The users can check out any combination of the features, up to= the maximum 20-license limit.
Example Scenario 1<= /strong>
Feature |
# of Licenses Consumed per Checkout |
# of Checkout Requests |
Total Licenses Consumed |
---|---|---|---|
MyDraw |
5 |
2 |
10 |
MyWrite |
2 |
3 |
6 |
MySpreadsheet |
1 |
3 |
3 |
Totals |
|
8 |
19 |
Number of licenses remaining= p> |
|
1 |
Example Scenario 2<= /strong>
Feature |
# of Licenses Consumed per Checkout |
# of Checkout Requests |
Licenses Consumed |
---|---|---|---|
MyDraw |
5 |
1 |
5 |
MyWrite |
2 |
4 |
8 |
MySpreadsheet |
1 |
7 |
7 |
Totals |
|
11 |
20 |
Number of licenses remaining= p> |
|
0 |
Example
The following example shows a toke= n-based license for the license pool scenario described above, where MySolu= tions is a license pool that is drawn upon to fulfill license requests for = MyDraw, MyWrite and MySpreadsheet.
FEA= TURE MySolutions { VENDOR=3DABC_Software COUNT=3D20 KEYTYPE=3DEXCLUSIVE VERSION=3D1.0 KEY=3Dbhq3ed873qcrKHG6783rhJgvkhvTUtxcuBiouVtyCuyVy78Gftq... } FEATURE MyDraw { VENDOR=3DABC_Software KEYTYPE=3DTOKEN VERSION=3D1.0 TOKEN_DEPENDENCY=3D"FEATURE=3DMySolutions VERSION=3D1.0 COUNT=3D5" KEY=3Db978bv5ybui7Noyg6c3Vd57fngN987NGSC54sDiugU6v5eio8g... } FEATURE MyWrite { VENDOR=3DABC_Software KEYTYPE=3DTOKEN VERSION=3D1.0 TOKEN_DEPENDENCY=3D"FEATURE=3DMySolutions VERSION=3D1.0 COUNT=3D2" KEY=3Dyig*bv7tu6r879yu09yut75evbGJvHGHdrCHJVJGCt79g78gvv... } FEATURE MySpreadsheet { VENDOR=3DABC_Software KEYTYPE=3DTOKEN VERSION=3D1.0 TOKEN_DEPENDENCY=3D"FEATURE=3DMySolutions VERSION=3D1.0 COUNT=3D1" KEY=3DhygvCTYGg6r67fg890hbyvGTCVKJBjhc5r7y9joiVGckjlnut8... }
Product suite licenses specify tha= t one token-based license depends on multiple real licenses. Product suite = licenses enforce a logical AND rule, requiring all licenses to be valid in order to perform a checkout. T= his is essentially the opposite of license pools, which specify that multip= le features depend on a single real license.
For example, MyDraw may be compose= d of two modules: Sketcher and Printer. A token-based license can specify t= hat in order to use MyDraw, you must have 1 license of each of the two modu= les.
Example
The following example shows a toke= n-based license for the product suite license scenario described above.
FEATURE= Sketcher { VENDOR=3DABC_Software COUNT=3D5 KEYTYPE=3DEXCLUSIVE VERSION=3D2.0 KEY=3DmBpIAWB9Uuzl2b2B3v]vcsFBx7qEQG1SwXCz8A9d612hU3vSKT... } FEATURE Printer { VENDOR=3DABC_Software COUNT=3D5 KEYTYPE=3DEXCLUSIVE VERSION=3D1.5 KEY=3DB9Uuzl2b2B3v]vcsFBx7qEvcsFBx7qEQG1SwXCz8A9d6U3vSKT... } FEATURE MyDraw { VENDOR=3DABC_Software KEYTYPE=3DTOKEN VERSION=3D1.0 TOKEN_DEPENDENCY=3D"FEATURE=3DSketcher VERSION=3D2.0 COUNT=3D1" TOKEN_DEPENDENCY=3D"FEATURE=3DPrinter VERSION=3D1.5 COUNT=3D1" KEY=3DmBpIAWB9Uuzl2b2B3v]vcsFBxBx7qEQG1SwXCz8A9dj1g866USKT...=20 }
You can use token-based licenses t=
o allow license requests to be fulfilled by one or more alternate product l=
icenses. This enforces a logical OR rule, since it requires one license
For example, instead of providing = a real license of MyDraw, you could define a license where MyDraw has a tok= en dependency fulfilled by either Lower_Priced_License or Higher_Priced_Lic= ense. Although the alternate token licenses may be more expensive than the = real license, the mapping allows users to more reliably access the software= they need.
The order of the token-based licen= ses in the license file determines the order that alternate checkouts are a= ttempted. For example, if the MyDraw features's Lower_Priced_License token-= based license precedes the Higher_Priced_License token-based license, then = Lower_Priced_License will be preferred for filling checkout requests. Highe= r_Priced_License will be used only if Lower_Priced_License is unavailable. = End users can change the license order if they desire.
Example
The following example shows a lice= nse for the alternate license scenario described above. Note that the first= MyDraw token-based license refers to Lower_Priced_License, so this will be= the preferred license for MyDraw checkout requests.
FEA= TURE Lower_Priced_License { VENDOR=3DABC_Software COUNT=3D5 KEYTYPE=3DEXCLUSIVE VERSION=3D1.0 KEY=3DmBpIAWB9Uuzl2b2B3v]8GJqW300arlnWmnT01nZXSOIYdF...=20 } FEATURE Higher_Priced_License { VENDOR=3DABC_Software COUNT=3D10 KEYTYPE=3DEXCLUSIVE VERSION=3D1.0 KEY=3DmBpIAWB9Uuzl2b2B3v]vcsFBx7qEQG1SwXCz8A9d6U3vSKT...=20 } FEATURE MyDraw { VENDOR=3DABC_Software KEYTYPE=3DTOKEN VERSION=3D1.0 TOKEN_DEPENDENCY=3D"FEATURE=3DLower_Priced_License VERSION=3D1.0 COUNT=3D= 5" KEY=3DmYsfn30C6ShBYszCq2WVicpTZXQwkfKJTohkzg1wNkle163...=20 } FEATURE MyDraw { VENDOR=3DABC_Software KEYTYPE=3DTOKEN VERSION=3D1.0 TOKEN_DEPENDENCY=3D"FEATURE=3DHigher_Priced_License VERSION=3D1.0 COUNT= =3D10" KEY=3D2w66Ng3wVSVp6ttmWCc8GyJqW300arlnWmnT01nZXSOIYdF...=20 }
Cascading licenses let you specify= a recursive list of token-based licenses, all of which must be available i= n order to fulfill a checkout request.
For example, say that the applicat= ion MyWrite depends on one license of MyDraw, which in turn depends on two = licenses of Sketcher. With this recursive dependency, MyWrite checkouts wil= l consume two licenses.
The maximum number of recursive de= pendencies you may define for a token-based license is 16.
The maximum number of dependencies= the token-based license may have is 512. (However, there is no limit on th= e number of token-based licenses you may define.)
Example
The following example shows a toke= n-based license for the cascading license scenario described above.<= /p>
FEATURE= Sketcher { VENDOR=3DABC_Software COUNT=3D10 KEYTYPE=3DEXCLUSIVE VERSION=3D1.0 KEY=3D2w66Ng3wVSVp6ttmWCc8GyJqW300arlnWmnT01nZXSOIYdF... } FEATURE MyDraw { VENDOR=3DABC_Software KEYTYPE=3DTOKEN VERSION=3D2.0 TOKEN_DEPENDENCY=3D"FEATURE=3DSketcher VERSION=3D1.0 COUNT=3D2" KEY=3D4i]mYsfn30C6ShBYszCq2WVicpTZXQwkfKJTohkzg1wNkle...=20 } FEATURE MyWrite { VENDOR=3DABC_Software KEYTYPE=3DTOKEN VERSION=3D2.0 TOKEN_DEPENDENCY=3D"FEATURE=3DMyDraw VERSION=3D2.0 COUNT=3D1" KEY=3DmBpIAWB9Uuzl2b2B3v]vcsFBx7qEQG1SwXCz8A9d6U3vSKT... }
Token-based licenses are always unlimited; therefore,
For example, you may have an application with multiple features th= at can be sold separately or together. Multiple instances of each feature c= an be shared on a single host. With token sharing, all instances of the particular feature sha= re licenses, but only amongst themselves, not between the different feature= s.
Token dependency sharing allows the features and their instances to share their available licenses and = thereby use the licenses more efficiently in cases where you do not want to= count features' licenses independently. Dependency sharing can be i= mplemented using multiple token-based licenses that share a common dependen= cy.
Tokens and their dependencies cann= ot both be shared at the same time.
Example Scenario
For example, say you have tw= o token-based features, "ModuleA" and "ModuleB," with a common token depend= ency, "Product." ModuleA requires three Product licenses and ModuleB requir= es two Product licenses, and there are a total of 10 Product licenses.
Without sharing implemen= ted, 2 instances of ModuleA (3 licenses required per instance * 2 inst= ances =3D 6) and 2 instances of ModuleB (2 licenses required per instance *= 2 instances =3D 4) will consume all 10 Product licenses.
Token sharing lets = you share licenses between multiple instances of ModuleA and ModuleB runnin= g on the same host. Using the same example with token sharing implemented, = two instances of ModuleA and two instances of ModuleB on a single host will= use only five licenses, because the licenses are shared between each f= eature's instances. Two instances of ModuleA share two Product license= s amongst themselves and two instances of ModuleB share three Product licen= ses among themselves.
Token dependency sharing= allows for sharing the dependency's licenses freely between ModuleA a= nd ModuleB. Continuing to use the same example with token dependency sharin= g implemented, two instances of ModuleA and two instances of ModuleB are ab= le to share just three Product licenses.
The example scenario described above is illustrated in the table below.<= /p>
Sharing Typ= e |
Product lic= enses used for two instances of ModuleA |
Product lic= enses used for two instances of ModuleB |
---|---|---|
None= |
6 |
4 |
Token shari= ng |
3 |
2 |
Token depen= dency sharing |
3 |
0 (shares 2 licenses with ModuleA) |
Token sharing license example
The f= ollowing example shows a token-based license for the token sharing scenario= described above.
FEATURE= Product { VENDOR=3DABC_Software COUNT=3D10 VERSION=3D1.0 KEY=3DmBpIAWB9Uuzl2b2B3v]vcsFBx7qEQG1SwXCz8A9d6U3vSKT... } FEATURE ModuleA { VENDOR=3DABC_Software KEYTYPE=3DTOKEN VERSION=3D1.0 SHARE=3DHOST TOKEN_DEPENDENCY=3D"FEATURE=3DProduct VERSION=3D1.0 COUNT=3D3" KEY=3D4i]mYsfn30C6ShBYszCq2WVicpTZXQwkfKJTohkzg1wNkle... } FEATURE ModuleB { VENDOR=3DABC_Software KEYTYPE=3DTOKEN VERSION=3D1.0 SHARE=3DHOST TOKEN_DEPENDENCY=3D"FEATURE=3DProduct VERSION=3D1.0 COUNT=3D2" KEY=3D2w66Ng3wVSVp6ttmWCc8GyJqW300arlnWmnT01nZXSOIYdF... }
Token dependency sharing license example
The following example shows a toke= n-based license for the token dependency sharing scenario described above.<= /span>
FEATURE= Product { VENDOR=3DABC_Software COUNT=3D10 VERSION=3D1.0 SHARE=3DHOST KEY=3DmBpIAWB9Uuzl2b2B3v]vcsFBx7qEQG1SwXCz8A9d6U3vSKT... } FEATURE ModuleA { VENDOR=3DABC_Software KEYTYPE=3DTOKEN VERSION=3D1.0 TOKEN_DEPENDENCY=3D"FEATURE=3DProduct VERSION=3D1.0 COUNT=3D3" KEY=3D4i]mYsfn30C6ShBYszCq2WVicpTZXQwkfKJTohkzg1wNkle... } FEATURE ModuleB { VENDOR=3DABC_Software KEYTYPE=3DTOKEN VERSION=3D1.0 TOKEN_DEPENDENCY=3D"FEATURE=3DProduct VERSION=3D1.0 COUNT=3D2" KEY=3D2w66Ng3wVSVp6ttmWCc8GyJqW300arlnWmnT01nZXSOIYdF... }