sockets

[Brian K. White]

The socket licensing is only illogical in that no one really wants it 
that way, but it's not intrinsically illogical.

You are not licensing individual sockets, you licensing the right to use 
the socket features at all.

It's pretty simple and Ken is right that people are just thinking about 
it wrong.

Richard had the right question which I would like to see the answer to, 
because that would make Ed and Nancy's arguments at least 50% valid.

If the license isn't counted when a process starts, unless and until the 
first time a process actually uses any socket feature, then it really is 
reasonable to expect that license to also be released when the process 
is no longer using any socket feature.

But I see no technical foul play here, no justification to cry foul and 
no problem to build a working and predictable application. You just have 
to understand what the rules are, and it's perfectly possible to play by 
them. They are odd, and I have rejected them for the various reasons I 
already stated, but they are not broken or even unfair unless one 
question comes back the wrong way:

Ed, in your application, are you saying that you have a socket function 
in a call table, and that within a single clerk or report 
process/session, every call to the call table decremented the sockets 
license and those didn't release until the parent clerk exited? That 
would be completely broken. This question is only meaningful if you had 
more than one sockets license total. I would expect one sockets license 
to be used, and not released until clerk exited, but no more than one 
sockets licenses to be used for that clerk session no matter how many 
times you called the call table and no matter how many sockets you 
opened and left open concurrently.

So it's basically just like all fp licenses since the beginning. If you 
have 5 users and collectively they may end up running a peak total of 
say 25 concurrent processes due to multiple windows, cron jobs, cgi 
scripts etc, and any of them might potentially use sockets features, 
possibly all at the same time, then you need 25 licenses to be sure.

What makes it reasonable to even offer to license the feature separately 
is, you may also have a 500 process system with only one single cron job 
or perpetual looping daemon process that uses sockets for one thing, and 
none of the other 500 processes anywhere ever uses any sockets. In that 
case you would only have to buy theoretically a single sockets license, 
or 2 or 3 just to be safe.

-- 
bkw