dolfin team mailing list archive

["Garth N. Wells" <g.n.wells@xxxxxxxxxx>]

On Sat, 2006-04-01 at 06:52 -0600, Anders Logg wrote:
> On Sat, Apr 01, 2006 at 11:25:16AM +0200, Garth N. Wells wrote:
> > On Fri, 2006-03-31 at 13:11 -0600, Anders Logg wrote:
> > > On Fri, Mar 31, 2006 at 06:22:39PM +0200, Garth N. Wells wrote:
> > > > On Fri, 2006-03-31 at 10:17 -0600, Robert C. Kirby wrote:
> > > > > >
> > > > > > I downloaded boost, pulled the header files out and dropped them  
> > > > > > into my
> > > > > > directory and it worked fine, so it appears that no binary  
> > > > > > libraries are
> > > > > > involved. I did a grep on the header files, and the dependency on  
> > > > > > other
> > > > > > boost components is limited.
> > > > > >
> > > > > 
> > > > > Is there any license issue to just stuffing the requisite .h files  
> > > > > into DOLFIN?
> > > > > 
> > > > 
> > > > No. The Boost license is more liberal the GPL. You can find it here
> > > > http://www.boost.org/LICENSE_1_0.txt.
> > > > 
> > > > Garth
> > > 
> > > I'm not sure. If you look in the GPL FAQ which is available at
> > > http://www.gnu.org/licenses/gpl-faq.html you find the following answer
> > > to the question "What is the difference between "mere aggregation" and "combining two
> > > modules into one program?":
> > > 
> > >     Mere aggregation of two programs means putting them side by side
> > >     on the same CD-ROM or hard disk. We use this term in the case
> > >     where they are separate programs, not parts of a single
> > >     program. In this case, if one of the programs is covered by the
> > >     GPL, it has no effect on the other program.
> > > 
> > > --> Combining two modules means connecting them together so that they
> > > --> form a single larger program. If either part is covered by the
> > > --> GPL, the whole combination must also be released under the GPL--if
> > > --> you can't, or won't, do that, you may not combine them.
> > > 
> > >     What constitutes combining two parts into one program? This is a
> > >     legal question, which ultimately judges will decide. We believe
> > >     that a proper criterion depends both on the mechanism of
> > >     communication (exec, pipes, rpc, function calls within a shared
> > >     address space, etc.) and the semantics of the communication (what
> > >     kinds of information are interchanged).
> > > 
> > >     If the modules are included in the same executable file, they are
> > >     definitely combined in one program. If modules are designed to run
> > >     linked together in a shared address space, that almost surely
> > >     means combining them into one program.
> > > 
> > >     By contrast, pipes, sockets and command-line arguments are
> > >     communication mechanisms normally used between two separate
> > >     programs. So when they are used for communication, the modules
> > >     normally are separate programs. But if the semantics of the
> > >     communication are intimate enough, exchanging complex internal
> > >     data structures, that too could be a basis to consider the two
> > >     parts as combined into a larger program. 
> > > 
> > > You could interpret this as if we distribute ublas as part of DOLFIN,
> > > then ublas must be licensed under the GPL, which we can't do?
> > > 
> > > On the other hand, the boost license is listed as compatible with the
> > > GPL so I guess it should be ok:
> > > 
> > >     http://www.gnu.org/philosophy/license-list.html
> > > 
> > > /Anders
> > > 
> > 
> > Looks ok to me since it's GPL-compatible. From
> > http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses
> > 
> >     "We classify a license according to certain key questions:
> > 
> >         * Whether it qualifies as a free software license.
> >         * Whether it is a copyleft license.
> > -->     * Whether it is compatible with the GNU GPL. (This means 
> >           you can combine a module which was released under that 
> >           license with a GPL-covered module to make one larger program.)
> >         * Whether it causes any particular practical problems."
> > 
> > 
> > Garth
> 
> Yes, looks ok.
> 
> What is logic behind including ublas and not other dependencies? Why
> don't we include libxml2 and PETSc? In the first case perhaps because
> it may be considered more standard than ublas and be expected to be
> present and in the second case because it's too big...
> 

I thought about this and some reasons to include it are (in no
particular order)

1. uBlas is not a binary library, so it seems natural to include it (not
sure that this is a legitimate motivation).

2. It is small, so the cost in terms of the increased size of the DOLFIN
source package is minimal, while the benefit is that we avoid an extra
dependency.

3. Boost has a non-standard build procedure that may confuse some users,
while uBlas does not need to be built. Also the default installation
location of Boost is version dependent, so it is likely that users will
have to specify the location manually.

A reason not to include it is that it is available as a package for most
Linux distributions and for Cygwin. Another reason not to include it and
to make it a dependency is if we wish to exploit more Boost libraries in
the future we don't have to be shy about it. I can see the Boost
libraries multi_array, static_assert, random and python possibly being
useful.

What I'll do is first not add ublas in the development version of DOLFIN
and see how everybody goes building it. It should be straightforward to
install the Boost package. If it proves problematic, we can add the
ublas code later.

Garth 


> /Anders
> 
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev