fenics team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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.

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

Attachment: signature.asc
Description: Digital signature