Name: Software Monetization Office Hours: Offline Borrowing with Built‑In License Count Compliance
Uploaded: 2026-03-24T16:32:12.227Z
Duration: 28 min 25 s
Description: Software Monetization Office Hours: Offline Borrowing with Built‑In License Count Compliance

Transcript for "Software Monetization Office Hours: Offline Borrowing with Built‑In License Count Compliance": Yeah. Thank you. Hi, everyone. So today, we will be talking about online counted borrowing in FlexNet Publisher, which is technically also called as transferable counted model. And in today's session, we would be covering the problem statement of why we are solving this, what exactly is the functionality, how it works, well and that will be followed by a demo and the q and a as well. So in today's world, the offline counted borrowing enables these software vendors and device manufacturers to extend their on prem license software to air gapped environment, and they can still ensure that the licenses are counted. They are efficiently used, and they are predictable predictable of what and how the licenses are being used in their end customer's environment. So when we talk about these air gap environment, today's the biggest and main top ask remains the the top ask is to have something which can be borrowed, which can be used on an offline environment, but still counted. So that is what we are exactly doing here. So the three main things that the transferable counted model gives us is efficient counted usage. By transferring these counts, you will be defining us a a period of transfer, and the producers will have full control over what is what is transferred, how many licenses are transferred, how many licenses are expiring, and you would get all the details while remaining offline. This fits very well in the real world workflows where where it supports the field test and the remote engineering workflows by allowing these licenses to be offline without any dependency on the server connectivity, continuous connectivity of the servers. And then the producers will have predictable license control on the transfer licenses with the expiry, with the early return, with the consumptions that's been made on the licenses, producers can predict how their licenses are used or or they can even avoid the misuse of the licenses. So these are the three main things that we are trying to solve here. What why exactly and what exactly is discounted offline borrowing? So as a producer, I would want an ability to check out the licenses, and I want to remain accounted in an offline environment so that the end customers so that the producer's end customer can use these licenses in the remote machine and just go offline. So, however, me as a producer, I still want to limit the usage. I want to control the use of the licenses, and I want to control the over usage as well. In case of portal, which we have traditionally, we usually hear a lot of licenses misuse cases or the the count becomes uncounted, and then you the producers will not have any control over those licenses. Whereas in TCM, you will have full control over the licenses that that's being transferred. So what are the things that's that's been introduced when we say counted offline borrowing or the transferable counted model, and how exactly are we trying to resolve this? So first, we are allowing producers to set their features to they they can, like, sell their features at new pricing points where they can exclusively create a feature, and then they can say, okay. This is a feature which I want to transfer, and this cannot be used for the borrow or any other purpose. This is solely for transfer purpose. The vendor daemon allows the early return of the transfer license. This is kind of an end customer end customer benefit where if the pro if the transferred license is, like, they're not using it anymore or they would not want to use it for the full transfer period. And if the producer has enabled the early transfer, they can just go ahead and return it. Like, in case of billing or some other compliance stuffs, it may save save them some some cost benefits would be there. And sometimes what happens when you want to do the billing or the other things, the end customer needs to understand what are the what are the licenses that they have transfer that that they've used that are being transferred, how many of the licenses have been used, and we have given an API which will give you all the information of the feature that's being transferred. So in the below part, on the how part, if you see that that the second line is the transfer keyword that we have introduced, which can be set at a license file level. So on the increment lines where you want where you're setting the attributes for a certain feature that you want to sell, you can highlight you can give a a keyword which is called as transfer, which makes that certain feature only a transferable feature. And when we talk about this transfer model, there will be another trial server which needs to be started at a remote location. And when starting that server, you will have to give a a keyword which is called as self transfer, and then you need to start the server. That means that that is a remote server or a child server which is getting started, and it does all the counting. It keeps track of all the all the checks, and it keeps track of the licenses that are being transferred and which are being used at an offline environment. So the the fourth one is the link transfer API. So that that's the API that's being used to transfer the licenses. Then the l l m a transfer stat. So that is the API that we have developed for an licensed application where it can set these APIs, and it can do all the calculations and gives the information on what transfer, what is the usage of that feature, what's the time that's been remaining for that feature to get expired. And in case that the feed the feature is not used at all, then you can just, like, go ahead and early return it. And then the last option that you see there, LS transfer return early, is a vendor variable that be that will be set by an producer, allowing the end customer to return the license early. That is about what are the things that's being done technically and how are these these being how are these things being achieved technically as well. So here, when we talk about transfer, you might be wondering, this is very similar to an existing functionality in FNP, which is called as borrow. So what is this transfer or counted borrow? Why exactly are we saying that we are solving the problem that borrow had and, like, it's it's, it's going, one level up ahead to with transfer where we are resolving many of the borrow problems. The first one is when you borrow a license, you will have to do it, like, on a single count features only. You cannot borrow multiple counts at a time, whereas transfer is designed to transfer multiple counts, and it allows multiple counts to be transferred at a remote location, and it it can be used seamlessly. And these borrowed licenses, they are not counted. Once it's borrowed, it's like giving the license to an end customer, and you don't know what's happening to that license. And that single license can be used on on that machine to start up on a various applications. Like, you it will not be it will not be stopped at one license. It acts as an uncounted license at an end customer machine. Whereas in transfer, it can be, like, tracked and it can be enforced locally, and you will be bound to use whatsoever number of licenses that you have transferred. You will you are bound to use only that many counts of the license. So this is one of the major problem that we have resolved with the transfer where the accounts are being tracked and enforced and and, like, monitored by the producers. When the borrowed licenses the impact on the central license pool is the borrowed license may just remain tied up, and you would not know what's happening. But the counts and the transferred licenses, they explicitly are explicitly reduced from the parent server, the parent pool of the licenses for the transfer duration. And if the transfer duration is over, it it will be automatically pulled back to the central pool or the parent pool that we call it as, and the end customer will no longer be entitled with that license. In case of expiry and recovery, the manual intervention is required in case of borrower, whereas in transfer, the automatic return and automatic early return is also possible using the APIs that we have developed. So the the, control of the producer that he has on a borrowed license is very limited. Once the license is taken at an end customer, the end customer would not be able to do anything about that license. There is very limited control on the borrowed license, and there is high risk of misuse of that of that certain license because it just becomes uncounted, and it may be used in many of the applications. Whereas in transferred in transferred license, the producer will have full control with the defined transfer policies. He can, like, set the transfer policy. What's the duration? Should it be early return? Should it not be early return? What's the duration that the end customer is entitled to use? Which are the features that he's entitled to use? He can set all the transfer policies for the transferred licenses, and, yeah, the producers will have full control over those licenses. Because of these limitations that the borrower has, we see it as a poor fit for the field, especially on non secure secure labs or the secure air gap environments where they need to be used, whereas transfer, triple counted models are built for field engineers field engineering and secure sites, and especially for the remote work remote work use cases where the producer would want to run the licenses on on fully secured environments. The trade off between the access and the enforcement is it's it's done because because of the control because of the, like, limited control that the producers will have on these borrowed licenses. Whereas because of the full control that the producer have on the transferred licenses, the compromise between flexibility and license protection is not done in case of transfer. The producer will have the full flexibility to to give the licenses, to take back the licenses, and as well as he can maintain the license protection as well at with with the control that the producer will have on this. So these are the few differences between the borrow and the transferable counted model. Let's just quickly see how it works and and, like, get back if you have any questions. Yeah. So before we we jump into our demo video, it does look like we we had two questions come in, Pooja. Mhmm. Maybe we'll does it make sense to address those first before we jump into the demo, or, I. could start the demo? Yeah. That, that TCM model is only for the license file based for now. We have not we have not done it for trusted storage based at the moment. Yeah. It's only certificate for now. The second question is, are all of the original fields visual etcetera preserved with the config of the transfer license? Yeah. It can be preserved in the transfer licenses. You can, like, you can transfer the features with the original fields. If I'm not wrong yeah. I think it can be done, but I will get back to you, Biden, on that. I'll just check and get back on that. K. Alright. And I'll go ahead and start our demo video. So here we have two machines for our demo. The first one is the parent machine from where the licenses are getting served and the second one. This one is the client machine on which the licenses will be transferred. The parent machine has got this license file. It has got four features with transfer support. We provide this transfer keyword for transfer support and two features with borrow enabled. So this is the license file and there is a vendor variable called LS transfer return early. We enable this to allow early returns in case we want to return any transferred feature before the expiration time, then we can use this LS transfer return early and return the transfer return the transferred licenses. So let me start the server. So the server is starting the features from the license file. LMSat is also showing zero in use for all the features. Now this is the client machine. First I will set the LM path and then I will set the transfer period. I will set it as twenty third march twenty twenty six at 3PM. Once the transfer period is set I will run lctransferlit api and transfer a feature T1. So this is checked out transfer is successful I will transfer another feature that is T2. So we can see the out messages on the server and LMStant will show these two licenses in linger. So these are in linger T1 one license is in linger T2 one license is in linger on the server side and on the client machine where we have transferred the licenses. I will run the transfer status. Here we can see there are two licenses T1 and T2 transferred and this is the expiration date and each of them have consumed one count. Now since we have transferred these licenses, I will simply stop this server to make the make the machine offline. So the parent server from where the licenses were transferred is not reachable. Now we can assume that now the now the client machine is offline. So now these licenses are on transfer cache. I have a dummy license file here. This has got one feature. I will start the server with this feature with this license file. And there is a flag which we need to fit when we are starting the server that is serve transferred. The serve transferred flag will allow server to read the licenses from transfer cache. So like we saw earlier, the license file had only feature F1. Now the server is starting the feature from the license file as well as from as well as the features from the transfer cache. So these are the features and if you run LMSTACK. It will show you, T1 and T2 which were the transferred licenses and the count of those licenses. And if if we want to use it on this machine, we can simply run lccheckout. So this will be checked out. So one license which was transferred is now consumed on this machine so if you try another checkout It says license number already reached, so whatever count you have transferred, only those licenses can be consumed. This is the difference between borrow and transfer on borrow. It behaves as a uncounted licenses. Any number of instances of same feature can be used on a machine, but here it allows us to use only one count. Whatever count was transferred, only those counts can be used. So once after use, we've checked in. Now I will start the server there and try to return the licenses early. So there is one more thing like we have used LM transfer. To check the status. This shows the licenses that are transferred. Now there is an API called LMA transfer stat API, which will also do the same. This also gives the same kind of information what this transfer utility does in case we don't want to use this utility. This API can be directly used customized to get this information. So after this now I have started the parent server now I want to return the license early so I will run LM transfer hyphen return vendor and the feature name. So the licenses gets returned early. Now the license is back to the server and if you see the server log on the child machine since T1 is removed from the cache there is only T2 which is present now in the transfer cache. T1 support for T1 is removed. This is the automatic reread whenever there is change in the transfer cache there will be an automatic reread to update the feature information on the server. So we can also return T2. So now whatever licenses was consumed transferred on the child machine is back to the server and LMstat here shows zero in use. So everything is returned. So instead of early return, if the client machine uses the licenses until the expiration, once after the expiry period is over, automatic check-in happens on the server side and the child machine will lose the license on the from the transfer cache. Yeah. I read the last answer. Yeah. If if the child if the parent server is still not accessible, it will process the request from the child machine, and then, yeah, it will process it back to the parent server once it's back online. So with this demo, the three major takeaways from the transferable counted model is the one is the offline counted usage, which is actually now practical and predictable. The demo showed us that the counted licenses can be transferred ahead of time. They can be used in offline, and they can be tracked locally, enabling the real world workflows without actually relying on the continuous connectivity of the of the main server. The second one is this TCM goes beyond the traditional borrowing that FNP is supporting. So unlike the standard borrowing here, it supports the counted features, and it makes suitable for advanced product configurations that were very that was difficult in in the previous use cases to be supported on an offline case. The third one is the control still remains with the producer even when the usage is offline. So with the defined transfer duration, the expiry, and the return behavior, the TCM will ensure that the license consumption stays predictable, and it will be aligned with the intended usage even outside the network, reducing the risk of misuse of the licenses. So, yeah, the these are the three takeaways from, today's demo. Christine, if we have any q and a, we can take the questions. Yep. And it does look, Byron has another question here. Fantastic. For some message, I for some reason, I can't see the it's it's not scrolling down, no worries. Christine. So Byron's asking, are all transferred licenses assigned to FNP auto or to the user that did the transfer? It will be to the user that did the transfer. And, yes, I I just checked that the original fields will be preserved in case of the transfer licenses also. Yeah. We'll give folks a few more minutes to to type in those questions for us. So, Annette, again, for those who joined maybe a little bit earlier, we do have two upcoming events. Our next SWIM office hours where we'll be going over kind of a technical overview of the new analytics platform in FlexNet operations. That's happening on April 21, same time as today's event. So please go ahead and register for that if you're interested. And then, of course, we have our annual soft summit twenty twenty six event that we'd love to have you guys attend and hear from our industry leaders. Both links are in the pin message in the chat. Cool. Looks like I I gave enough time for more questions. Are you not able to see that, Pooja? If not, I can read it for you. Yeah. So I I could read it, Christine. Okay. So the transfer license will have a a expiry. It it's not like all time use kind of license, So you have to set the expiry period for that transfer license. However, these transfer license are also available for the normal checkouts and check ins if if, the producers has such use case. So in case of, long time usage, you can go for the normal checkout, but you have to be connected in that case of in that case because of the heartbeat that takes place. If it's completely offline, it's either borrow or transferred, and that both of them will have an expiry. K. Let's see here. Let's see if there's so it does look like there is there was another question that maybe we there must be some issue with our our chat today. So the the question that was raised was, what happens when the server is not accessible and the client tries to return the transferred license early? Will it be processed when the server is back online? Yes. Yes, Christine. I I think we answered that. Yeah. Oh, The. so it will be processed once the server is back online. That's. right. Apologies. Alright. Let's give folks maybe another minute or so to to respond here or to ask any any other questions? Alright. Let's see here. Okay. I'm not seeing anything new. And, again, we do apologize if if your question is being submitted and it's not making it into our into our chat feed here. We will, of course, get back to you, you know, reach out to either myself or to Pooja with any questions. See here. Alright. So I'm not seeing any further questions, Pooja. I think we did a you did a great demo and session covering this content. For those of you who, again, had entered late, we are recording this session, and we will share the recording as soon as it's been processed and is available. We thank you all for attending today's session, and hope to see you in our future ones. Alright? Have a great day, y'all. Thanks. Appreciate your time, and thank you, Pooja. One, you.