Re: [LAF-devel] Re: Design

[Wesley J L. <wj...@ic...>]

On Sunday 10 August 2003 8:25 pm, David M. Brown wrote:
> This looks good.  The only concern I've have in the past is with
> licensing of Sleepycat's Berkeley DB, but that was with projects that
> had some closed-source components.  Since I'm hoping we can keep this
> all BSD licensed, this should be OK.

Well, using BSD might be problematic...

=46or databases:

Sleepycat's license is GPL compatible (and obviously compatible with=20
itself) but it's not BSD compatible, because of clause #3:

* 3. Redistributions in any form must be accompanied by information on
 *    how to obtain complete source code for the DB software and any
 *    accompanying software that uses the DB software.  The source code
 *    must either be included in the distribution or be available for no
 *    more than the cost of distribution plus a nominal fee, and must be
 *    freely redistributable under reasonable conditions.  For an
 *    executable file, complete source code means the source code for=20
all
 *    modules it contains.  It does not include source code for modules=20
or
 *    files that typically accompany the major components of the=20
operating
 *    system on which the executable file runs.
 *

Likewise, MySQL support would be out, since that's GPL.=20

However, Postgresql *is* BSD licensed, so it could be used as a backend.

=46or a GUI:

Qt is GPL, so not BSD compatible.

wxWindows, GTK, and FOX are all LGPL, as is libgedcom (which I was=20
hoping to use). While these wouldn't affect this work itself being BSD,=20
it does prohibit distribution of executables without also providing=20
full source code for all libraries linked against it. (In essence,=20
negating the difference between BSD and GPL).

=2E..

Anyway, if we want to try to stay BSD, it might be tricky, but perhaps=20
could be done... personally, I think we might be better off going with=20
[L]GPL which would put quite a bit more free software at our disposal.

Of course, we can also play games to get around some license=20
prohibitions by (for instance) modularizing things to run as separately=20
linked processes that communicate with well-documented sockets or=20
something.

What is everyone's thoughts on this? I'm not against BSD, but it is=20
rather limiting from a consumer-of-free-software perspective.

> I'm not very familiar with ruby.  What are the advantages for using
> it as an embedded scripting language?  Can you give an example or two
> of how it could be used as such?

Well, ruby is a "scripting" language comparable in scope to perl or=20
python, except it's much more object-oriented, and, IMO, a much more=20
clean, intuitive language overall. It embeds as easily as perl or=20
python--usually using SWIG (http://www.swig.org/).

Basically the advantage of having scripting language support would be =20
twofold. As a developer, you can implement some logic that annoying to=20
do in C++ in ruby (or perl, or python, or whatever). For example, if=20
you wanted to have a plugin that fetched data from www.ancestry.com or=20
www.familysearch.com, it would be several lines in a scripting language=20
(which has built in network support, easy string manipulation, etc,=20
etc) while writing it in a compiled language would probably mean the=20
pain of creating sockets, connecting them, creating buffers, reading=20
data, parsing it, etc. Second, that you could (as a user) write custom=20
scripts to "drive" the GUI (generate custom reports, link data into=20
another program, whatever).

=2D-=20
Wesley J. Landaker - wj...@ic...
OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2