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