I like this scheme - I have done something a bit like this with locking before (not your way though), but it did suffer from one problem, on a Windows network if a program crashed/was terminated/ or the PC rebooted, sometimes the locked block on the server was not cleared. Sometimes would clear after some time, sometimes had to be cleared manually on the server (Administrative tools/open files). I think it is a caching issue. Did you ever have such problems?
Other musings: As far as concurrent or per seat licences go, I take your point. One of the programs is used all the time (that is they open it and leave it running) on all screens that want to use it anyway, so concurrent and seat licences end up being the same in this case. Mind you concurrent also can mean two things - the program is always opened on the desktop, but only active when they are actively looking up data - which do you choose as the concurrent user (program open but in background or active). That also is an issue for developers and marketers to choose too! John -----Original Message----- From: Paul Heinz [mailto:[EMAIL PROTECTED] Sent: Sunday, 30 April 2006 8:49 p.m. To: [EMAIL PROTECTED]; NZ Borland Developers Group - Delphi List Subject: RE: [DUG] Licencing schemes John asked: > The scheme you mentioned appeals greatly because of its simplicity - > applies to licencing up to a fixed licenced number of concurrent > users. I didn't know there was a way to lock one byte - how do you do > that?? It's essentially a pair of Win32 APIs (LockFile and UnlockFile). You can look them up on MSDN for the full details. function LockFile(hFile: THandle; dwFileOffsetLow, dwFileOffsetHigh: DWORD; nNumberOfBytesToLockLow, nNumberOfBytesToLockHigh: DWORD): BOOL; stdcall; dwFileOffsetHigh and nNumberOfBytesToLockHigh need to be 0 for Win9X compatibility (if you care). So, to lock a single byte, pick an appropriate dwFileOffset and use a NumberOfBytesToLock of 1. Also, the file doesn't need to be as long as you have 'slots' i.e. it can even have a size of 0 since you can happily lock any bytes you like, even those beyond the end of the file. A gotcha to be aware of is that, in Win32 unlike Unix, you can't read bytes under a lock so don't lock anything which you will need to be able to read whilst any locks exist. > I was more leaning to licencing it per screen installed - it can be > more costly for the users but as the app is likely to be running much > of the day that is academic in this case. Well, we've been using lock-based concurrent user licensing for Profax (and now Accredo) since ummm.. ages ago i.e. right back to the DOS versions in the 80s and 90s. Technically, it's pretty hard to beat for simplicity, reliability, and enforceability. On the non-technical level, our experience is that customers accept concurrent licensing as more 'fair'. I think this is simply because they feel they are paying for _actual use_ and more use equals more business value which justifies paying more. Seat-based licensing is generally felt to be somewhat less 'fair' since they are forced to pay for _potential use_ i.e. because they might _rarely_ need to use your software from some PC, they have to pay as if they always use it from that PC. As seat-based licensing is essentially unenforceable (unless you plan on demanding to physically audit your customer!) it boils down to an 'honesty' system and since customers often feel seats-based is less fair, at best they are likely to only buy as many seats as they actually use or, at worst, they will cheat and under-license. So, my opinion is that, without compelling reasons to the contrary, you are generally better off with concurrent use licensing revenue-wise. TTFN, Paul. __________ NOD32 1.1461 (20060329) Information __________ This message was checked by NOD32 antivirus system. http://www.eset.com _______________________________________________ Delphi mailing list [email protected] http://ns3.123.co.nz/mailman/listinfo/delphi
