We all know that, since release 18, Cinema 4D comes with three different licensing mechanisms to properly respond to our customer base’s licensing needs and to increase license management effectiveness.

Standalone, node-locked, permanent Cinema 4D licenses are, since the very early days, delivered using Cinema 4D Serials where specific modules and/or product bundles are licensed using the provided serial numbers.

Floating, non-permanent Cinema 4D license are currently delivered using one of the two license-serving mechanism represented by:

• MAXON License Server;
• Reprise License Manager.

Whilst the former was actually introduced earlier, the latter has become available since R18 and represents a standard for customers looking for a flexible, non-proprietary, 3^rd-party license management designed to centralize licensing operations for multiple client applications.

In R19 SP1 the RLM licensing mechanism has been slightly improved to allow our 3rd-party plugin developers to properly access Cinema 4D licensing information and, following the current practice, to bind their plugin licensing information to them.

It should be noted that whilst the MAXON License Server was designed to grant 3^rd-party plugins licenses provision by simply enrolling the plugin license into the MAXON License Server, delivering a similar hassle-free functionality using the RLM requires 3^rd-parties to integrate Reprise API into their products and to provide RLM compliant licenses due to the design of the RLM licensing infrastructure.

Aside from these two approaches, a third hybrid-one has been foreseen and implemented in R19 to still grant our developers to have their products properly licensed when RLM licensing takes place without too much effort.

It’s relevant to note that this approach relies on two pre-requisites:

1. the 3^rd-party developer has to load/save serial information locally on the client rather than querying the server;
2. the customer will be asked to install the 3^rd-party product’s license on each client where the product is supposed to be used rather than on the licensing server.

Given that RLM serves the client with a Cinema 4D license available in the RLM license pool, the mechanism, at the base of the third approach, can be schematized in two steps:

1. The plugin accesses the Cinema 4D license information querying the running client;
2. The plugin retrieves its license locally on the client and checks for its validity against the value retrieved on step 1.

The first step is achieved via an updated version of GeGetSerialInfo() which is capable to return Cinema 4D license information in a RLM context passing as SERIALINFO the value SERIALINFO_RLMLICENSE.

The second step is achieved using ReadRegInfo() which is capable to read private serial information when Cinema 4D is provided with a floating-license via a license server. It’s worthy to point out that the plugin license should have been stored on the client using WriteRegInfo() during the plugin license submission otherwise the ReadRegInfo() will fail to retrieve meaningful values.

The changes introduced in the GeGetSerialInfo(), when used to query for a Cinema 4D license in a RLM context, populate the SerialInfo::nr member with a String() based on the following pattern XXRSSSNNNNN useful to check retrieved plugin license against the running Cinema 4D license similarly to using the GeGetSerialInfo() in a MAXON License Server licensing scenario.

Looking forward hearing from you, feel free to comment, ask more or simply share your experience.

Happy licensing, Riccardo