Control: tag -1 = help Re: Robie Basak 2019-03-20 <20190320142403.GE30970@mal.justgohome.co.uk> > > > It is well understood that the OpenSSL license is not "compatible" with > > > the GPL (either version 2 or 3); and furthermore, Debian has long taken > > > the position that, unless a license exception is granted by the > > > copyright holders, a package which is distributed under the GPL must > > > only link to libraries whose licenses are also GPL-compatible in order > > > for it to be included in Debian. > > > > How is that a problem in libpq5, and not in the other packages? > > libpq5 seemed like a reasonable place to file this bug in the first > instance. I don't intend to dictate how or where this must be resolved. > > To help put this into perpspective: > > There are 140 source packages that build a binary that depends on > libpq5. > > 84 of these mention GPL in debian/copyright, but apparently have no > linking exception (heuristically and not checked but this is hopefully > enough for an indication). PostgreSQL is BSD-licensed, so there is no problem in PostgreSQL itself. (We use libedit instead of libreadline in psql to avoid the libssl problem.) Also unlike the mariadb case, we have been shipping libpq linked against libssl for at least a decade, so there is no regression. Upstream is working on supporting alternate crypto providers, but that will not happen before PostgreSQL 13. What is less clear is if we have a giant problem now, or if we can get out of the situation by claiming that the reverse dependencies do not use libssl directly. Theoretically, we could ship a libpq5-nossl.deb which I believe would have the same symbol signature. Input from ftp-master, debian-release, and/or debian-legal on this is needed, I cannot say what to do with licensing terms in all those reverse-dependers. > Of these 84, based on my glance at their debian/copyright files > manually, and without deeper investigation: > > * 12[1] appear to be GPL-2 only, so are affected today and will > continue to be affected in the upcoming OpenSSL upstream > relicensing. > > * 27[2] look like they're GPL-2+, GPL-3 or GPL-3+, so are affected > today but can be expected to become compatible in the future with a > newer release of OpenSSL upstream. However this does not help for > buster. > > So that's at least approximately 39 of 140 reverse dependencies that > appear affected based on a quick glance through. I've been fairly > conservative in my superficial analysis - I skipped reverse dependencies > where I couldn't see any compatibility problem from a quick glance. > > [1] bandwidthd-pgsql dballe inspircd libnss-pgsql2 libodb-pgsql-2.4 > pmacct r-cran-rpostgresql saga sphinxsearch tora ulogd2-pgsql > yubikey-server-c > > [2] clisp cvm cyphesis-cpp gammu gnokii gnu-smalltalk gnunet grass > libpg-perl libpreludedb motion newlisp osm2pgrouting osm2pgsql pam-pgsql > libzdb perdition pgmodeler postgis pspp pvpgn qgis repmgr sqlsmith > sysbench w1retap zabbix Christoph
Attachment:
signature.asc
Description: PGP signature