You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

There are many different ways you can use token-based licensing, as described in the following examples.

License pools

One primary use for token-based licensing is to let users purchase a number of pseudo-features that each require one or more real licenses. This gives users a "pool" of licenses they can draw upon for license checkout requests, providing the flexibility to use various combinations of features as their needs require.

For example, say that the product suite MySolutions consists of three individually sold features: MyDraw, MyWrite, and MySpreadsheet. ABC Corp purchases 20 token-based licenses of MySolutions, including all three applications. Whenever there is a checkout request for one of these three applications, a particular number of licenses is taken from the 20-license pool for the MySolutions suite: MyDraw requires 5 licenses for each checkout; MyWrite requires 2 licenses, and MySpreadsheet requires 1 license.

As you can see from the two different scenarios below, a pool of token-based licenses gives customers significantly more flexibility than purchasing a specific number of licenses for each feature. The users can check out any combination of the features, up to the maximum 20-license limit.

Example Scenario 1

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

 

 

1

Example Scenario 2

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

 

 

0

Example

The following example shows a token-based license for the license pool scenario described above, where MySolutions is a license pool that is drawn upon to fulfill license requests for MyDraw, MyWrite and MySpreadsheet.

FEATURE MySolutions
{
VENDOR = ABC_Software
COUNT = 20
KEYTYPE = EXCLUSIVE
MAJOR_VERSION = 1
MINOR_VERSION = 2
KEY = GTLP4FLUFFDFJB3N87SEVB224G0TJKKP
}
FEATURE MyDraw
{
VENDOR = ABC_Software
KEYTYPE = TOKEN
MAJOR_VERSION = 1
MINOR_VERSION = 0
TOKEN_DEPENDENCY = "FEATURE=MySolutions VERSION=1.0 COUNT=5"
KEY = PTZH9BTWNTLFJHH862IOAF39NHIM9HVB
}
FEATURE MyWrite
{
VENDOR = ABC_Software
KEYTYPE = TOKEN
MAJOR_VERSION = 1
MINOR_VERSION = 0
TOKEN_DEPENDENCY = "FEATURE=MySolutions VERSION=1.0 COUNT=2"
KEY = KW1OPU87VNUAA9ZI2NMBP9721EEU2 
}
FEATURE MySpreadsheet
{
VENDOR = ABC_Software
KEYTYPE = TOKEN
MAJOR_VERSION = 1
MINOR_VERSION = 0
TOKEN_DEPENDENCY = "FEATURE=MySolutions VERSION=1.0 COUNT=1"
KEY = PO3OP36RLTATVFHOT3H4RONIOV257L98
}

 Product suite licenses

Product suite licenses specify that 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. This is essentially the opposite of license pools, which specify that multiple features depend on a single real license. 

For example, MyDraw may be composed of two modules: Sketcher and Printer. A token-based license can specify that in order to use MyDraw, you must have 1 license of each of the two modules.

Example

The following example shows a token-based license for the product suite license scenario described above.

FEATURE Sketcher
{
VENDOR = ABC_Software
COUNT = 5
KEYTYPE = EXCLUSIVE
MAJOR_VERSION = 2
MINOR_VERSION = 0
KEY = GTLP4FLUFFDFJB3N87SEVB224G0TJKKP
}
FEATURE Printer
{
VENDOR = ABC_Software
COUNT = 5
KEYTYPE = EXCLUSIVE
MAJOR_VERSION = 1
MINOR_VERSION = 5
KEY = HEN3CRJ8VOI6FS5L25KKB0QLRJD3CE4O
}
FEATURE MyDraw
{
VENDOR = ABC_Software
KEYTYPE = TOKEN
MAJOR_VERSION = 1
MINOR_VERSION = 2
TOKEN_DEPENDENCY = "FEATURE=Sketcher VERSION=2.0 COUNT=1"
TOKEN_DEPENDENCY = "FEATURE=Printer VERSION=1.5 COUNT=1"
KEY = ALPO3OP36RLTATVFHOT3H4RONIOV257L
}

 Alternate licenses

You can use token-based licenses to allow license requests to be fulfilled by one or more alternate product licenses. This enforces a logical OR rule, since it requires one license or another to succeed with a checkout.

For example, instead of providing a real license of MyDraw, you could define a license where MyDraw has a token dependency fulfilled by either Lower_Priced_License or Higher_Priced_License. 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 licenses in the license file determines the order that alternate checkouts are attempted. 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. Higher_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 license 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.

FEATURE Lower_Priced_License
{
VENDOR = ABC_Software
COUNT = 5
KEYTYPE = EXCLUSIVE
MAJOR_VERSION = 1
MINOR_VERSION = 0
KEY = CTLF6UIWOPPQYH35Q7WPYB7W2NH68JI9
}
FEATURE Higher_Priced_License
{
VENDOR = ABC_Software
COUNT = 10
KEYTYPE = EXCLUSIVE
MAJOR_VERSION = 1
MINOR_VERSION = 0
KEY = AP1FYIS98WPN2UIP99QSVUIPA4EEOV26
}
FEATURE MyDraw
{
VENDOR = ABC_Software
KEYTYPE = TOKEN
MAJOR_VERSION = 1
MINOR_VERSION = 0
TOKEN_DEPENDENCY = "FEATURE=Lower_Priced_License VERSION=1.0 COUNT=5"
KEY = HEN3CRJ8VOI6FS5L25KKB0QLRJD3CE4O
}
FEATURE MyDraw
{
VENDOR = ABC_Software
KEYTYPE = TOKEN
MAJOR_VERSION = 1
MINOR_VERSION = 0
TOKEN_DEPENDENCY = "FEATURE=Higher_Priced_License VERSION=1.0 COUNT=10"
KEY = ALF5HUJ9VCQ6HSNL42MLT0VLMJC3PDMM
}

 Cascading (recursive) licenses

Cascading licenses let you specify a recursive list of token-based licenses, all of which must be available in order to fulfill a checkout request.

For example, say that the application MyWrite depends on one license of MyDraw, which in turn depends on two licenses of Sketcher. With this recursive dependency, MyWrite checkouts will consume two licenses.

The maximum number of recursive dependencies you may define for a token-based license is 256. (However, there is no limit on the number of token-based licenses you may define.)

Example

The following example shows a token-based license for the cascading license scenario described above.

FEATURE Sketcher
{
VENDOR = ABC_Software
COUNT = 10
KEYTYPE = EXCLUSIVE
MAJOR_VERSION = 1
MINOR_VERSION = 0
KEY = GTLP4FLUFFDFJB3N87SEVB224G0TJKKP
}
FEATURE MyDraw
{
VENDOR = ABC_Software
KEYTYPE = TOKEN
MAJOR_VERSION = 2
MINOR_VERSION = 0
TOKEN_DEPENDENCY = "FEATURE=Sketcher VERSION=1.0 COUNT=2"
KEY = HEN3CRJ8VOI6FS5L25KKB0QLRJD3CE4O
}
FEATURE MyWrite
{
VENDOR = ABC_Software
KEYTYPE = TOKEN
MAJOR_VERSION = 2
MINOR_VERSION = 0
TOKEN_DEPENDENCY = "FEATURE=MyDraw VERSION=2.0 COUNT=1"
KEY = ALPO3OP36RLTATVFHOT3H4RONIOV257L
}


  • No labels