In the past we used Application::IsGuiActive() to determine what
licenses of our product, AtomKraft (AK), we allow running inside the
Nuke session.
If IsGuiActive() returned false, we would pick up both AK/batch *and*
AK/interactive licenses.
This silently assumes that if you run out of AK/batch licenses on your
nuke_r render jobs, you are happy for them to pick up unused
AK/interactive lics.
Then we had a client who didn't like this, probably because their farm
was 'stealing' AK/interactive seats from their compers.
So we changed it to use Application::UsingInteractiveLicense(). That
means now you must start nuke with -i for it to take an available
AK/interactive license. This essentially ties the license types of
hostapp and plugin to each other 1:1.
This is what the client wanted but it has the side effect that if you do
want to use AK/interactive licenses /at all/ in GUI less Nuke sessions,
you are now forced to run nuke with -i, i.e. taking a very expensive
nuke_i license.
In retrospect he sensible thing would probably have been to make this a
choice, i.e. a configuration option that each site can change.
I personally do not think that enforcing this will lead to a notable
increase of AK/batch sales. It also doesn't change the annoying fact
that our customers now are forced to either:
- buy expensive nuke_i licenses for each AK/interactive seat they want
to use on their farm.
- buy additional AK/batch seats but then still have their AK/interacrive
seats being totally unused, e.g. at night on the farm or when compers
are idle.
So my question is: how do other 3rd party vendors handle this? Anything
I may overlook, any better solutions? Experiences? Customer reactions?
Thanks in advance for taking the time to answer!
--Moritz
_______________________________________________
Nuke-dev mailing list
Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
