> > Please seriously consider IB_WISQL as a replacement to WISQL.
> >
> > If it doesn't have some things you want, lend me the sources to WISQL

and

> > I'll port them into IB_WISQL.
> >
> > I've been giving it away as total freeware so there are no issues with
> > licensing to worry about.

> I believe that a tool like WISQL has to be part of the InterBase Open
> Source distribution.

I agree that it should be accessible to all who want to use and contribute
to it for free. I fully allow that...

Not only do contributors get free licensing but under the "Trustware" model
I even grant full usage of my code pending something for commercial gain
works out. If nothing profitable takes place then they are not bound to
submit licensing. Submitting licensing is a voluntary thing and I leave it
up to the moral judgment of the component user. If someone absolutely thinks
that they should never have to pay for software and they use IBO for free
and make millions of dollars with their applications then that's a risk I
suppose I'm taking. I have faith in the people of this world that there will
be enough people with integrity to submit their licensing sufficient to make
it worth my time. If people aren't or can't make money with IBO sufficient
to pay licensing (without it being a hardship to them) then I have no desire
to collect money from them.

> IB_WISQL is not Open Source, AFAIK, and even if it were, an IBO license
> would be needed to work on it.

Yes, a free license is all that is required. Anyone that contributes
something to IBO gets free licensing whether commercial or not.

It is frustrating that many seem to have their false assumptions but there
is only so much I can do about that...

This has been my policy for over three years now... I'll admit I haven't
made it publicly obvious though until a little over a year ago...

> I think that, _if_ the "official" component-based way to InterBase is
> IBX, then those components should be used to build Delphi & C++B tools
> that will be part of the product. I can see that there are areas where
> they overlap with IBO (and where IBO is definitely superior)...

With all due respect, there are some items that need to be clarified here.
Not only are your assumptions about IBO and its licensing incorrect but
there are other very important aspects that need to be considered here.
There are many benefits to using the native IBO data access architecture for
this over IBX data access... I'll explain. (beware of ramble)

IBO has been designed as an ideal tool suite to use in an application such
as a WISQL. It contains loads of functionality and capabilities that IBX
would be a very long time to ethically catch up with. Why should everyone go
without those capabilities when they are freely available in IBO?
Additionally, much of what is in IBO that makes it special will never be in
IBX unless it were to be "intellectually stolen". There are some very unique
and special algorithms that are under copyright protection and I fully
intend to guard them as such.

I suppose some IBX'ers could scramble and try the catch-up game with IBO but
the only thing accomplished there would be to put me out of business and end
up with nothing better after a ton of hard work. I'd rather that effort be
directed into making what is already great, better. I think the InterBase
community would also be better off if I didn't have to take my talents and
skills elsewhere. Cooperation is far better than competition in this arena.

The IBX data access architecture is dependant on the TDataset portion of the
VCL so technically IBX should NOT be considered open source-able. InterBase
does not have the right to open source the VCL data access code and so IBX
is not a viable piece of technology for those who are working on projects
that mandate all involved tools also be open sourced. IBX cannot be ported
to anywhere other than Inprise development environments and that limits it
severely as to who in the open source community is going to get involved
with it. I hope InterBase aspires to be used from the whole development
community in general and not just Inprise development tools. Their official
tools such as WISQL should reflect that...

IBO on the other hand, has far less dependencies than IBX. IBO has, in
addition to full BDE emulation components based on TDataset, the whole
native data access architecture that uses nothing above TComponent (other
than visual controls). This is what is used in IB_WISQL. Thus, this
architecture is highly portable to other development environments such as
the LINUX FPK (free PASCAL) and other environments. Why not get these people
involved in the development of WISQL too?

Back in May I made an official statement that I intend to share the native
IBO data access architecture with all these other open source development
environments. Essentially, I am attempting to elevate the IBO data access
architecture to become a standard in the LINUX development community. It
needs a standard to be defined and I can't think of a better model to start
from than the IBO one. Especially one that will bring in a richly integrated
visual element. I am ready, willing and waiting for all the pieces to come
together to more aggressively pursue this course.

Like me I think ISC has a grand vision of where InterBase can go in the
whole development community than locking into Inprise only tools. This is
the vision InterBase needed in the past to succeed and needs as much today
as it did back then. Otherwise we may be doomed for the same fate InterBase
nearly met at the "Black Christmas" last year.

How many people are out there that have Delphi 2 and cannot afford to
upgrade to Delphi 5 that might want to get involved with open source
InterBase? IBX requires that everyone upgrade to Delphi 5 whereas IBO allows
Delphi 2 and higher. This is a big plus for InterBase to get everyone
possible involved as affordably as possible I think.

Because they seem to recognize this I am allowing InterBase to distribute
IBO (not the eval either) with their distributions. Everyone will have
access to IBO as much as IBX. I am also allowing the new InterBase company
(the one we are all wondering how is going to make some $$ to stay afloat)
to receive a significant portion of IBO trustware licensing fees received
through them. I want them to make the funds they need to stay afloat and
this is one more of my ways to help this to happen. I think we can all
safely assume that this means they will have a vested interest in promoting
IBO as much or more than IBX.

IBX needs to remain focused on the new services and installation API's. I
intend on leaving it that niche open for it to grow and flourish in. As for
the data access portion, I fully intend to keep the momentum I have and
strive keep it so that using IBO is preferable in every aspect over IBX.
Count on it. Pouring work into the IBX data access layer may very likely be
a futile cause since those willing to get involved making contributions will
be doing it in IBO because that gets them free licensing and a huge leap
forward in completeness and stability.

So, in conclusion, I would seriously reconsider making the assumption that
IBX's data access components are going to win out over IBO in the long run.
If everyone is made aware of how IBO is licensed and took the time to see
how much more complete and stable it is nobody would waste their time with
IBX, except for those who, for one reason or another, are emotionally
attached to it.

Regards,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com