fenics team mailing list archive

[Andre Massing <massing@xxxxxxxxx>]

Anders Logg wrote:
> On Fri, Feb 12, 2010 at 01:28:40AM +0100, Andre Massing wrote:
> > Anders Logg wrote:
> > > Here's an update on the status for getting packages ready for
> > > inclusion in the next Ubuntu LTS release.
> > >
> > > 1. Johannes needs all releases to be ready by Monday. That will give
> > > him a couple of days to prepare the packages.
> > >
> > > Which releases do we want to make? There have been JIT compiler fixes
> > > in FFC and UFL that would be good to get in, and also updates in
> > > DOLFIN.
> > >
> > > We have also made changes to Instant. The buildbot is failing for
> > > Instant but I don't know why.
> > >
> > > 2. Unfortunately the DOLFIN package needs to be build without CGAL and
> > > ParMETIS.
> > >
> > > The reason is that both CGAL and ParMETIS are in the non-free section
> > > of Debian. I knew from before that ParMETIS has a non-free license
> > > (which makes an even stronger case for SCOTCH) but I don't know why
> > > CGAL is in non-free. Anyone else knows why?
> > I still struggling with this license jungle but there is a rather
> > long thread why Debian consider the QPL library as not compliant
> > with the DSFG  (Debian Free Sofware Guidlines), but to cite from
> >
> > http://lists.debian.org/debian-legal/2004/05/msg00992.html
> >
> > "The QPL requires that all changes are sent to the original
> > author upon request, and that all license disputes are settled in
> > Amsterdam City Court by the laws of the Netherlands.  Both of these
> > restrictions are non-DFSG-free.
> > "
> >
> > or see the general discussion on QPL
> >
> > http://lists.debian.org/debian-legal/2004/04/msg00233.html
>
> I thought this was settled since Qt and KDE are in Debian main but
> apparently not. Here's what Debian say about the QPL:
>
>  The DFSG-freeness of this license has been called into question. Some
>  people appear to believe that because the Qt library is in Debian
>  main, that the QPL is DFSG-free. That is a hasty conclusion, however,
>  because the Qt library is also licensed under the GNU GPL (see
>  http://www.trolltech.com/newsroom/announcements/00000043.html).
>
>  The QPL is not GPL-compatible, which, regardless of one's opinion
>  about the license's DFSG-freeness, poses a major practical problem for
>  any code licensed under the QPL that is reused elsewhere in
>  conjunction with code under the GNU GPL. This makes the QPL alone a
>  particularly poor choice of license for a library.
>
>  Furthermore, it is not clear that the Trolltech corporation (the
>  author of the Qt library and the QPL itself) believes the QPL to be a
>  free software license. Trolltech's website describes how their
>  dual-license approach is intended to be "open source-friendly" (see
>  http://www.trolltech.com/company/model.html). If Trolltech felt that
>  the QPL alone were friendly enough to open-source, why do they have a
>  dual-licensing policy?
>
>  Copyright holders in QPL-licensed works should be encouraged to follow
>  Trolltech's example, and dual-license their work under the GNU GPL or
>  another clearly DFSG-free license.
>
> See http://wiki.debian.org/DFSGLicenses#QPublicLicense.28QPL.29.2CVersion1.0
> So the QPL should be avoided.
>
> Perhaps we should ask the CGAL people why they are still using QPL and
> ask them to use something else. If enough people ask them, perhaps
> they will care.

We can try, but I think they that there is a fairly little chance, since 
a lot of non-basic packages in CGAL are licensed under the QPL. But I 
will investigate it.

I also figured out that we nowadays only need to link against libCGAL 
and not libCGAL_Core (was a relict from old testing programs)
Johannes mentioned something that libCGAL is licensed unter LGPL ?
So I am wondering whether something can be debain/main if it *only* 
depends on a LPGL compatible lib which is distributed together with some 
 non QPL libs in non-free?

And there is there the issue that we using some template headers, which 
are under QPL.
Complicated, we probably have to figure it out after the next release 
due to time-constraints...?

> --
> Anders
>
>
> > > If DOLFIN is compiled against CGAL or ParMETIS then the DOLFIN package
> > > would depend on a non-free package, which would place DOLFIN in the
> > > contrib section, which for technical Debian reasons places DOLFIN in
> > > the "NEW" queue, which means Johannes cannot upload but must get
> > > someone else with higher "Debian security clearance" to upload and
> > > that will take a while. There would also be a similar problem for the
> > > FEniCS meta package.
> > >
> > > So DOLFIN will be built without CGAL and ParMETIS in Ubuntu, but will
> > > be available with these dependencies in Launchpad PPA.
> > That's a bit of a pity that CGAL has this kind of strange license mix.
> >
> > > We should sort out our dependencies for future releases.




> > I am also wondering whether using a dynamically loadable library
> > instead of shared library would influence the decision which
> > category a package will be put in...
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~fenics
> > Post to     : fenics@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~fenics
> > More help   : https://help.launchpad.net/ListHelp