Re: [Elmerdiscussion] Re: Debian package for Elmer - Re: ITP: Elmer -- Finite element software for multiphysics problems
Hello again, On Thu, 2008-11-13 at 15:10 -0500, Adam C Powell IV wrote: On Thu, 2008-11-13 at 08:05 -0500, Adam C Powell IV wrote: [snip] Thank you. I'm afraid I'm already well-enough along that the only issue remaining is finding Scotch functions corresponding to METIS_MeshPartNodes and METIS_MeshPartDual. I'm in contact with upstream, which is helping with this (off-list). I've posted my first two versions 5.4.1-1 and 5.4.1.dfsg-1 at http://lyre.mit.edu/~powell/elmer/ . The former includes the full source, and works (as far as I can tell), but doesn't have the versioned shared library. The latter omits mathlibs, umfpack and elmergrid/src/metis, and has a complete copyright file for what's left, but ElmerGrid linking fails because of the missing Metis functions as mentioned. I've just posted .dfsg-2 which is DFSG-compliant (doesn't include metis) and includes a working -- but not complete -- ElmerGrid. That is, ElmerGrid can't do METIS-style partitioning using the MeshDual and MeshNodal methods because Scotch doesn't support them, though it can do the other three METIS partition styles. I also reversed the order of the rpath and shlibs patches, so the attached shlib patch should be acceptable for upstream adoption. I built it also for 32-bit. They're up in my Debian Lenny repository at opennovation.org. I'm building Ubuntu Hardy 64- and 32-bit as well. I have not patched it to work with Debian's UMFPACK. If I need it, I'll take care of that; otherwise I'll wait for the next Elmer release. The only two ways to get around this are: * Get the ARPACK people to drop the non-free requirements of their license (see http://bugs.debian.org/491794 ). * Change the license of Elmer either to something like LGPL or to grant an explicit GPL exception to link with ARPACK (and maybe Metis?). Both of these are, of course, beyond the scope of this maintainer... :-( This is still needed before I can upload to Debian. Somehow Francesco's post didn't get to the Elmer list, so I'll point out that the FSF's linking exception example is at: http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLIncompatibleLibs Note that there are different texts for GPLv2 and v3; Elmer is I believe currently under v2. Also, this applies to the elmergrid directory re Metis and fem directory re ARPACK. These copyright notices typically go in the AUTHORS file. Share and enjoy, and please let me know if there are any errors. Cheers, -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ --- elmerfem-5.4.1/fem/src/Makefile.am~ 2008-11-10 17:07:18.0 -0500 +++ elmerfem-5.4.1/fem/src/Makefile.am 2008-11-10 17:06:59.0 -0500 @@ -79,7 +79,8 @@ libelmersolver$(SHL_EXT): $(SOLVEROBJS) binio/libbinio.a $(RM) $@ - $(SH_LD2) $(RPATH_ELMER) $(SH_LDFLAGS) $(B64FLAGS) $(LDFLAGS) -o $@ $(SOLVEROBJS) $(SOLVER_LIBS) -L. -Lbinio -lbinio + $(SH_LD2) $(RPATH_ELMER) $(SH_LDFLAGS) $(B64FLAGS) $(LDFLAGS) -Wl,-soname,libelmersolver-5.4.1.so -o libelmersolver-5.4.1.so $(SOLVEROBJS) $(SOLVER_LIBS) -L. -Lbinio -lbinio + ln -s libelmersolver-5.4.1.so $@ .$(OBJEXT).$(SHLEXT): @@ -186,7 +186,7 @@ $(CP) ElmerSolver$(EXEEXT) $(DESTDIR)$(prefix)/bin $(CP) ViewFactors$(EXEEXT) $(DESTDIR)$(prefix)/bin $(CP) GebhardtFactors$(EXEEXT) $(DESTDIR)$(prefix)/bin - $(CP) libelmersolver$(SHL_EXT) $(DESTDIR)$(prefix)/lib + $(CP) -a libelmersolver*$(SHL_EXT) $(DESTDIR)$(prefix)/lib $(CP) elmerf90 elmerf90-nosh elmerld $(DESTDIR)$(prefix)/bin if USE_MPI $(CP) ElmerSolver_mpi$(EXEEXT) $(DESTDIR)$(prefix)/bin signature.asc Description: This is a digitally signed message part
Re: Debian package for Elmer - Re: ITP: Elmer -- Finite element software for multiphysics problems
On Fri, 2008-11-14 at 21:50 +0100, Francesco Poli wrote: On Fri, 14 Nov 2008 08:57:40 -0500 Adam C Powell IV wrote: [...] On Thu, 2008-11-13 at 23:49 +0200, Mikko Lyly wrote: [...] Indeed, you're fine as far as your distribution is concerned; as far as I can tell no GPL code in the fem directory written by others which is linked to ARPACK. As the Elmer copyright holder, you just need to abide by the ARPACK license, and can do whatever you want with the Elmer code. But if Debian redistributes it, and the code changes hands, the owner of the Elmer copyright can in theory restrict Debian from distributing it. [...] LGPL for Elmer is unfortunately not possible at the moment, but an GLP exception might be taken under consideration. How would you like to see the exception be documented for being compatible with Debian policies? I'm afraid I don't have enough experience with this to give good advice here. Can someone on debian-legal perhaps provide an example of a copyright statement which provides such an GPL exception? Hi Adam, hi everyone else! Hi Francesco! [I am keeping you and the other addresses in Cc:, since you asked to be Cc:ed in the past and I suppose the other people are not subscribed to debian-legal] Thanks, no need for me since I subscribe to debian-science. If I understand correctly, the issue is that Elmer, which is distributed under the terms of the GNU GPL, links against ARPACK, which is available under GPL-incompatible and non-free terms. The distributability issue may be solved with a GPL exception granted from Elmer copyright holders, as long as no other purely GPL'ed code is included in or linked with Elmer. That is to say, *each* copyright holder of GPL'ed code included in or linked with Elmer must agree with the GPL exception. To clarify: each copyright holder of GPL'ed code in the binary/binaries which link with ARPACK needs to agree. As mentioned, my review of the fem directory showed that CSC owns the copyright to all of the code in question (ElmerSolver, libelmersolver, all of the equation plugins). Assuming that all such copyright holders agree, the canonical example GPL linking exception is detailed at http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLIncompatibleLibs Thanks, I was not aware of this. On the other hand, I think you (Adam) are aware that this solution would force Elmer to be placed in the contrib Debian archive (rather than in main), Yup, my pre-upload package is already in contrib. with the additional inconvenience that ARPACK has now been removed from Debian: http://bugs.debian.org/497900 I re-uploaded it into non-free a couple of days ago. I would recommend getting in touch with ARPACK upstream maintainers and persuading them to relicense ARPACK under DFSG-free and GPL-compatible terms (a 3-clause BSD license would be an optimal suggestion). Indeed, will do. I hope this helps. Disclaimers: IANAL, TINLA, IANADD, TINASOTODP. It helps a lot! Thanks, -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: Debian package for Elmer - Re: ITP: Elmer -- Finite element software for multiphysics problems
On Fri, 14 Nov 2008 08:57:40 -0500 Adam C Powell IV wrote: [...] On Thu, 2008-11-13 at 23:49 +0200, Mikko Lyly wrote: [...] Indeed, you're fine as far as your distribution is concerned; as far as I can tell no GPL code in the fem directory written by others which is linked to ARPACK. As the Elmer copyright holder, you just need to abide by the ARPACK license, and can do whatever you want with the Elmer code. But if Debian redistributes it, and the code changes hands, the owner of the Elmer copyright can in theory restrict Debian from distributing it. [...] LGPL for Elmer is unfortunately not possible at the moment, but an GLP exception might be taken under consideration. How would you like to see the exception be documented for being compatible with Debian policies? I'm afraid I don't have enough experience with this to give good advice here. Can someone on debian-legal perhaps provide an example of a copyright statement which provides such an GPL exception? Hi Adam, hi everyone else! [I am keeping you and the other addresses in Cc:, since you asked to be Cc:ed in the past and I suppose the other people are not subscribed to debian-legal] [BTW, there's no need to Cc: me, as long as debian-legal is among the recipients] If I understand correctly, the issue is that Elmer, which is distributed under the terms of the GNU GPL, links against ARPACK, which is available under GPL-incompatible and non-free terms. The distributability issue may be solved with a GPL exception granted from Elmer copyright holders, as long as no other purely GPL'ed code is included in or linked with Elmer. That is to say, *each* copyright holder of GPL'ed code included in or linked with Elmer must agree with the GPL exception. Assuming that all such copyright holders agree, the canonical example GPL linking exception is detailed at http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLIncompatibleLibs On the other hand, I think you (Adam) are aware that this solution would force Elmer to be placed in the contrib Debian archive (rather than in main), with the additional inconvenience that ARPACK has now been removed from Debian: http://bugs.debian.org/497900 I would recommend getting in touch with ARPACK upstream maintainers and persuading them to relicense ARPACK under DFSG-free and GPL-compatible terms (a 3-clause BSD license would be an optimal suggestion). I hope this helps. Disclaimers: IANAL, TINLA, IANADD, TINASOTODP. -- On some search engines, searching for my nickname AND nano-documents may lead you to my website... . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgp2C9wMo6bIE.pgp Description: PGP signature
RE: [Elmerdiscussion] Re: Debian package for Elmer - Re: ITP: Elmer -- Finite element software for multiphysics problems
Hi, The configure files are tuned by the authors with the -m64 compilation flag. I have made the package only available for the amd64 architectures. Migrating to different architectures and even to i386 means patching more the configure system and has to be checked with the authors. Ah, I didn't notice this, thanks for the heads-up. I'll make sure to take care of this before uploading. Actually the configure tries by default to figure out whether your current system is capable of 64 bit. You can force to drop the-m64 by using the configure option --with-64bits=no. Regards, Juha -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian package for Elmer - Re: ITP: Elmer -- Finite element software for multiphysics problems
On Thu, 2008-11-13 at 08:05 -0500, Adam C Powell IV wrote: On Thu, 2008-11-13 at 09:55 +, Antonio Amorim wrote: Dear Colleagues, I have previously created a debian package for Elmer that does not claim to fulfill the official debian policies but might be useful to trigger the debian work. The package is available as source and for the amd64 architecture. It is available form the repositories: deb http://mirror.sim.ul.pt/debian-paipix etch main contrib non-free where one can replace deb by deb-src and etch by lenny or sid. In the backport to etch, I also backported libqt4 that is available from the same repository. The packages are elmerfem and elmerfem-doc. All packages are build under pbuilder so the dependencies should be Ok. Thank you. I'm afraid I'm already well-enough along that the only issue remaining is finding Scotch functions corresponding to METIS_MeshPartNodes and METIS_MeshPartDual. I'm in contact with upstream, which is helping with this (off-list). I've posted my first two versions 5.4.1-1 and 5.4.1.dfsg-1 at http://lyre.mit.edu/~powell/elmer/ . The former includes the full source, and works (as far as I can tell), but doesn't have the versioned shared library. The latter omits mathlibs, umfpack and elmergrid/src/metis, and has a complete copyright file for what's left, but ElmerGrid linking fails because of the missing Metis functions as mentioned. Both are supposedly in section contrib. The first should really be non-free because of the inclusion of Metis. I'm afraid I realized *after* putting a lot of time into this that neither one is acceptable to Debian, because Debian considers ARPACK to be non-free, and will almost certainly refuse to distribute a GPL program linked to a non-free library. The only two ways to get around this are: * Get the ARPACK people to drop the non-free requirements of their license (see http://bugs.debian.org/491794 ). * Change the license of Elmer either to something like LGPL or to grant an explicit GPL exception to link with ARPACK (and maybe Metis?). Both of these are, of course, beyond the scope of this maintainer... :-( In the meantime, feel free to enjoy and add to these two packages. I'd welcome any patches to improve them. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
RE: [Elmerdiscussion] Re: Debian package for Elmer - Re: ITP: Elmer -- Finite element software for multiphysics problems
Hello Adam, First of all, thank you for your effort, it is greatly appreciated. The only two ways to get around this are: * Get the ARPACK people to drop the non-free requirements of their license (see http://bugs.debian.org/491794 ). * Change the license of Elmer either to something like LGPL or to grant an explicit GPL exception to link with ARPACK (and maybe Metis?). Both of these are, of course, beyond the scope of this maintainer... :-( I do understand the problem, but could you please elaborate the Debian point of view? I think we are good wrt the licence of Arpack (we reproduce the copyright notice in the documentaion, at least, as required by Arpack license for binary distributions, as well as for source). LGPL for Elmer is unfortunately not possible at the moment, but an GLP exception might be taken under consideration. How would you like to see the exception be documented for being compatible with Debian policies? Regards, Mikko Lyly From: Adam C Powell IV [EMAIL PROTECTED] Sent: Thursday, November 13, 2008 10:10 PM To: debian-science@lists.debian.org Cc: [EMAIL PROTECTED] Subject: [Elmerdiscussion] Re: Debian package for Elmer - Re: ITP: Elmer -- Finite element software for multiphysics problems On Thu, 2008-11-13 at 08:05 -0500, Adam C Powell IV wrote: On Thu, 2008-11-13 at 09:55 +, Antonio Amorim wrote: Dear Colleagues, I have previously created a debian package for Elmer that does not claim to fulfill the official debian policies but might be useful to trigger the debian work. The package is available as source and for the amd64 architecture. It is available form the repositories: deb http://mirror.sim.ul.pt/debian-paipix etch main contrib non-free where one can replace deb by deb-src and etch by lenny or sid. In the backport to etch, I also backported libqt4 that is available from the same repository. The packages are elmerfem and elmerfem-doc. All packages are build under pbuilder so the dependencies should be Ok. Thank you. I'm afraid I'm already well-enough along that the only issue remaining is finding Scotch functions corresponding to METIS_MeshPartNodes and METIS_MeshPartDual. I'm in contact with upstream, which is helping with this (off-list). I've posted my first two versions 5.4.1-1 and 5.4.1.dfsg-1 at http://lyre.mit.edu/~powell/elmer/ . The former includes the full source, and works (as far as I can tell), but doesn't have the versioned shared library. The latter omits mathlibs, umfpack and elmergrid/src/metis, and has a complete copyright file for what's left, but ElmerGrid linking fails because of the missing Metis functions as mentioned. Both are supposedly in section contrib. The first should really be non-free because of the inclusion of Metis. I'm afraid I realized *after* putting a lot of time into this that neither one is acceptable to Debian, because Debian considers ARPACK to be non-free, and will almost certainly refuse to distribute a GPL program linked to a non-free library. The only two ways to get around this are: * Get the ARPACK people to drop the non-free requirements of their license (see http://bugs.debian.org/491794 ). * Change the license of Elmer either to something like LGPL or to grant an explicit GPL exception to link with ARPACK (and maybe Metis?). Both of these are, of course, beyond the scope of this maintainer... :-( In the meantime, feel free to enjoy and add to these two packages. I'd welcome any patches to improve them. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
