RE: SN backend GPL or LGPL? (was: SourceNav release...)

RE: SN backend GPL or LGPL? (was: SourceNav release...)

[Doug Fraser]

First, let me say that I agree that the Lesser GPL (LGPL)
is a far more flexible license for development of
library components. No doubt. But SN is an entity, a whole,
not a collection, so I would be surprised to see it go LGPL
in a general sense. That being said, I'll attempt to explain
my reasoning for supporting your earlier 'CORBA' example.

Using SN as a tool in cooperation with other tools
would not run against the spirit of OpenSource. If
that were true, then the compilation of proprietary
solutions using GCC would also run against the spirit.
As would using PERL to handle CGI into a proprietary database
on a web server. All these tools are used as solutions
in proprietary settings every day. Deriving a proprietary
work from an open source product would run counter,
because that derived work itself is what is being marketed.
In the same sense, you can derive works from GPL products
for your own personal use without turning those changes
back, as long as you do not make the derived work available
to anyone else. So in that sense, if you bundle SN with
a collection of other tools that communicate with an
autonomous SN to perform useful work, that would be an
accepted use. What would matter, though, is if you modified
SN to provide a closed backend to enable communications
to your tools. If, however, you provide that modification
to the public, then you have met your responsibility to
the community by providing a useful extension to the
existing tool.

Doug

> -----Original Message-----
> From: Robert Hartley [mailto:rhartley@ics.com]
> Sent: Wednesday, February 13, 2002 3:20 PM
> To: sourcenav@sources.redhat.com
> Subject: Re: SN backend GPL or LGPL? (was: SourceNav release...)

<snip>

> All other issues aside, using Corba or something as a 
> workaround would not be
> in the collaborative spirit of open source.
> 
> That is why I am wondering about an LGPL version of the SN backend.
> 
> Thanks to all for listening,
> 
> - Rob
> 
> 

Let's start it (Re: SN backend GPL or LGPL?)

[Eray Ozkural]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey there,

IMHO, we don't need a license different from GPL. Let it remain free...

We still have to decide on a name. I suggested sourcebase, and Mo said fuzzyp
(but that's a fuzzy name ;). It's probably going to be hosted on
sources.redhat.com so we have to do an initial import to start the work. I
suggest that we start with the source/snavigator directory, with all its
contents (we don't build gui/ though). That way, we'll be forced to drop
hacked versions of tcl/tk and the old db. It's easy to use upstream tcl/tk in
the part of the code we're going to adapt. It was said on this list before
that the old berkeley db was used for performance, but is that really true?
We can go for the latest berkeley db instead of that one. It might also allow
us to use a few advanced features, those people are crazy for performance.

With that directory, we're going to have to work on the build system and do
some changes (hopefully minor) for a preliminary version. I tried the
feasibility of that and it doesn't seem hard, I've got it half-working here.

We can keep the C and tcl/tk interfaces in, and simply disable all GUI stuff.

Then, we can progress to work on the API. (Like refining library API, writing 
a C++ wrapper, an abstract database interface, etc.)

Thanks,

- -- 
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8bUhdfAeuFodNU5wRAgbxAKCV2HfCq7VEs1lKnNIECW7gI+SncQCfZiPg
iqKm9lk6tEDV0yFmlEHfHSY=
=Crmp
-----END PGP SIGNATURE-----

Re: Let's start it (Re: SN backend GPL or LGPL?)

[Mo DeJong]

On Fri, 15 Feb 2002 19:41:47 +0200
Eray Ozkural <erayo@cs.bilkent.edu.tr> wrote:

> IMHO, we don't need a license different from GPL. Let it remain free...

If we directly swipe SN code then it would have to be GPLed. If instead we
simply swipe the APIs and ideas then it could be licensed under a LGPL
or Berkeley style license.

> We still have to decide on a name. I suggested sourcebase, and Mo said fuzzyp
> (but that's a fuzzy name ;).

I think the name still needs work. Can anyone think of a good name that captures
the concept of a database of symbols and/or fuzzy parsing? I don't think the
name has to have anything to do with sourcenav since we would expect that
other projects want to use it too.

> It's probably going to be hosted on
> sources.redhat.com so we have to do an initial import to start the work. I
> suggest that we start with the source/snavigator directory, with all its
> contents (we don't build gui/ though). That way, we'll be forced to drop
> hacked versions of tcl/tk and the old db.

Well, the Tcl/Tk version on sources now is a rather stock 8.3. The old releases
were built on "hacked Tcl/Tk" versions but that is not really the case anymore.
I think we are fine depending on the Tcl version on sources for the Tcl API
to the database layer and the testing framework.

> It was said on this list before
> that the old berkeley db was used for performance, but is that really true?
> We can go for the latest berkeley db instead of that one. It might also allow
> us to use a few advanced features, those people are crazy for performance.

The newer releases of BDB have a feature that allows for atomic operations.
If something crashed the DB should not become corrupted. This seems like
an important new feature since a hosed symbol DB is one of the more common
problems in SN.

> With that directory, we're going to have to work on the build system and do
> some changes (hopefully minor) for a preliminary version. I tried the
> feasibility of that and it doesn't seem hard, I've got it half-working here.
> 
> We can keep the C and tcl/tk interfaces in, and simply disable all GUI stuff.

I think reworking the C API is the most important and most critical initial step.
Once you get into the guts of the existing C API, you realize that it appears to
be a rather clean layer on top on a more scary DB interface. I think we want
to just keep the clean layer and avoid the more scary bits.

Mo

Re: Let's start it (Re: SN backend GPL or LGPL?)

[Eray Ozkural]

On Friday 15 February 2002 22:25, Mo DeJong wrote:
>
> I think the name still needs work. Can anyone think of a good name that
> captures the concept of a database of symbols and/or fuzzy parsing? I don't
> think the name has to have anything to do with sourcenav since we would
> expect that other projects want to use it too.
>

Come on, it can't be this difficult to find a name. What are your suggestions 
people?

Thanks,

-- 
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C