[Info-vax] Eisner's PAKs, was: Re: Can't get hobbyist licenses from Openvmshobbyist

[Stephen Hoffman]

On 2015-01-20 15:49:57 +0000, John Reagan said:

> On Tuesday, January 20, 2015 at 9:41:59 AM UTC-5, David Froble wrote:
> 
>> 
>> I'm going to suggest that the entire PAK system with VMS be junked.  
>> Now before anyone has a hissy fit, consider.
>> 
>> Any legitimate commercial user of VMS is going to "follow the rules". 
>> That's just the way it is, and if they are not, well, what has been 
>> lost?
>> 
> 
> Unfortunately, that isn't the truth.  We had several legitimate 
> commercial customers who wanted some license management facility to 
> track all their licenses.  They were unsure of what they had (and 
> perhaps HP was unsure as well?) and an architected solution to 
> manipulate licenses was invented.  The additional aspects of version 
> dates, release notes, etc. was all to help customers stay 'legal'.  The 
> added 'benefit' of using LMF as a way to prevent piracy was a secondary 
> goal.  Later on, we realized that LMF also allowed new ways to 
> license/sell products with things like per-user licensing, per-node 
> licensing, icap, etc.

Though in more recent times and given that LMF well predates the web, 
you would expect to enter your vendor login credentials and a system 
serial number into a vendor's web server, and view a listing of the 
associated entitlements there, with download and email access to that 
data available[1].   This would address the central requirement that 
John mentions, too.

If a site wanted or needed a local copy of this same licensing and 
support data hosted locally on the server or on some local "license" 
server, then ask for the vendor credentials at VMS installation or 
upgrade, and download an encrypted and digitally-signed copy of the 
data from the vendor's servers into the local server's offline cache.   
If this was to reflect other recent norms for this sort of software 
license management and tracking, then there'd also be a periodic 
poll[2] for licenses and patches and related data, and a transfer of 
that data into the local cache.

I'd probably also generate a public-private key-pair for the server 
during the VMS install or upgrade, and use that as part of the 
encryption and authentication associated with the entitlements data 
access and any associated data transfers, too.  Maybe also optionally 
with a vendor-signed CSR involved here.   I'd probably also look at 
migrating LMF PAKs to digitally signed certificates, where that's 
appropriate or required.  Loading a blob of license data is likely a 
whole lot saner than the rather more fussy PAK registration process, 
where you really need a local license check.   But I digress.

For systems that must always be offline and with no network access and 
that can never directly poll the vendor's server for licenses or 
support entitlements or current patch data, then the folks involved can 
link to the vendor's server from another client, and look and transfer 
the cryptographically-signed licensing data and patches from there over 
onto the "marooned" server, using whatever local access and file 
transfer is expected and available.   Always-offline access would be 
somewhat more problematic for the hobbyist or loan-of-products or or 
pay-per-use[3] licensing schemes, though — this if VMS wasn't simply 
free to use, with support requiring a contract.

We've all seen reports of erroneous licenses and confused or lost 
support contract information posted here over the years, too.  Having 
authorized remote access into the canonical data stored at VSI would 
reduce the occurrences of this same "fun", too.

The expectations and norms and technologies from back when LMF was 
designed and created in the late 1980s as part of the run-up to VAX/VMS 
V5.0 are not the same as those of today, after all.  The web didn't 
exist back then, after all.

#######
[1] Pedant note:  This with opt-in access.  Opt-in downloads.  Opt-in 
notifications.  Opt-in patch installs.  No network required.  Etc.
[2] Not going to expect there to be push notifications here, but that'd 
be typical where time-critical notifications and updates are to be 
expected.
[3] What HP has called iCap, the capacity-on-demand licensing, or with 
the hobbyist or similar time-locked licenses.




-- 
Pure Personal Opinion | HoffmanLabs LLC