In the lives of companies, product dependency relations are present in their daily use of software assets. It can have a significant impact on the investment cost of a particular solution and the legality of using the software, so it is something to consider. (This article was originally published on Digitrendi.hu.)
As one reads the title, one may think: Is another addiction problem coming up? While it is not necessary to immediately think of a new addiction that we do not yet know, it may indeed be similar to the behavioral pattern of an addictive state. All this in such a way, that bypassing the problem and not treating the situation carefully can put the person concerned and their environment at a disadvantageous position.
Product dependency can be technical or legal
Microsoft product dependency relations are there in the life of organizations on a day-to-day basis. For the average user, this may not even seem to be important, while using the various software applications provided to him/her on a given device. On the other hand, if we look more closely at this, from a technical point of view, and also from a licensing point of view, it becomes a visible phenomenon that we must address.
Let’s get started by mapping out relatively obvious software product relations. Technically, you need a proper operating system, which is a prerequisite for the software to run, in order to run desktop applications. In a very common and simple example, using a Microsoft Office Suit without a Windows (or Mac OS) operating system is unimaginable.
There may also be a product dependency case, that does not technically link two different software products, but there is a license agreement for the software, which obliges us to use the second product (a “bundled product”).
For example, Microsoft’s Volume Upgrade License in Volume License Agreements (e.g. Windows 10 Pro), which require other software (such as Windows 7 Professional) as an upgrade basis. However, it is technically not necessary to install the latter. Of course, all software products involved in the relationship must be licensed, whether technically or legally related to each other.
It is fortunate if they meet in-house. In this context, we need to consider product relationships that typically represent software products that are inoperable (based on SQL technology) without a database manager or different types of access licenses (CALs) that may be built upon each other.
What should be tied together?
In light of the above, the question becomes clear to me: is the software product I want to use, legally or technically linked to other licenses, products that we also need to own, or can be used on its own?
Because of these so-called product dependencies can significantly affect the total investment cost of a particular solution and the legality of software usage, it is very important to consider them.
That might be okay, but where is the information on this, which tells you what to bind? Previously, until July 1, 2015, this information was available in a contractual document called Product Use Right in the Microsoft Volume Licensing Program, which was later replaced by Product Terms.
The latter, for unknown reasons, omitted this information. There is also a Volume Licensing Brief on the “Microsoft software dependency guide” which can be downloaded from the vendor?s site, but this material is not up to date as of December 2015.
Rapid clarity is almost literally gold, which is why the table below summarizes products and dependencies that are less obvious. It contains all currently available software products that require further non-integrated software in addition to the operating system. The left column shows the product, and the right column shows the required dependency product.
