From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4868 invoked by alias); 13 Feb 2002 16:21:32 -0000 Mailing-List: contact sourcenav-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: sourcenav-owner@sources.redhat.com Received: (qmail 4811 invoked from network); 13 Feb 2002 16:21:31 -0000 Received: from unknown (HELO ics.com) (216.112.183.3) by sources.redhat.com with SMTP; 13 Feb 2002 16:21:31 -0000 Received: from ics.com (ics.com [216.112.183.3]) by ics.com (8.9.0.Beta5/8.9.0.Beta5) with ESMTP id LAA19431 Wed, 13 Feb 2002 11:21:28 -0500 (EST) Message-ID: <3C6A9292.7BB4B877@ics.com> Date: Wed, 13 Feb 2002 09:06:00 -0000 From: Robert Hartley Organization: Integrated Computer Solutions (ICS) X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: sourcenav@sources.redhat.com Subject: SN backend GPL or LGPL? (was: SourceNav release...) Content-Type: multipart/mixed; boundary="------------2CB44C710202586E2BCC4D53" X-SW-Source: 2002-q1/txt/msg00065.txt.bz2 This is a multi-part message in MIME format. --------------2CB44C710202586E2BCC4D53 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-length: 1456 If we did have the back end torn off of SN, would that make everything that used also GPL? Can we take SN type GPL code, turn it into a library, and then use it in an LGPL way? What if we had some sort of Corba type middle ware that provided a decent distributed API, without actually linking the code in. Would any application that connected to it still be bound by the GPL? I am trying to find out here if there is any room for commercial developers to contribute to SN. It would be a shame to let it all go to waste. Thanks, Robert > From: Mo DeJong > To: "Eray Ozkural (exa)" > Cc: sourcenav at sources dot redhat dot com > Date: Thu, 10 Jan 2002 09:45:27 -0800 > Subject: Re: SourceNav release ... > I think the right solution is to turn the SN backend into a > library. Even if you don't reuse the code, the ideas that are > there have years of effort behind them and they do work. It should > make use of Berkeley DB to store symbols but through an API so > that people can swap out other database layers if they want to. It > should also provide a nice two phase parse and dump into symbol DB > sequence that is easily inspected. Just figuring out what and > where the problem with a parser is can be the most difficult part > of fixing a problem. Also, it is absolutely critical that a well > defined regression test framework is developed as part of the > library. --------------2CB44C710202586E2BCC4D53 Content-Type: text/x-vcard; charset=us-ascii; name="rhartley.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Robert Hartley Content-Disposition: attachment; filename="rhartley.vcf" Content-length: 366 begin:vcard n:Hartley;Robert tel;fax:617-621-9555 tel;work:617-621-0060 x-mozilla-html:TRUE url:http://www.ics.com/ org:Integrated Computer Solutions (ICS);Engineering version:2.1 email;internet:robert.hartley@ics.com title:Systems Engineer adr;quoted-printable:;;Sixth Floor=0D=0A201 Broadway;Cambridge;MA;02139;USA x-mozilla-cpt:;7328 fn:Robert Hartley end:vcard --------------2CB44C710202586E2BCC4D53--