On Sun, 9 Dec 2012 21:48:43 -0800 Ludovico Cavedon wrote: [...] > On Fri, Dec 7, 2012 at 1:13 PM, Francesco Poli (wintermute) > <invernom...@paranoici.org> wrote: > > I noticed that ntop is mainly licensed under the terms of the GNU GPL > > v2 or later, with only one file (ssl.c) having an OpenSSL linking > > exception. > > > > However, ntop seems to link with libssl (which is notoriously > > GPL-incompatible) and also seems to link with libgdbm (which [1] > > is licensed under the GNU GPL v2 or later, with no OpenSSL > > linking exception). > > > > [1] > > http://packages.debian.org/changelogs/pool/main/g/gdbm/gdbm_1.8.3-11/libgdbm3.copyright > > This does not look like an issue to me. > There is no linking from libgdm3 to openssl, and libgdm3 makes no use > of openssl, so the problematic clauses of the openssl do not apply to > to libgdm3.
Even if there's no *direct* linking of libgdm3 with libssl, it is my understanding that there is indeed an issue, as long as one single binary executable is linked with both libgdm3 and libssl. I believe that this follows from Section 3 of the GNU GPL v2. gdbm is the "Program" released under the terms of the GNU GPL v2 or later. The binary executable linked with it is "a work based on it" (according to the FSF's legal theory of linking, which is usually assumed to be valid by the Debian Project, in order to stay on the safe side...), and Section 3 states, in part: | 3. You may copy and distribute the Program (or a work based on it, | under Section 2) in object code or executable form under the terms of | Sections 1 and 2 above provided that you also do one of the following: | | a) Accompany it with the complete corresponding machine-readable | source code, which must be distributed under the terms of Sections | 1 and 2 above on a medium customarily used for software interchange; or, | [or other methods to make the source available...] Hence, one has to make the source code available under the terms of Sections 1 and 2, that is to say, among other things "licensed as a whole at no charge to all third parties under the terms of [the GNU GPL v2]" (see clause 2b). But, "For an executable work, complete source code means all the source code for all modules it contains [...]" (as clarified in the final part of Section 3). But one of the modules is libssl, which cannot be made available under the terms of the GNU GPL v2, since its license is incompatible. > > > I am under the impression that several ntop source GPL-licensed > > files get compiled into a binary that links with libssl, > > but do not have any OpenSSL linking exception. > > The only source code file which uses openssl is ssl_utils.c and it has > an openssl exception. I thought that was enough. > However, I did some reading to refresh my memory on the topic and I > can see how this could be interpreted to apply to all source code > files that to into the binary. It is my understanding that all the source files that get compiled into the object code which links with libssl need the exception. [...] > Thank you for the report, Thanks to you for your kind reply and for the time that you'll be willing to dedicate to the issue. Bye. -- 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
pgpnidozW7Fxg.pgp
Description: PGP signature
