based on people screaming that they now cant use the licenses for multiple machines at the same time a little whil back I suspect that this “overuse” is not possibl anymore .
I would like clarification on that basically
What happens when a user signs into a AMI instance and forgets to sign out before they blow the AMI away?
Any proper implementation would time out the license lock no later than 24hrs without an application heartbeat ‘still using this license id’
All these corner cases have long been considered and solved in decades of license management. And most have come up with reasonable implementations, that make varying tradeoffs based on needs.
I should just be a cloud floating server with the option to borrow a license for X days for offline use like foundry … thats how everyone assumed it worked , cloud license server …
There are a few tradeoffs, and the offline use is a corner case that needs to be considered in production critical apps. Separate from the ‘air gapped’ use case, which is totally separate.
There’s a trade-off of how long would you allow an app to continue using a license token without re-validating with the central license server - to handle Internet outages of any kind. If you make the window too short, you risk kicking someone on a deadline out unnecessarily. If you make the window too long, you allow for abuse (people pulling the cable on purpose, running just up to the time limit).
There will always people who cheat on everything in life, and it’s fair to put reasonable protections against that into the system. But you also need to understand your customer’s use cases. Playing a game is not the same as being a broadcast deadline or a client in the room.
It would also be fair to make this safety trade-off part of the price/procedure. Maybe there’s a small premium price for longer offline periods, or some other reporting requirement, or server could simply upload logs of when they’ve used a license while being offline and that can be reconciled.
All that assume that there is accurate release of a license once no longer used. One option is to run the app in question as a child process of the license daemon (local component). So if the app dies, the license server will know, even if the app crashed rather than shutting down and releasing the license.
Or you build the app and some part of the UI process checks in with the local license daemon every 15min and says, ‘still here and still using’. If the license daemon says ‘fine’, it keeps going. If the license daemon has been reset (a-la Adobe), the app gets an error code, offers you to save the project, but requires you to quit immediately without further use.
Either way you should not allow a use case where the same license token can be used to start an app on another system without being released on the last system the token was actively used. There’s no reasonable reason or use to allow that. Yes, you can run into the case where a user does actually want to switch systems. This either requires the license token to be revoked once the app exits or dies, and records this with the central license server, with a backup procedure in your cloud account management to force that (a-la Adobe). Or it requires the user to actively revoke the license on the previous system (a-la BorisFX, also with an emergency release process which you can use once per month).
If you want to allow users to use the app on two systems simultaneously (as Adobe does), then simply manage two license tokens that can be assigned and tracked on respective systems. No need to create ambiguity that creates more problems than it solves.
And no app should ever start without having checked the license being valid under all contractual terms. Whatever you have to build in as valid safety mechanisms given use production deadline use cases, etc.
And addressing @finnjaeger concern. The validation of the license token can be separate from login credentials. Even after releasing the token back to the central license server, you can keep the cookies that remember your login. So if you start the app again, you don’t have to revalidate your credentials, you’re only requesting the license token back from the central server.
Which goes back to the current Flame menu ‘Quit and logout’ is not the right choice. They should be separate choices of ‘release license’ and ‘log out of credentials’.
Just a few of the considerations. Again, all been done before.
The only bad solution is if your software leads to lots of false positives on abuse and you send threatening letters that turn out to be bad PR.
This is where the distinction between a ‘software architect’ and a ‘software developer’ comes into play. One solves problems. The other one considers the long-term requirements and use cases while solving problems. Of course product managers and UX specialists, and security engineers also play a role. It’s a team effort that advances the business needs of both the company and the users in a well considered and respectful balance.
The root of these problems with Flame may be the fact that these are separate teams at ADSK, and Flame is buried deep in the ‘Other’ or ‘write-in’ category of apps. Plus it runs also on Linux, which is less common in their portfolio. It creates a ‘who is on first’ situation with us stuck in-between.
1 Like
@finnjaeger
It used to be possible to check out a license using the manage my license function from the pop up
That may still function
Try it
@Adam Flame-Feedback is your one-stop-shot to log feature request. It is FFF (free, fun and fantastic 
When you leave Flame from Desktop or Cloud, you can start an new instance of Flame and authenticate and the license will be available. if you have an instance of Flame running while you start a another Flame then the user interface will want you that you do not have a license available but you could pause the other instance of the license if you want. So, I do not think we need to implement a log out at Flame exit as you asked for but please play with the licensing behaviors and let us know. I used Flame on multiple environments and never got issue because I did not log ot before starting a new instance of Flame.
4 Likes
Stephane,
I just tested this, and I did get the error you described (Mac + Linux).
I do remember that not being the case always though and accidentally running it both on the Mac & Linux simultaneously without error.
I wonder if the difference is that as of Flame 2025, Linux now also uses the browser based login, vs. the older popup based authentication. Maybe there was a transition period as the licensing code was evolving where the mutual exclusivity was not as bullet proof?
Thanks Jan for validating the workflow.
There were many licensing back-end improvements done over the last six months so what you see if the result of these changes. This is why I feel Adam’s request might not be required.
2 Likes
If that is the case, that would be good. Maybe the concerns we have and the incidents that triggered them, are in fact addressed already.
Only one way to find out…
i would try it but if “just trying stuff out” can result in a angry letter from compliance thats no good, and thats what I am scared of.
So basically now I CANT possibly be accidental non-compliant anymore as I cant overuse my license, is that correct?
thats the most important thing to me, i dont want to get a huge bill in a few months becuase someone forgott to close flame when going home or whatever…
If this is working now I will actually start doing named users proper… and so people can self service use the license wherever they are which is sort of the idea I guess
1 Like
Well, in that single test I did (started Flame on Mac Studio, then opened VNC connection to my Linux workstation and started Flame there as well - got error message) it seems to prevent you from doing anything wrong.
But this testing is a spot check, not full coverage overall scenarios, all combinations of licenses and systems. Quite possible that there are still corner cases.
That being said - if you do get a letter (less likely it seems), you can always refer to this thread, and say, we were very diligent, we asked questions, we were assured it’s not possible. So if it still happens, that’s not our problem, that’s ADSK’s problem.
And I think this is only applies to 2025 and onwards. That’s when Linux switched to newer licensing code. And it was probably when they were running hybrid codes, that things didn’t always connect.
Though you guys are mostly Mac, so it shouldn’t be as much of an issue there.
When we got in Big Time Trouble the Autodesk Compliance Officer showed me a screenshot that listed each license, which physical machine it was assigned to, and if it was active, how long it had been active, or signed out. “Can I see this screen in Autodesk Admin? So helpful!” “No sir, you cannot.”
It was various things like my old MacPro I never logged out before transferring to my MacStudio. Or if someone came into the office and worked on an office machine, but then went home and used the same license work from home. That was a big compliance issue for him. He assured me they were going to have a fix ala Adobe.
How long ago was that?
This last December
So more recent… and on Mac.
The old Mac Pro I could see if that had some older license manager that behaved differently than current versions. Unmanaged transitions in process.
That being said, the log should definitely not only include ‘assignment of license’ but also some sort of regular heart beat, at least every 24hrs to indicate that license is ‘assigned and in use’.
Also the log should include which license manager version is in use, so if the process changed, some outdated/older behaviors can be isolated.
Otherwise this log is utterly useless and in fact dangerous as in your experience.
Lets hope that as @Slabrie said, a lot of improvements have been made and that all this got sorted out. But I totally get it, that it’s hard to trust if we don’t know the specifics, and they’re being opaque about it. The powers of big brother…
1 Like
Who can I contact to get clarification on that? apparently - from a quick test it still lets me launch flame 2x for a single user without a warning or anything , i just transitioned everyone to personal licenses how they where intended but this scares me
Maybe file a support case with the licensing team.
If this is not supposed to happen, it’s a bug. Their job to chase it down, plus then you have a paper trail.
I still have to down-grade to Flame 2025 Licensing sub-system with each new install, as all subsequent versions make Flame un-licensable, un-runnable. Even did a 1+ hour Zoom with that team. Nothing has come of it. At some point I’m sure Flame with update their minimum version requirements and then I’ll be fucked.
yea ill do that