Re: [LAF-devel] Re: Design

[David M. B. <da...@da...>]

Wesley J Landaker wrote:

> 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...
> 
> For databases:
> 
> Sleepycat's license is GPL compatible (and obviously compatible with 
> 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 
> all
>  *    modules it contains.  It does not include source code for modules 
> or
>  *    files that typically accompany the major components of the 
> operating
>  *    system on which the executable file runs.
>  *

I don't see why this is a problem with the BSD license. In fact,
Sleepycat gives the GPL and BSD license as two good examples of
licenses which work with their license (at
http://www.sleepycat.com/download/licensinginfo.shtml). Here is part of
that page:

The open source license for Berkeley DB permits you to use the software
at no charge under the condition that if you use Berkeley DB in an
application you redistribute, the complete source code for your
application must be available and freely redistributable under
reasonable conditions.

Further down it mentions the BSD license, too.

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

I won't claim to be a license expert, but I'm fairly sure that
BSD-licensed code can use GPLed code. Now that I think about it though,
(one of) the point(s) of the GPL is to make sure code stays open, and
BSD code can be closed later on. But, then that code can no longer use
the GPLed code, right?

I'll have to look more closely at it. My network connection is flaking
out right now, so later... :/

> 
> However, Postgresql *is* BSD licensed, so it could be used as a backend.
> 
> For a GUI:
> 
> Qt is GPL, so not BSD compatible.
> 
> wxWindows, GTK, and FOX are all LGPL, as is libgedcom (which I was 
> hoping to use). While these wouldn't affect this work itself being BSD, 
> it does prohibit distribution of executables without also providing 
> full source code for all libraries linked against it. (In essence, 
> negating the difference between BSD and GPL).
> 
> ...
> 
> Anyway, if we want to try to stay BSD, it might be tricky, but perhaps 
> could be done... personally, I think we might be better off going with 
> [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 
> prohibitions by (for instance) modularizing things to run as separately 
> linked processes that communicate with well-documented sockets or 
> something.
> 
> What is everyone's thoughts on this? I'm not against BSD, but it is 
> 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 
> python, except it's much more object-oriented, and, IMO, a much more 
> clean, intuitive language overall. It embeds as easily as perl or 
> python--usually using SWIG (http://www.swig.org/).
> 
> Basically the advantage of having scripting language support would be  
> twofold. As a developer, you can implement some logic that annoying to 
> do in C++ in ruby (or perl, or python, or whatever). For example, if 
> you wanted to have a plugin that fetched data from www.ancestry.com or 
> www.familysearch.com, it would be several lines in a scripting language 
> (which has built in network support, easy string manipulation, etc, 
> etc) while writing it in a compiled language would probably mean the 
> pain of creating sockets, connecting them, creating buffers, reading 
> data, parsing it, etc. Second, that you could (as a user) write custom 
> scripts to "drive" the GUI (generate custom reports, link data into 
> another program, whatever).

Yeah; maybe we can make extensions possible in a couple of different
ways. Ruby sounds like a definite way to go.  Is it fairly widely used? 
  For my benefit can you give a couple of examples of where it's being used?

Thanks,
David


>