[DUG] Licencing schemes
Todd Martin
toddm at kol.co.nz
Sun Apr 30 21:05:22 NZST 2006
Okay. So how do you do it in Unix?
Todd.
----- Original Message -----
From: "Paul Heinz" <paul at accredo.co.nz>
To: <johnkbird at paradise.net.nz>; "NZ Borland Developers Group - Delphi List"
<delphi at ns3.123.co.nz>
Sent: Sunday, April 30, 2006 8:48 PM
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.
>
>
>
>
>
>
> _______________________________________________
> Delphi mailing list
> Delphi at ns3.123.co.nz
> http://ns3.123.co.nz/mailman/listinfo/delphi
>
>
>
> --
> Internal Virus Database is out-of-date.
> Checked by AVG Free Edition.
> Version: 7.1.385 / Virus Database: 268.4.5 - Release Date: 21/04/2006
>
>
--
Internal Virus Database is out-of-date.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.4.5 - Release Date: 21/04/2006
More information about the Delphi
mailing list