On Tue, 18 Sep 2012 20:19:41 +0200 Anton Gladky wrote: > 2012/9/18 Francesco Poli <invernom...@paranoici.org>: > > > > Something that is *not* legally distributable does *not* magically > > become distributable, just because the architecture is not officially > > supported by the Debian Project... > > This part of the issue may be irrelevant for the release of wheezy, but > > not generally irrelevant: I think you should have gmsh removed from the > > m68k architecture, in order to make this part of the issue really go > > away. > > I am not agree. It is NOT officially supported by Debian. Why should we care > about that? The version there is 2.3.0, it is very old.
It is not officially supported by Debian, but packages built for that architecture are still distributed by the Debian Project! If one such package is not legally distributable, the distribution of that package should be stopped, unless there are other ways to solve or work around the issue! Hence, I think that the least that should be done is removing m68k from the list of architectures for which gmsh is auto-built. So that gmsh is no longer present in unstable or testing for m68k. > > > There seem to be other GPL-licensed libraries linked with gmsh: > > libcholmod1.7.1 (some parts are GPL-licensed) > > libumfpack5.4.0 (UMFPACK is GPL-licensed) > > http://packages.debian.org/changelogs/pool/main/s/suitesparse/current/copyright > > Please correct me if I am wrong. > > > > Linking with these libraries seem to still make the GPL-incompatibility > > of OCE/OpenCASCADE very relevant, unfortunately. > > If this is really the case, then the possible solutions I can think of > > are: > > > > (A) Open CASCADE S.A.S. should be contacted and persuaded to > > re-license Open CASCADE Technology under GPLv2-and-v3-compatible terms. > > > > (B) Open CASCADE Technology should be substituted with a > > GPLv2-and-v3-compatible replacement, if any is available. > > > > (C) CHOLMOD and UMFPACK copyright holders should be asked to re-license > > these libraries under the GNU LGPL. > > > > (D) CHOLMOD and UMFPACK copyright holders should be asked to add a > > license exception that gives permission to link these libraries with > > code released under the OCTPL. > > It is weird to contact upstream of third-party codes to ask about > relicensing due to some uncertain license-incompatibilities. It may be weird, but something has to be done in order to solve this issue. Please note that the incompatibility of the OCTPL with the GNU GPL is not uncertain: it is clearly explained in bug #617613 (which was cited in my original bug report). In particular, it is acknowledged by the Open CASCADE S.A.S. FAQ <http://www.opencascade.org/occt/faq/>. I am still convinced that the solution to be preferred is (A), but, until we succeed in obtaining a GPL-compatible Open CASCADE, the other possible strategies should be considered. > > Actually libsuitesparse-dev is not even in build-depends of GMSH. > I think your statement is irrelevant. Sorry. I don't see how it can be irrelevant, sorry. The libraries I mentioned are among the dependencies of the binary package gmsh and of other binary packages built from the gmsh source package: I assume that they are there for a reason. These libraries (or part of them) are GPL-licensed, as far as I can see. If the Gmsh executable (or the Gmsh library) is really linked with both Open CASCADE (or OCE) and with at least one GPL-licensed library, then the license incompatibility kicks in and makes the binary package undistributable. If the linking is indirect and the GPL-licensed libraries are not used by Gmsh, then I wonder why they get pulled into the binary package dependencies... -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! ..................................................... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgpB5KIiKyX8E.pgp
Description: PGP signature