Software Side Roads

Many software products, including Rhino, issue complex per-user license keys for trial use. I believe that a single trial license key per product for everyone is the best solution.

Understandably, many Rhino3D plugins follow the licensing user flows which Rhino itself does. Most of the time, that makes sense. The Cloud Zoo does, after all, have a supporting framework designed around those flows.

In this case we can improve the user experience using the same building blocks- in this case, the same http API endpoints. The shift I recommend does not place any limits on how the trial works after installation: time limits, one-time-only requirements per user, and the like.

Rhino itself, at the time of this writing, has in the typical case a stepwise user flow for new users:

1. Download a copy of Rhino from the mcneel.com website.
2. Make a note of the trial license code you’re being given
3. Go through one of two paths to add the license:
   • Visit the My Account section of mcneel.com and add it
   • Start Rhino and proceed through several stages of click-through (this procedure is not presently available for plugins because they don’t know the identity of the user but I’ve filed a request with McNeel for a feature enhancement)

In either case, the user has to remember or copy/paste a complicated, unique code. It feels complicated and the user might not copy/paste correctly. The user might also be interrupted during the process between wanting the trial and finishing the setup steps, in which case finding the correct code again both feels like and is a burden to the user. Issuing trials is a sales pitch: the process should be as simple as possible.

I believe that it’s much easier to have a fixed license key employed by users to request a trial. They don’t have to keep track of a string or go through a process to retrieve it if they forget. It’s never hidden in one step of some web click-throughs or in an email they have to rummage through an inbox to find.

The toolbox we have to work with, in the form of HTTP endpoints between McNeel’s server and the plugin vendor’s server, is the following set of transactions (the two optional ones are not required):

• Get: From McNeel to vendor as a result of the user asking to apply a license, “Tell me about this license”
• Add: From McNeel to vendor as a result of the user asking to apply a license, “The user has requested that we add this license to a user or group. Is that ok?”
• Remove: From McNeel to vendor as a result of the user wishing to remove a license probably to utilize it for another person or group, “The user has requested that we remove this license from a user or group. Is that ok?”

The technical details behind those endpoints are contained in the RhinoCommon section of McNeel’s “Guides” at rhino3d.com. Every license, per the spec, has a unique serial number and a unique license registration key. That last fact, however, doesn’t require what it seems to when issuing trial licenses.

The way Rhino appears (this is my best guess at what’s going on) to use the API for its own trial copies is the obvious path:

1. Either in advance or at the time of user request, create a license with a unique registration key. Notify the user of what this key is. They need to remember it or come back and find it, and because it’s unique that can’t be a simple location like the vendor’s home page.
2. User registers by typing in the unique code.
3. Cloud Zoo internally, asks their database to return a license corresponding to that user and that license key if it exists.
4. The other part of the Cloud Zoo returns the appropriate license from step 1 and connects it to that user.
5. User is free to use Rhino after it checks the Cloud Zoo using their user id.

I believe that a much better path (as followed in my own Xray plugin) is:

1. User registers by typing in “FLCT-XP00-0000-0000-0000-0000” (those are zeroes not o’s- sorry about the font)
2. Cloud Zoo asks the Falcata Group’s API server (Add call) to connect a license with that key to that user and return the license and return it if it exists.
3. The Falcata Group API server creates a license, attaches it to the user/entity, and returns it.
4. The user is free to use Rhino after it confirms with the Cloud Zoo that the license is attached to that user.

The key insight enabling this shortcut is that the license returned by the server in step 3 does not need to have the same license key as the license key entered in step 1.

I’ve tested this and it works. But further, per the other requirements of the spec, it is pretty much _required_ to work:

• The vendor’s database is the one responsible for being the record of all licenses, not just the ones in use
• The Cloud Zoo API explicitly allows joining and other operations on licenses to form license clusters. Clusters are a required feature in order to support transactions including product bundles and upgrades. Because a cluster can contain several licenses and the serial numbers and keys must be unique, clearly no particular license within a cluster needs to have a key matching that in the Add request. McNeel could enforce a requirement that one of them needs to, but at present they don’t and I don’t see any functional reason for them to add that requirement: from their point of view if the vendor’s server judges it to be an appropriate Add request then why should they disagree afterwards so long as the license(s) will work in practice?

To summarize, all the vendor needs to do is:

1. Accept the entity (user) id, trial license key and product code in the expected but not required GET call and pass back information about the trial license. GET can return information about the template trial license itself- no need to create a license specific to the user yet.
2. Upon receiving the ADD call, create a new license for the user or turn down the request in a circumstance such as a repeat request for a one time trial.
3. Pass back the new license information and link it to the user in the vendor’s internal database.