cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Question - What are the limitations when working with non Flexera "Licensed" Applications from the ARL List

Hi Everyone, I am trying to educate myself a little more on the License management side of the tool, since my role primarily consists of managing the environment in terms of Beacons, FNMS Console, Agents etc. , all of the architecture type of things.

My question relates to those "other" applications aside from the following list, which as we know require a Flexera License to perform a lot of the day to day functions that the licensing teams do.

Adobe, IBM, Microsoft, Oracle, VMware, Symantec and SAP

For example, lets take an application like Putty0.70 which does appear on the ARL list and does indicate the number of "installed" devices via the Devices tab under the Application tab. In my case, there are no Licenses tied to it at this point, but my suspicion is that one could associate a License by creating a new one by following the process (which I have no experience on)

So, if my assumption is correct that one could create a new license for this application what limits would one encounter in terms of what one could do or see with this scenario. I am trying to understand if Flexera allows the client to perform similar functions with these, what I will refer to as "other" applications that exist in the ARL list in a similar fashion as the Adobe, IBM, Microsoft, Oracle, VMware, Symantec and SAP ones.

To Summarize then ... what are the differences when working with the applications under the core list of  Adobe, IBM, Microsoft, Oracle, VMware, Symantec and SAP which require Flexera licenses and these "other" applications that show up under the ARL list  which "appear" when possibly configured in a similar manner as the others , perhaps offer the same level detail, analysis capabilities etc.

Thanks as Always

Bruce

 

 

(1) Solution

Hi Bruce,

Putting aside any of those tier one vendors for a moment & reducing the tasks to their simplest in FNMS - you can still track license compliance for any applications by:

1. Ensuring the application is recognised by FNMS which could require:
- no extra effort - the app is already in the ARL published by Flexera so you see installs already
- you can use FNMS add to the ARL to ensure the app is recognised (by augmenting an existing app with new evidence, or creating a new app from scratch).

2. Define a license with appropriate metrics/use rights that cover that app
- on a license you can manually tweak individual usage rights to adhere to the license agreement

So, depending on the complexity of the product/metrics you may need to do considerable research to make sure you define the license so that the consumption is accurate/reflecting the license terms.

What's special about the vendor packs you mention is that they provide:
* in some cases they add new license types that are specific to that vendor (eg Oracle Processor)
* they provide a wealth of research on the SKU's and usage rights for licenses that help automate the definition of the license.
* updates to the libraries over time will match changes vendors make to their license terms and FNMS will flag these changes for your review.

So, leveraging from the vendor PURL's adds (significant) value with automation of the license creation & maintenance of the licenses but you still always have the ability to create licenses and applications from scratch if needed - even if they aren't from one of the top vendors.

-Murray

View solution in original post

(2) Replies

Hi Bruce,

Putting aside any of those tier one vendors for a moment & reducing the tasks to their simplest in FNMS - you can still track license compliance for any applications by:

1. Ensuring the application is recognised by FNMS which could require:
- no extra effort - the app is already in the ARL published by Flexera so you see installs already
- you can use FNMS add to the ARL to ensure the app is recognised (by augmenting an existing app with new evidence, or creating a new app from scratch).

2. Define a license with appropriate metrics/use rights that cover that app
- on a license you can manually tweak individual usage rights to adhere to the license agreement

So, depending on the complexity of the product/metrics you may need to do considerable research to make sure you define the license so that the consumption is accurate/reflecting the license terms.

What's special about the vendor packs you mention is that they provide:
* in some cases they add new license types that are specific to that vendor (eg Oracle Processor)
* they provide a wealth of research on the SKU's and usage rights for licenses that help automate the definition of the license.
* updates to the libraries over time will match changes vendors make to their license terms and FNMS will flag these changes for your review.

So, leveraging from the vendor PURL's adds (significant) value with automation of the license creation & maintenance of the licenses but you still always have the ability to create licenses and applications from scratch if needed - even if they aren't from one of the top vendors.

-Murray

Thanks Murray ...  that explains things perfectly .. I am sure your reply will help others as well.

 

Thx Again