That’s a shame. But you must have some odd corner case in your setup somewhere they haven’t figured out. I’ve installed 2025.2 on two Rocky systems (8.7 and 8.10) and have no problems. And presumably there are quite a few others running Linux with later versions of 2025. Not discounting your problem, but you’re triggering something that is beyond their imagination.
You have been licensed.
Yup. Which is wierd, because really nothing all that exotic.
This has happend with me and after about 15 mins you’ll get a dialogue box wanting to throw you out.
I actually have my license logged in on 2 different workstations. I am on a Linux system 98% of the time and the Mac system the rest but am yet to be kicked off either, even when I have had both open at the same time (with one obviously being inactive even though open).
As mentioned elsewhere, I feel this thread is enough to cover you as long as you aren’t doing anything untoward.
1 Like
I see, seems inconsistent.
I am not doing anything, i assigned a licence to every actual flame user that we have, its like 100% how autodesk wants this to work (I think).
People are however hopping machines, and the licenses dont follow via AD i guess (we dont have AD).
Potential issue:
So lets say @hildebrandtbernd is logged in on his machine then walks over to the finishing suite because clients are comming in.
He closes flame, logs into the machine in th suite , its all good.
Now lets say - myself - I see all machines are occupied except for bernds flame , and I just want to export something or whatever try a python script , I dont know that bernd is logged in somewhere else I assume he is on lunch or whatever - so I start flame do my thing.
No warnings, no nothing and then we get a letter a few weeks later?
So now If I just take away everyones logins and dont use user based licensing but just do a flame001 flame002 user and login “each machine” i am not running into this issue anymore, but thats not how the user based licensing is supposed to work? I am strongly considering this however.
I will ask them in a ticket for a call with someone from licensing to just explain the terms and our duties here, if we have to log out of flame (and you have to launch flame to log out , right?) everytime we switch machines then we need to know.
and the danger or someone in the heat of the moment forgetting this is insane.
How many licenses does one have to have to be eligible for floating lics?
In fairness, this use case is a built-in conflict between user based licensing on one hand, and a usability issue on the other hand, when user who had to quit Flame or it crashed on them, don’t want to re-enter their password. You can’t have it both ways.
Because when you go back to Bernd’s station, and you relaunch Flame, it will use his cached cookies to reactivate his license without asking for your login.
That is however, because you only did the first half of user based licensing. You are using individual user licenses for Flame, but you are sharing Mac OS users. The correct answer would be that when Bernd leaves his workstation, he should log out of Mac OS. Then when you see his station open, you should login with your Mac OS user. When you do that, and then open Flame, the browser may find cookies from the last time you logged into Flame on that system, and will start Flame with your assigned login license rather than Bernd’s. Because cookies and licenses are stored in the browser cache which is separate for each MacOS user.
Now I get that logging out of Mac OS is an extra burden, because when you login you have to wait for every app and OS tray thingy maggici to load and it’s a few minutes. But it actually is the right thing to do in a multi-user office environment. Your email and many other things will follow you around that way as well.
And with Flame’s new user settings it would allow you to have separate preferences from Bernd, as the Flame user settings are stored per OS user.
If you’re using user based licensing for Flame but sharing OS users you are kind of sitting between the chairs of a single user office and a multi-user office environment. It’s bound to create issues somewhere, not just with Flame.
You can work around it by logging out of Flame and re-entering passwords. Ideally Bernd would have logged out (at the risk of being frustrated to re-login when he returns from the client session without anyone else having used his system), or you upon taking over a station someone else has used, should have logged out. You can hover over the little menu in the bottom right to see who the currently logged in user is. If it’s not you, logout, and then login with your own license.
But that seems more trouble than just logging out of Mac OS. Does Mac OS have the ability to switch users like Windows does? So someone wouldn’t have to log out and log back in, but just switch to another user? Don’t think I’ve seen it, but it may be possible.
All this is with one caveat I have not tested. When you logout of Mac OS the ADSK license server should quit, and then it restarts when you login with your Mac OS user. That is the first defense to not re-using the same license. Barring that, if you login as Finn on Mac OS and launch Flame, the ADSK license server should get your license login from the browser cache and use it properly rather than Bernd’s. Let’s hope the ADSK team got that part right. I think they did, but then who knows.
With all that said, if you continue with your use case as you described it and as I understand, ADSK actually has a leg to stand on when they say you didn’t use the software properly.
If you on the other hand use ‘flame-01’, ‘flame-02’ licenses, each assigned to a system, that’s totally cool and would work. Except that these licenses can never be used on any other system. In the end you would be needing more licenses than you have users, as you have separate systems in the client suite, or you may use one at home. So it’s financially worse than taking the few extra minutes to log out of Mac OS.
Ill talk to licensing support about this next week.
I am happy to spend money on as many licenses as we need concurrently , not looking to cheap out but if they need me to do any other steps or be vigilant MYSELF thats where I have to know what my duties as a admin are.
Like sure I give everyone a license and they activate it on their macbook at home so they can do research on the couch or whatever - but i have 0 controll (there is nothing in the licensing tools on adsks websire) if they use flame on multiple machines, no way of stopping it , no way of checking. Adsk clearly has that info from the angry emails I have seen from other companies.
Our system works differently our machines are to “serve apps” everyone is on his “personalized” machine remoting int" for us this is so flexible and nice but yea it contradicts adsks ideas maybe…
I really just want
You know how many times I used to have maya open on different machines because of whatever all with my single AD user , so the reverse can also happen where the same system user is logged into multiple machines.
I am pretty sure that if autodesk sets up a licensing compliance trap
Can you elaborate? So you’re using the Macs as terminals and everyone remotes into another system where Flame actually runs? Even the client suite?
Also, you can always tell your freelancers not to use the license on their Mac at home. That they need to remote into one of your systems.
I can tell them, but then what am I gaining from “user based licensing” . and I cant stop them other than to remove access to the license which means i have to manage all logging in all the time, like alan does.
So yea the client suite is the only one where a physical mac is the rest is in a serverrack. for now, this probably will change too and I will run fibre for SDI to the suite with a switcher.
usually people tend to use the same machines but sometimes that changes. freelancers etc.
It all sounds like a licensing trap, maybe I have to talk to a lawyer and check if thats even legal in germany lol. probably not, seems preditory af.
1 Like
Ich stimme dem nicht zu.
A trap has to be intentional. Same with predatory. Don’t see that being the case.
Sending threatening letters when their system has bugs causing the appearance of abuse and them not doing enough diligence on their end to button things up, could be considered undue harassment.
In the end it probably is one thing we see every day: a company decides to redesign a product and with it a crucial process flow - like going from floating to login licenses. In their ‘do more with less’ resourcing model they cover the first 80% of the use cases and celebrate success. Then the remaining 20% of corner cases rear their head, catch them by surprise, and they aren’t prepared, and because users generally are considered by too many executives as necessary evils rather than raison d’etre the whole thing devolves into a shit-show. I mean the press wouldn’t have anything write about if that didn’t happen.
At the large enterprise level login based licensing is less appealing since not all your users that are assigned a license will be working at the same time. So floating licenses work better at that scale. But that can be fixed by just offering discounts that brings down the login licenses to the average use rate at that enterprise. Easier than maintaining two licensing models.
It would be interesting to learn why ADSK feels that user based licensing is desirable? Did they have large accounts asking for that? Probably not the Flame user base, since we’re just a write-in vote with the company. This comes from one of their flagship apps, like AutoCAD. But once they do it, it has to be across the board.
Also, what user do your artists login as on the machine room macs?
What I said about separate OS users applies to the system running Flame.
So if they share logins on dumb terminals, no harm. But everyone should have their own OS user on your Flame servers, then it would work as designed and detailed above.
These are all typical issues small mid sized companies face. It’s more complex than single user, but our processes aren’t as mature as big enterprise. We end up between the chairs, and often system designs don’t account for that space enough. They don’t make it easy on us, and we don’t have the bandwidth and resources to compensate. Everyone gets frustrated.
1 Like
We all use a default local admin user to login to the “terminal”.
There are so many things I would have to setup per user somehow the overhead would crush me…
1 Like
Totally. That space in-between is too complex for the resources you have, yet it doesn’t offer a satisfactory solution in-between single user and enterprise which has dedicated IT staff. We are artist and IT department at the same time.
We saw this in the backlash against the new user settings in 2025.1 (or was it 2025?). Same reason.
Floating licenses would have solved your compliance problem. But with the software migrating to individual user preferences, that’s a losing battle.
This may have been ok, if we started that way from the beginning. But re-building this mid-journey creates a headache.
‘Don’t fix it if ain’t broke’
There is a tool for Synology that you may want to sandbox, called Synology Directory Server, which is a 2008 AD compliant server.
Setup is straightforward.
It will enroll hosts, users and groups.
If your growth ambition is low, and you don’t need to lose your mind on ACLs then this is worth investigating, because it works with your existing hardware, then fades away - maintenance requirements are pretty low.
There is also an LDAP Server.
FreeIPA is a good solution here, but not trivial.
It is not beyond you to find your way through the software but the options (and possibilities for error) are extensive.
You can spin up a Rocky 94 vm in proxmox, although it’s a good idea to dedicate at least one real NIC to FreeIPA.
Then there’s Entra…
Bye bye money and bye bye future money, but it’s pretty amazing.
not neccesary. we’ve run FreeIPA as a basic VM on all types of host hardware for a decade.
1 Like
If there hadn’t been talk of angry communication from Autodesk then I may have suggested this as a non-issue.
I am not opposed to the user license model but it potentially needs to be smarter on the Autodesk side. If a cloud based Autodesk server basically acted as a floating license server, if when you tried to login and the user license was checked out to another Flame instance then it could give you the option of either automatically (and remotely by an Autodesk server triggered logout) logging out the other instance and using this new instance instead or otherwise cancelling the Flame launch. Simple, easy, no danger of license being abused either intentionally or not. Not sure what happens when security dictates no internet access to workstations though (although all security protocols I have read allow whitelisting certain websites to allow for this license model) but this is already an issue if you are on set or somewhere with no internet connection so would make no difference to the status quo. This would surely be the simplest model and I actually thought this was how user licensing was supposed to work anyway? Seems to me how Adobe licensing works.
Once again, as discussed earlier in this thread, I’ve always dug the dongle license option. So simple and easy to carry around if you are going to use another system. Floating License server also rocks, it isn’t that hard to setup VPN access to a self hosted floating license server. In the case of the user license model, and I reckon the argument would stand up in a court of law if Autodesk did come after anyone legally, the onus is actually on Autodesk to provide a rock solid licensing model that does not allow the user to break the license agreement. If Autodesk has stuffed up their licensing system then that is their issue. Oh, and the long end user agreements that you have to agree to don’t actually stand up in a court of law. There are precedents against this in most countries as there cannot be expectations that the average person can understand a complex legal agreement. Any license agreement needs to be short and in layman’s terms or else it means nothing legally. Most countries have a small claims court which is usually free, based on common sense and you can usually represent yourself. Autodesk taking anyone to court would cost them more than what they would recoup so doubt it would ever come to that.
So in the end, I don’t think we have a massive issue here unless you are intentionally doing the wrong thing.
2 Likes
I have PTSD from dealing with foundry and microsoft when it comes to “license audits”
Beign treated like a criminal as a paying customer is not my kind of vibe
3 Likes
happened to me a few years back. Got a very unpleasant letter accusing me of multiple users on the licence. I contacted ADSK and found out exactly what machines and when they were accusing me of using and found the problem…during One Frame of White, i had a last minute glitch in the entry and when Andy asked me to check something I had the project on both my home mac and the office. I remoted in to the office to check a few settings, saved the file, copied over to the home mac. I am usually very careful to log out before opening on another…this time it was purely a mistake. I could easily explain the issue and ADSK accepted the result, but its really annoying that they can waste your time resources trying to fight them off claiming you owe them many thousands of pounds for fraudulently using software that already costs you thousands a year.
And is it such a crime for a user who pays a fortune each year for the software, to get penalised if its opened on two machines at once (by mistake) while that one user is working on the same single project ?
Maxon/C4d licencing works well in that you can use it on all your machines, but if its being used it will not let you open the app until the licence has been released from the other computers. Why can’t ADSK implement that without it having to be a client feature request?
edit: and now i read a few more of the many entries before mine and realise this has now been addressed by ADSK and should no longer be an issue.
2 Likes