Andreas Metzler <ametz...@bebt.de> writes:
> well, we have decided to use the system library exception because we
> thought we had the right to so, not because we hoped that no copyright
> holder would notice. Undoing this for specific packages where a
> copyright holders tells us he disagrees undermines this position. Imho we
> need to either with using the exception or somebody(TM) needs to do a
> license analysis of our packages and we then need to implement coding
> changes to weed out any and all GPL<->openssl linkage.
I think the situation here is this dependency chain:
libcurl-gnutls -> libldap2 -> libssl
(There may be others; I didn't do a thorough check. Does anyone know if
there's a tool that will recursively analyze a binary's NEEDED sections
and build a human-readable graph of the library dependencies?)
openldap switched from GnuTLS to OpenSSL in 2.6.9+dfsg-1~exp2 in January
of this year.
The OpenLDAP dependency has a long history. (I was involved, many years
ago, in trying to find the money for development of the GnuTLS port for
licensing reasons.) Using GnuTLS is supported upstream, but it tends to
cause a steady stream of low-level issues, annoyances, and
incompatibilities. Were I still an OpenLDAP package maintainer, I would
have been eager to switch to OpenSSL as well.
I do find it fairly hard to understand the logic behind a position that
somehow our git-remote-https binary as distributed is a derived work of
OpenSSL and thus violates the GPLv2 license based on the nature of this
specific dependency chain, but then I was always dubious of the legal
merits of FSF's extremely aggressive and maximalist position on the
definition of derived works in the context of the GPLv2 license. I am not
a lawyer, this is not legal advice, and it's worth what you paid for it.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
