Folks, As LG has noted, the “flaw” was not an error or bug in the implementation about how floating licenses work. But, it was more of an unintended cross consequence where BMC made the decision that we didn’t want to trigger the side effect of grabbing a bunch of application floating tokens just because of a query to the application to get a list of items for a console – especially when there may often not have been any items from that application to show in the first place for the user. So, in order to allow for the more effective interaction of the applications through a console without the side effect that was occurring, we considered it a “flaw in the intention” of the overall goal of licensing and so we reacted to the customer input and made the console no longer trigger obtaining licenses.
As for how the licenses work, as folks have noted, it is a business decision about the behavior of licensing. If you look at most products, you either need a license just to use the product – there is no concept of a no license “read” user that BMC Remedy has. And, then many others have no concept of a “floating” license and all users are either “fixed” or “unlicensed” (with whatever unlicensed means). Finally, for those that do have floating licenses, you will not find products that let you use the product, then suddenly change your license to another type, and then release it back to let someone else use it all within minutes (I would be interested to see any product on the market that folks think have a floating license model that does this). So, really, the licensing is not as odd or unusual as folks think. Most of the time, it is the flexibility and variety of access with lots of unlicensed access allowed that causes the questions. Again, BMC has always been open to discussions about point areas where the spirit of the licensing is not being obeyed. This console example is a poster child for that. Although it was performing correctly and according to the rules, a decision was made to allow an exception as it was not the intention or goal to grab a bunch of application licenses just because of a console. As for can others do this? The answer is no. We allow violations of licensing models when there is a determination that the intention/goal of the model is not being met – another example is approvals where you do not need to have an application (or even an AR System license) to approve things that are assigned to you when you are working with approvals and BMC product. So, you don’t have to suddenly have everyone in the org who can approve having to have a license just to do approvals – even though they are writing to the system by doing an approval. For these cases, we take advantage of some exception logic that is built into the system to allow for these types of exceptions that is available only to BMC (since it is allowing violation of the licensing model, BMC can violate our own model but others cannot). Doug Mueller From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of LJ LongWing Sent: Monday, November 02, 2015 10:21 AM To: [email protected] Subject: Re: Serious flaw in BMC Remedy Licensing ** John, As you know, I'm not a BMC employee...so all of my understanding of things comes from that perspective :) As I understand it the overview console utilizes a plugin to pull the information...but, being I don't run ITSM where I work...I can't confirm this....but even with that said...even if the plugin was pulling the information...it's the SERVER that determines what type of allocation is made...so....if I were to guess, and this is 100% a guess...I would guess that something was re-written in the server that says something along the lines of 'if the query is coming in from 'this client' and the user is floating...don't allocate a write token'....and I would assume, that the 'this client' portion of that is specified using the client type function when that plugin connects.... So...trying to replicate it would be difficult....but in theory not impossible.... On Mon, Nov 2, 2015 at 11:02 AM, John Sundberg <[email protected]<mailto:[email protected]>> wrote: ** Just wondering — say you wrote your own console … how can you not “tap” the license unless you need it? Is this reserved only for the BMC provided consoles? -John On Mon, Nov 2, 2015 at 11:34 AM, LJ LongWing <[email protected]<mailto:[email protected]>> wrote: ** Ryan, As I understand it, this isn't a 'flaw' that needs to be 'backported'...but instead, a change in direction from their long standing stated policies. As I understand it, and somewhat agree with...the reason that a Float Write is accompanied by doing a query, instead of at attempt to write, is quite simple. If a user is doing a query for some data, they are more than likely trying to find something that they need to modify, and as such, will need a write license in the near future. Along those lines, if they didn't request a write till they were actually trying to write, it might be frustrating to the user experience. Now...with that said...when the policy was put in place (as I understand it...almost from the beginning...certainly not recent)...there was no concept of an 'overview console' that allowed people to query every form in the system for relevant information and consolidating it into a console/dashboard type of functionality....when this was done, and applied the old methodology of 'a query likely means a coming modify', then as you know, this then causes massive quantities of float licenses to be unnecessarily consumed. When it was pointed out to BMC that this was occurring, and how 'unfair' it was, BMC apparently decided to change it so that the overview console was allowed to do its queries without incurring a penalty on the cost of the system by allocating licenses to everyone in the console. So....while it was a design choice with unintended financial consequences...it was not a flaw, or a bug....and in order to avoid this feature, you need to be on the version of the tool that changes the direction and avoids this one scenario.... I'm not a major fan of the 'it's a feature, not a bug' discussion...but in this case, I agree with BMC's logic that it wasn't a bug....I don't fundamentally agree with the idea of allocating float write on query...but it's not my tool, and I don't make the rules :) On Mon, Nov 2, 2015 at 9:15 AM, Ryan Nicosia <[email protected]<mailto:[email protected]>> wrote: We are on 7.6.04 with Mid Tier 8.1. So, based on Doug and Misi's response it sounds like it is fixed in newer releases (we are moving to 9.x this coming spring). That begs a follow up question or 2. If this is indeed a flaw with 7.6.04, one could argue we have been overpaying for licenses since 2012. Unfortunately, since the user.log logs these interactions and we are using the RRR license tool to determine how many licenses we need, it appears there is no easy way to figure out how many actual write licenses we need and should assign. 1. Does anybody have any recommendations on how to address with BMC when with our annual license renewals? 2. We have queried SQL with the 1900+ write license consumers and determined that 500 of them have never updated a ticket or entered a work log entry in a ticket. Would setting them to Incident "viewer" be a good work around? 3. Is what has been fixed in 8.x relative to the "flaw" something we can apply to our 7.6.04 environment? Thanks AR listers!! Ryan _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org<http://www.arslist.org> "Where the Answers Are, and have been for 20 years" _ARSlist: "Where the Answers Are" and have been for 20 years_ -- John Sundberg Kinetic Data, Inc. "Your business. Your process." 651-556-0930<tel:651-556-0930> I [email protected]<mailto:[email protected]> www.kineticdata.com<http://www.kineticdata.com/> I community.kineticdata.com<http://community.kineticdata.com/> _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
