Latest upstream release: 1.3.2
Current version/release in Fedora Rawhide: 1.3.1-14.fc20
URL: https://github.com/xelerance/xl2tpd/tags

Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Latest upstream release: 1.3.3
Current version/release in Fedora Rawhide: 1.3.1-14.fc20
URL: https://github.com/xelerance/xl2tpd/tags

Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

CC:ing fe-legal on this bug:


There is an interesting change in license of xl2tpd 1.3.3:

https://github.com/xelerance/xl2tpd/commit/f039398af5d97921ade559c0e6d5b11a818ddff5

+Special exception for linking xl2tpd with OpenSSL:
+
+  In addition, as a special exception, Xelerance Corporation gives
+  permission to link the code of this program with the OpenSSL
+  library (or with modified versions of OpenSSL that use the same
+  license as OpenSSL), and distribute linked combinations including
+  the two. You must obey the GNU General Public License in all
+  respects for all of the code used other than OpenSSL. If you modify
+  this file, you may extend this exception to your version of the
+  file, but you are not obligated to do so. If you do not wish to
+  do so, delete this exception statement from your version.

However, I worked at Xelerance, when we forked Mark Spencer's l2tpd code which is licensed under GPLv2+. There are also significant contributions made by other people under the GPL. I am not aware of authors having been contacted about this change of license. Neither I nor Tuomo Soini have been contacted.

This change was done when they merged in one of my FIPS patches from the fedora branch that removed native md5 code to use openssl's md5 code to ensure FIPS compliance. This might have caused a license problem by mixing GPL and the openssl license?

Should I change the code in fedora to use nss instead of openssl?

Am I correct in that we should not ship version 1.3.3 if we know this license change is dubious at best?

Eh, we don't use the openssl exception, so its not a Fedora blocker (we'd just no-op it away), because we consider openssl to be a system library.

You should definitely talk to the upstream about the inappropriateness of changing the license without clearing it through all the copyright holders (assuming you didn't assign your copyright in that work to them). The change they made is reasonably non-controversial (its the standard FSF openssl exception), but still.

Closing this as NOTABUG.