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

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

[Robert Hartley]

[-- Attachment #1: Type: text/plain, Size: 975 bytes --]

Doug Fraser wrote:

> If you link in a library, your new work embodies that library, and
> thus is covered by the license of the underlying library. If that were
> not so, then any OpenSource project could be turned into a library
> in order to void the GPL. So the act of linking to a library binds your
> work to the underlying license. Deriving a library from a GPL product
> conveys GPL status to that library, since the library is a derivative work.
>
> Which, in the spirit of the tool and the spirit of OpenSource, is
> as it should be. However, I can't see that it would keep you from
> developing an extended IDE if the rest of the IDE communicated to
> SN through an API that did not require linking. CORBA as you say
> or a database.

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


[-- Attachment #2: Card for Robert Hartley --]
[-- Type: text/x-vcard, Size: 366 bytes --]

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

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

[Syd Polk]

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

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

[Doug Fraser]

If you link in a library, your new work embodies that library, and
thus is covered by the license of the underlying library. If that were
not so, then any OpenSource project could be turned into a library
in order to void the GPL. So the act of linking to a library binds your
work to the underlying license. Deriving a library from a GPL product
conveys GPL status to that library, since the library is a derivative work.

Which, in the spirit of the tool and the spirit of OpenSource, is
as it should be. However, I can't see that it would keep you from
developing an extended IDE if the rest of the IDE communicated to
SN through an API that did not require linking. CORBA as you say
or a database. You could develop that API, feed it back to the
community, then move forward with the proprietary tools, just using
a separate SN as a backend. Some would argue against that on
philosophical grounds, but it would appear to be quite legal.


Personally, I am quite happy with my SN5.0 release. One of these
days, work permitting (yeah, fat chance...) I want to learn how
to hook it into the backend of VIM, so I can use VIM as my editor,
and have it feed controls back to SN. VIM has a backend hook built
into it, so it should not be too hard.

Thank you to the all the fine folk who have provided
and contributed to SN.

Doug

> -----Original Message-----
> From: Ian Roxborough [mailto:irox@redhat.com]
> Sent: Wednesday, February 13, 2002 1:40 PM
> To: Robert Hartley
> Cc: MDavies@uk.waukbearing.com; sourcenav@sources.redhat.com
> Subject: Re: SN backend GPL or LGPL? (was: SourceNav release...)
> 
> 
> On Wed, 13 Feb 2002 13:38:26 -0500 Robert Hartley 
> <rhartley@ics.com> wrote:
> >
> > What I was trying to ask is if we made the back end of SN a 
> shared library,
> > libSNdb.so, would every thing that linked to this library 
> have to be GPL'd or
> > would the library be able to be treated as a LGPL work?
> 
> This would require a change to the licensing, which probably
> won't happen.
> 
> Ian.
> 

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

[Ian Roxborough]

On Wed, 13 Feb 2002 13:38:26 -0500 Robert Hartley <rhartley@ics.com> wrote:
>
> What I was trying to ask is if we made the back end of SN a shared library,
> libSNdb.so, would every thing that linked to this library have to be GPL'd or
> would the library be able to be treated as a LGPL work?

This would require a change to the licensing, which probably
won't happen.

Ian.

> "Davies, Mike" wrote:
> 
> > > 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?
> >
> > Any changes you made to the Sourcenav Code would be GPLed and you would have
> > to provide them in the usual ways,  however it seems to me that any
> > application that used the CORBA interface would be effectively dynamically
> > linked to it and so might escape 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.
> >
> > Well,  many commercial firms contribute to GPLed SW,  there is nothing
> > stopping you from doing that.  If you are trying to make a proprietry
> > version of SourceNav then this is prohibited by the licence.  That is quite
> > apart from the implications for the feelings of people who contributed their
> > efforts freely for the common good.
> >
> > Mike Davies
> 

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

[Robert Hartley]

[-- Attachment #1: Type: text/plain, Size: 1255 bytes --]

What I was trying to ask is if we made the back end of SN a shared library,
libSNdb.so, would every thing that linked to this library have to be GPL'd or
would the library be able to be treated as a LGPL work?

Ian?

-rob

"Davies, Mike" wrote:

> > 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?
>
> Any changes you made to the Sourcenav Code would be GPLed and you would have
> to provide them in the usual ways,  however it seems to me that any
> application that used the CORBA interface would be effectively dynamically
> linked to it and so might escape 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.
>
> Well,  many commercial firms contribute to GPLed SW,  there is nothing
> stopping you from doing that.  If you are trying to make a proprietry
> version of SourceNav then this is prohibited by the licence.  That is quite
> apart from the implications for the feelings of people who contributed their
> efforts freely for the common good.
>
> Mike Davies

[-- Attachment #2: Card for Robert Hartley --]
[-- Type: text/x-vcard, Size: 366 bytes --]

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

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

[Davies, Mike]

Hi Robert,

IANAL,  but :

> If we did have the back end torn off of SN, would that make everything
> that used also GPL?

Yes, if it was an extension of GPLed code

> Can we take SN type GPL code, turn it into a library, and 
> then use it in
> an LGPL way?

Nope.

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

Any changes you made to the Sourcenav Code would be GPLed and you would have
to provide them in the usual ways,  however it seems to me that any
application that used the CORBA interface would be effectively dynamically
linked to it and so might escape 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.

Well,  many commercial firms contribute to GPLed SW,  there is nothing
stopping you from doing that.  If you are trying to make a proprietry
version of SourceNav then this is prohibited by the licence.  That is quite
apart from the implications for the feelings of people who contributed their
efforts freely for the common good.


Mike Davies

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

[Robert Hartley]

[-- Attachment #1: Type: text/plain, Size: 1456 bytes --]

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


[-- Attachment #2: Card for Robert Hartley --]
[-- Type: text/x-vcard, Size: 366 bytes --]

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