Re: [open-cobol-list] libdb Licensing - READ

[Roger While]

Re: Licensing - This is rather interesting :
http://www.internetnews.com/dev-news/article.php/3495981
especially the last sentence.

Re: Proprietary sources -
Actually to try to get them to open source.
I cannot believe that C-ISAM is a major revenue earner for IBM
and as they have recently opensourced some 50 projects
on Sourceforge it may be possible.

Re: VBISAM -
Try this :
www.sim-basis.de/vbisamcvs.tar.gz
Usual configure/make/make install

Well, TC, OC and VBISAM were never designed to run natively
under Win. However, OC and VBISAM do run under Cygwin and
supposedly under Ming. (Maybe TC too ?)

Both VBISAM and C-ISAM do have transaction facilities.
Interesting point - How does one specify in Cobol if one wants
transactions ?

Roger

At 16:51 04.05.2005 -0400, you wrote:
> Roger While wrote:
>
> > Thanks for taking a time out from your own project.
>
> Actually, I'm not currently an active developer in any open source 
> project.
>
> However this topic as been discussed on the TinyCOBOL mailing list on 
> several occasions.
>
>
> > At least here in Europe (with driver program "cobcrun"
> > and compiling applications as modules ), there is NO
> > licensing problems (So, I have been informed by a lawyer).
>
> I think one can safely say that you would need a small army of lawyers, at 
> least one per jurisdiction, to get a full legal opinion.
>
>
> > I really do not want to be held up by legal constraints.
>
> I agree.
>
> The time would be better spent doing actual development.
>
>
> > Therefore, we should both concentrate on an alternative.
> > I will continue to contact sources. (Including I*M - C-ISAM).
>
> Well, what your objective is in contacting proprietary sources ?
>
>
> > I have CVS access to the VBISAM project (As you know)
>
> Well, VBISAM looks promising.
>
> However, I could not get the tests, enclosed with VBISAM, to work 
> properly. So I could not confirm nor deny any of the author's claims.
>
> Also, VBISAM is geared toward a UN*X style file-system. So some ports 
> (FAT, NTFS ...) of the file-system parts would be required.
>
> While it does have record level locks, it does not adequately deal with 
> concurrency issues. So some form of a transaction processor (small, say 30 
> users or less) would be required.