Non-compliance
To remain compliant, you do not only need to monitor the deployment and/or usage of the program, but you also need to control versions, editions and features of the supporting programs. Quite often we see that product-oriented teams (e.g. database administrators) deploy and manage DB2 databases without being aware of the license restrictions. Traditionally, the primary task for database administrators is to maintain system availability, which is usually achieved by standardizing deployments and configurations. While this is a good technical practice, it might lead to a non-compliance situation.
Using an unsupported version of a component may lead to a non-compliance situation for all the deployments of a specific program in your infrastructure. The height of the risk depends on various factors. For example: at a minimum you would risk purchasing a single license for the unsupported version of the component and at a maximum you would risk reinstating S&S for every deployment of the programs in your environment.
Let’s assume you have two Spectrum protect 7.1 environments, one in Datacenter A and another one in Datacenter B.
- You own a total of 10.000 PVU licenses for Spectrum Protect
- You have no active Support & Subscription (S&S)
- You can continue to use the program within the terms and conditions defined at the time of the purchase.
- At time of the purchase, Spectrum Protect 7.1 included IBM DB2 Enterprise Server Edition 10.5 as it’s supporting program.
- Since you have no active S&S, upgrading the program, primary and supporting programs, is not permitted.
If one would upgrade the database in Datacenter B to a higher version (e.g. DB2 Enterprise Server Edition 11.1), you could be at risk for all 10.000 PVUs. When under audit, you could be forced to re-instate S&S for all 10.000 PVU’s leading to a huge fine.