Hi Dave,

Ladybridge and openQM have put the fun back in MV for me (and several
others that I know of).

Martin does an excellent balancing act between keeping the traditional
MV feel and workability and adding modern functionality. This has
impressed me greatly.

This has been discussed at length (beaten to death?) in every venue
from private e-mail to the openQM mailing list, CDP and Debian Legal.
The consensus from those in the know has been that the GPL is being
followed better here than it is in many projects.

First, a common misconception is that FLOSS in general and the GPL in
particular prohibit sale and/or profit - this is simply not the case.

Perhaps a bit of confusion here: The "derived work" concept applies to
code which embodies or is reliant upon GPL'd libraries and API's.
Ladybridge's approach appears to me to be following in the footsteps of
the original mySQL dual licensing.

Now I guess I need my old disclaimer:
I am not now nor have ever wished to be a lawyer. <g>
-Tom

P.S.
<SHAMELESS PLUG>
Leaving the whole GPL issue out of the mix, IMHO (the commercial
version of) openQM is a much superior product to many of the current
offerings - and at a much lower cost of ownership.

This coupled with the ease of migration makes me wonder why folks would
consider re-writing something like D3 a bit at a time ... wouldn't it
be easier and less expensive to simply migrate to a live and breathing
DBMS like openQM?

Given the ease of web connectivity and other modern concepts embodied
in openQM, these savings continue into the future.
</SHAMELESS PLUG>

i thought if an entity desired to umbrella under the "API -or- library"
approach... it should have been performed under the "LGPL" versus the
"GPL": http://www.gnu.org/licenses/lgpl.html

no? (i trust this has probably been beat to death as you stated... so
don't feel compelled to chase this... the only reason i surfaced it is
that it was the crux of a tiny redflag when reviewing a personal
"return on commitment", ie. chasing a marketing lure of socialism
while being confronted with a cash-register in the background. for
some reason there's a troublesome dichotomy. if one gets past this,
then it simply reduces to
convenience/functionality/standards/reliability/price/performance.
based upon the modest snapshot that i did, I have to imagine
substantial energy has gone towards each of these. i'll definitely
give this a closer look sometime.)

dave

dzigray wrote:

It's well worth your time to take a good look at OpenQM.

--
Kevin Powick

Tony Gravagno wrote:
object's properties from an object's handle is generally fundamental
and shouldn't require explanation -- it's also fundamental to concepts
of encapsulation -- so as not to require "insider" knowledge of
underlying structures.

application? in fact, there are countless techniques for performing
the efficient management of opening files and implicitly binding
relationships between a file's name and the filevariable.

if coding an application-level program, i would definitely make certain
to utilize such a technique (as you suggest) should the filename be of
any importance to me -- and then shame on me if i didn't! --
especially in a D3 system.

HOWEVER... if you were implementing a generalized utility/support
program/remote-debugger... would a debugger know which file-variable is
tied to which file-name-variable? no... especially given all the
creative tony's out there with their own file-open techniques.
(granted, if you were writing a system-debugger for pick... you could
easily get the filename from the FCB... but that's a different story.)

i'm sorry... i could disclose more of what i'm doing to provide greater
justification for my need... but the above should suffice.