Hello Carl,

Thanks for the clarification. I have always heard the term "existing customers" 
so originally I thought we were fine, but this is the first time I have seen 
the term "existing systems". However, it seems what I said before is mostly 
correct, eventually all customers will be forced to capacity based licensing as 
they life cycle hardware (even IBM customers). In addition it seems there is a 
diminishing number of OEMs that can sell SS v5, which is what happened in our 
case when we wanted to go from v4 to v5 with existing hardware (in our case 
DDN). So I strongly encourage organizations to be thinking of these issues in 
their long term planning.

Thanks and kind regards,

Dean

-----Original Message-----
From: gpfsug-discuss-boun...@spectrumscale.org 
<gpfsug-discuss-boun...@spectrumscale.org> On Behalf Of Carl Zetie - 
ca...@us.ibm.com
Sent: Thursday, April 16, 2020 10:25 PM
To: gpfsug-discuss@spectrumscale.org
Subject: Re: [gpfsug-discuss] Spectrum Scale licensing - important correction

> From my understanding existing customers from DDN, Lenovo, etc. that 
>have v4 with socket based licenses are not entitled v5 licenses socket 
>licenses. Is that a correct understanding?

It is not, and I apologize in advance for the length of this explanation. I 
want to be precise and as transparent as possible while respecting the 
confidentiality of our OEM partners and the contracts we have with them, and 
there is a lot of misinformation out there.

The short version is that the same rules apply to DDN, Lenovo, and other OEM 
systems that apply to IBM ESS. You can update your system in place and keep 
your existing metric, as long as your vendor can supply you with V5 for that 
hardware. The update from V4 to V5 is not relevant.


The long version:

We apply the same standard to our OEM's systems as to our own ESS: they can 
upgrade their existing customers on their existing OEM systems to V5 and stay 
on Sockets, *provided* that the OEM has entered into an OEM license for Scale 
V5 and can supply it, and *provided* that the hardware is still supported by 
the software stack. But new customers and new OEM systems are all licensed by 
Capacity. This also applies to IBM's own ESS: you can keep upgrading your old 
(if hardware is supported) gen 1 ESS on Sockets, but if you replace it with a 
new ESS, that will come with capacity licenses. (Lenovo may want to chime in 
about their own GSS customers here, who have Socket licenses, and DSS-G 
customers, who have Capacity licenses). Existing systems that originally 
shipped with Socket licenses are "grandfathered in". 

And of course, if you move from a Lenovo system to an IBM system, or from an 
IBM system to a Lenovo system, or any other change of suppliers, that new 
system will come with capacity licenses, simply because it's a new system. If 
you're replacing an old system running with V4 with a new one running V5 it 
might look like you are forced to switch to update, but that's not the case: if 
you replace an old "grandfathered in" system that you had already updated to V5 
on Sockets, your new system would *still* come with Capacity licenses - again, 
because it's a new system.

Now where much of the confusion occurs is this: What if your supplier does not 
provide an update to V5 at all, *neither as Capacity nor Socket licenses*? Then 
you have no choice: to get to V5, you have to move to a new supplier, and 
consequently you have to move to Capacity licensing. But once again, it's not 
that moving from V4 to V5 requires a change of metric; it's moving to a new 
system from a new supplier. 

I hope that helps to make things clearer.



Carl Zetie
Program Director
Offering Management
Spectrum Scale
----
(919) 473 3318 ][ Research Triangle Park ca...@us.ibm.com


_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss
_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss

Reply via email to