Jason,

> > 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...

well, at least you have had one (more) chance to clarify things to me
and others who read this list. :-)

> 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

my view is clearer now, thanks.

> 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)

I didn't say that I mind whether one is better than the other (and I
have said that I _know_ IBO is superior under many aspects); I said
that, although your licensing scheme is not as restrictive as it may
seem to many (and for clarifying that I thank you again), two points
must be taken into account:

- IBX is the official open source component-based solution for
InterBase;
- there are areas in which IBX and IBO overlap.

If you could demolish these two points, I am more than happy to follow
you in your quest.

> I suppose some IBX'ers could scramble and try the catch-up game with IBO

You are talking about a game I am not interested in; in my opinion, the
better the tools, the happier the programmers. I am a programmer and I
can surely benefit of IB_WISQL (despite the name - have you thought
about giving it a more commercially sound one? ;-)), but I have to say
that your advice to use IB_WISQL and let WISQL/IBConsole die a terrible
death is not a good one; OS InterBase needs OS tools, and third parties
(like you) are welcome to produce better tools. This is the way I see
things currently. IBX could surely be deprecated in favor of IBO, but I
don't see it a reasonable thing just because IBO does not come directly
from InterBase (see later).

> 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.

I fully agree; I couldn't see how your initial post in this thread was
about cooperation, though.

> The IBX data access architecture is dependant on the TDataset portion of the
> VCL so technically IBX should NOT be considered open source-able.

In theory you're right; it can be open sourced just like anything
written in Delphi, which is dependant on TObject; to work on it, one
must purchase a Delphi license, which gives him the right to distribute
the results of his work as either free or commercial products; I can see
why this makes a product (IBX or IBO or whatever) not open source-able,
but I haven't understood your point.
But maybe we are slipping a bit OT here...

> 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...

are you suggesting rewriting the tools with IBO? How does that
accomodate with the open source scheme?

> 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.

Your point is clear; as I said in my previous post, I wanted to know
whether IBX was the official architecture (as it seems today) or not; if
I understand you right, the game is open about that, and thye community
will state what the better tools are. Is this right?
Personally, I will try to do my best to make the better prevail (still I
see it as a competition thing rather than collaboration...).

> 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.

You aree foreseeing a future in which the two products will complement
themselves, is this right?
Personally I would prefer a single framework, or at least a certain
interface uniformity; do you plan to do any work with IBX's developers
for that?

> 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.

Still you say it's not competition and talk about winners and loosers...

> 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.

The only software to work with InterBase I am "emotionally attached"
right now is the BDE, so you can see for yourself in which shoes I am
standing. :-)
In the end, I just can't see a future where both IBX and IBO will
survive, so why is InterBase making IBX part of the product? Could they
at least give the two alternatives out-of-the-zip-file (no boxes,
please)?
--
____
_/\/ando