bug-commoncpp
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFE. Boost C++.


From: David Sugar
Subject: Re: RFE. Boost C++.
Date: Sun, 14 Apr 2002 17:21:37 -0400 (EDT)

Hmm...I did not get that far looking at Boost yet.  The question of
preserving freedom in software is important as well, which is why we
choose to use the (L)GPL in the first place.  In the GNU project we have
unique and largely (L)GPL'd implimentations of ansi and similar standard
libraries, in glibc, in the stdlibc++ in gcc, etc.  Perhaps a more
interesting question could be how to have a freely implimented reference
based on on a GPL project (such as GNU Common C++), with the GNU
implimentation being a GPL'd implimentation of the same said base ref.  
One way to achieve that might be a dual disjunctive license strategy, and
that might be one of the few cases it might make sense to consider a dual
disjunctive license between a BSD style license and a GPL or LGPL'd one.

However, this discussion is speculative.  I am not advocating changing our
license strategy in GNU Common C++ at this point, but simply offering some 
discussion on the issues involved.

David

On Sun, 14 Apr 2002, Jeremy Noetzelman wrote:

> Offhand, I do believe that the 'freely licensed' requirement they refer to
> wouldn't apply to (L)GPL'd software, as the GPL isn't free in the sense
> that it places requirements upon licensees.
> 
> In fact, http://www.boost.org/more/lib_guide.htm explicitely states that
> Boost can't accept (L)GPL'd submissions.
> 
> It might be better suited to take some of the interesting things out of
> Boost and reimplement them into CC++ instead.  Besides, then nobody will
> have to deal with the horrific build system Boost uses ;)
> 
> On Sun, 14 Apr 2002, David Sugar wrote:
> 
> > Ali,
> >
> > I had not been fully aware of Boost as a resource for vetting free
> > implimentations of libraries as a precursor for standards proposal
> > before.  In that Boost seems to require free (freely licensed) source
> > available implimentations, I see no fundimental conflict with that, or
> > even with the work of the ansi/c++ draft committees in regard to what we
> > choose to do in GNU.
> >
> > Further, in some ways GNU Common C++ was intended to address
> > shortcommings of the existing C++ ansi standard library by directly
> > addressing functionality (sockets, threads, synchronization,
> > serialization, etc) that they choose at the time to ignore :).  In that
> > respect, the mission of GNU Common C++ does seem consistent and related
> > to the stated goals of Boost.  In that regard, it would seem there is a
> > real basis for further discussion about what Boost is doing and how it
> > relates to what we are doing in GNU Common C++.
> >
> > David
> >
> > Ali-Reza Anghaie wrote:
> >
> > >I'd like to submit a RFE. Basically I'd like to suggest that the Boost
> > >C++ project and GNU Common C++ get together and work on integrating
> > >their projects.
> > >
> > >Regards, -Ali
> > >
> >
> >
> >
> > _______________________________________________
> > Bug-commoncpp mailing list
> > address@hidden
> > http://mail.gnu.org/mailman/listinfo/bug-commoncpp
> >
> 
> 
> _______________________________________________
> Bug-commoncpp mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-commoncpp
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]