public inbox for sourcenav@sourceware.org
 help / color / mirror / Atom feed
From: Syd Polk <jazzman@bayarea.net>
To: Robert Hartley <rhartley@ics.com>
Cc: sourcenav@sources.redhat.com
Subject: Re: SN backend GPL or LGPL?  (was: SourceNav release...)
Date: Wed, 13 Feb 2002 12:19:00 -0000	[thread overview]
Message-ID: <90FC0288-20BB-11D6-A405-0050E4C09301@bayarea.net> (raw)
In-Reply-To: <3C6A9292.7BB4B877@ics.com>


On Wednesday, February 13, 2002, at 08:21 , Robert Hartley wrote:

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

No, Red Hat made us release everything as GPL'd. Since Red Hat owns the 
copyright, you can contact them for a version with LPGL'd backend.

>
> 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 don't think so. As long as you are not linking any of the libraries, 
you should be ok.

>
> 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 <supermo at bayarea dot net>
>> To: "Eray Ozkural (exa)" <erayo at cs dot bilkent dot edu dot tr>
>> 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.
>
>
Syd Polk
QA and Integration Manager, Mac OS X Development Tools
+1 408 974-0577

  reply	other threads:[~2002-02-13 19:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-13  9:06 Robert Hartley
2002-02-13 12:19 ` Syd Polk [this message]
2002-02-13 10:38 Davies, Mike
2002-02-13 10:50 ` Robert Hartley
2002-02-13 11:25   ` Ian Roxborough
2002-02-13 11:55 Doug Fraser
2002-02-13 12:49 ` Robert Hartley
2002-02-15  9:43 Doug Fraser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=90FC0288-20BB-11D6-A405-0050E4C09301@bayarea.net \
    --to=jazzman@bayarea.net \
    --cc=rhartley@ics.com \
    --cc=sourcenav@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).