Nope, it's hyperbolic, so it's expected (depends on what you chose for near and far plane).

Here's an explanation I just found through google which also has some graphs.

The characteristics of this can become a problem (precision distribution, z-fighting) and there's a whole plethora of tricks to overcome this (playing with the near/far-plane, infinite projection, reversing the depth value, using log-depth). I'm only slowly grasping all this myself, so rather search yourself. Just to give you an impression have a look at this Outerra blog entry.

Not sure if it's relevant for that culling library, since it stores full floats anyway. Also I might revoke a bit my earlier concerns: If you don't mix that occlusion depth values with the DirectX depth values (read: compare) it probably doesn't matter either as long as you project everything the same way. Also: a native float doesn't clamp like a depth buffer value.

An additional warning though: I tried to make samples running and got no luck. Even after fixing semi-hardcoded paths and some other inconsistencies, relevant samples produced SEHException (in C# this means something native went bad), so I wonder if the library actually works. At least I have no proof so far. (No offense to the author intended.)