Using the GPL with OpenSSL/BSD-4-clause

From LibrePlanet
Jump to: navigation, search


NOTE: This is a draft. It may contain errors. Please do correct any errors you find.

This article assumes that the reader is somewhat familiar with this issue. If not, a good overview by Mark McLoughlin can be read on the Gnome website. [1] The aim of this article is to clarify common misconceptions, to consolidate the most informative references, and to offer guidance for developers, project maintainers, and packagers regarding this issue.

Motivation

The GPLv2 and GPLv3 both include a requirement of the form: "You may not impose any further restrictions ..." (GPLv2 Section 6 - GPLv3 Section 10) [2][3] which the FSF (author and publisher of the GPL family of licenses) contends is in conflict generally with all licenses of the original "4-clause BSD" form [4] (such as that of the widely-used OpenSSL license [5]) due to it's "obnoxious" advertising clause. Not surprisingly, it seems to be the general consensus among free software developers that any program or library which itself links to the OpenSSL library is incompatible with the GPLs; but there is some controversy as to whether or not the OpenSSL library is protected by the GPL "System Library Exception" (GPLv2 Section 3 - GPLv3 Section 1) and whether or not the LGPL can be used as a remedy. [6] Notions have been expressed from general apathy as "... In reality, GPL/OpenSSL linking is tolerated because few upstream GPL project developers care about the issue ...". [7] to frustration "... this [is] totally non-productive nonsense. Seriously, how many people actually care whether some GPL code links with OpenSSL? My guess is two: RMS and EM. ...". [8] Well, if you are reading this (and of course, you are), that makes at least three people.

These differences in opinion are manifest most plainly in the package repositories of various GNU/Linux distributions; with distros representing both sides of the debate. As such, there are possibly hundreds of packages in the repos of major distros currently installing programs with GPL-family licenses that link to OpenSSL (or other libraries with similar licensing terms). Some distros have chosen to offer custom versions of these libraries that either replace OpenSSL with a compatible library (such as GnuTLS or Mozilla NSS) or strip out the functionality that requires such libraries. Some have chosen not to carry these libraries at all.

One thing that everyone should agree upon is that in order for licensing terms to be valid, they must not be subject to interpretation; so it must be the case that only one interpretation is defensible. Therefore, it must be true either that distros that distribute OpenSSL-enabled forms of the conflicting libraries are violating the GPL or that the other distros are expending precious resources or limiting their packaging selection unnecessarily in order to avoid the perceived conflict. The resolution to this debate would seem to hinge most strongly upon whether or not the FSF considers OpenSSL to be an essential "System Library" and if there is a precise notion of "System Library" that applies universally across all GNU/Linux systems or if a particular library such as OpenSSL can be essential on some distro but not others. After all, in terms of core system components, most of systemd is essential on some systems with none of it's components present on others; and one certainly could not claim that any of systemd is essential on a Windows system. Unfortunately, there is little authoritative information to be found regarding this nor examples of how this has been handled in the past; and one must muddle through megabytes of lawyer-speak in order to parse most of what is accessible and reach a conclusion on their own.

The OpenSSL library is focused upon here only because it is perhaps the most widely used library that induces this dilemma; but this article applies generally to any library with a license of the original "4-clause BSD" form. One particular library (libircclient) is mentioned because it exemplifies a particular corner-case that should be highlighted. It is an LGPLv3+ licensed library that is capable of linking to OpenSSL, but only if the user specifies an enabling switch to the ./configure script; otherwise it will not link to OpenSSL. [9] This is a fairly common practice; but it is unclear whether or not such a switch is permitted by the LGPLv3 and whether or not the resulting binaries (even without OpenSSL support) are themselves legitimate. In other words, does the licensing conflict exist before compile-time or does the conflict arise only at the moment the actual linkage occurs?


The Facts

The following bullet points constitute the entire body of unambiguous facts on this topic resulting from research to date:

  • This issue has haunted the free software community for a very long time.
  • BSD removed this clause from it's license in 1999; but licenses retaining an analagous clause are still prevalent today, notably OpenSSL License of the OpenSSL library.
  • The GNU license compatibility list categorizes both the Original BSD (4-clause) License and the OpenSSL License as "GPL-Incompatible Free Software Licenses". [10][11]
  • The LGPLv3 does not itself contain the same wording such as that in the which constitutes the conflict; but it does clearly state that it's terms are supplemental extensions to the GPLv3. [12]
  • FedoraProject considers OpenSSL to be a "System Library" and so exempt from conflict per the "System Library Exception". [13] Fedora distributes the libircclient binary package with OpenSSL linkage enabled as do third-party RPM repos. [14][15]
  • Debian has taken the opposite stance that OpenSSL is non-essential and therefore not protected by the GPL "System Library Exception"; and has generally recommended that upstreams of GPL'ed programs add an exception for OpenSSL to their licenses. [16] As an example of an LGPL'ed library, Debian distributes the libircclient binary package with OpenSSL linkage disabled. [17] Debian even goes so far as to track and post on its website all such potential license collisions detected by it's automated Lintian package sanity checker and the final acceptance decisions. [18]
  • Several other distros distribute libircclient binaries but no clear statements on this matter have yet to be found from these. The libircclient packages in ArchLinux (also AUR), Gentoo, and OpenSuse have OpenSSL linkage enabled so presumably they are either unaware of the issue or are in the Fedora camp. [19][20][21][22] The libircclient package in Ubuntu does not have OpenSSL linkage enabled so they are presumably following Debian's lead. [23]
  • The OpenSSL FAQs interpret the scope of the "System Library Exception" maximally, stating "... the GPL does not place restrictions on using libraries that are part of the normal operating system distribution ...". [24]
  • The most definitive reference yet found as to the official FSF opinion of whether OpenSSL qualifies for the "System Library Exception" is a post to the debian-legal mailing list by Shane Coughlan of the FSFE who quoted Brett Smith of the FSF as saying, "... We do not believe that OpenSSL qualifies as a System Library in Debian. ..." which is based on the comparatively small number of reverse-dependencies for an essential system library and the fact that "... it isn't installed on a base system. ...". [25] Clearly though, this leaves open the possibility (however dubious) that it could be considered otherwise depending on the distribution; so it would be interesting to apply this measure against the distros that do take that position.
  • A broad interpretation of the "System Library Exception" can be found in the "Software Freedom Law Center Guide to GPL Compliance 2nd Edition" stating that "... the intention of the “System Library exception” is to avoid the need for production of source code which the user can expect to receive with the copy of the operating system ...". [26]
  • On 2015-08-01 OpenSSL announced plans to re-license as Apache-2.0 which is compatible with the GPLv3; but there has since been no news regarding this at the time of this writing (2016-11-02). [27]
  • On 2016-10-31 Rich Salz, representing OpenSSL, announced their latest road-map which made no mention of re-licensing; so a reader asked if there was any progress in this direction. This was the response: [28] 
   Rich Salz 2016-11-01
   "We are still working on it.  Nothing to report.  Unlike public code development,
        this will mostly be a quiet behind the scenes venture."
  • Perhaps a counter-fact, but the "Software Freedom Law Center Guide to GPL Compliance 2nd Edition" says of the GPLv3 Section 7(d): "... The long-standing and occasionally troublesome incompatibility with the “BSD advertising clause” is an example of the friction removed by this provision. ...". [26] If that is to be taken literally ('removed', not 'eased'), then this article can perhaps shrink substantially.
  • Currently, the simplest remedies are either to add a "Linking Exception" to the license header of each source file of the main program or to re-licence the entire project permissively. [29] The caveat is that all copyright holders must agree to this. If it is not feasible to do so, then perhaps a replacement library can be found. In the case of OpenSSL several such replacements exist for it's various functions such as GnuTLS, Mozilla NSS, and Nettle.


Frequently Asked Questions

Should I inform the developer(s) that their library violates the GPL? Should this be done privately via email or on the project's public forum?

?

Should I ask the distro packager(s) to stop distributing the offending library?

?

What if the developer(s) or packager(s) refuse or do not respond?

The SFLC offers a form letter for engaging upstreams in "A Legal Issues Primer for Open Source and Free Software Projects" and recommends that they or other legal counsel be contacted if the issue can not be resolved in a timely manner. [30])

If I have a GPL program which links to a library such as libircclient which is capable (but only as a compile-time option) of linking to OpenSSL, can I simply drop support for distros that enable this option and target only those who choose not to; or should I inform any distros that the such libraries violate the GPL whether they link it to OpenSSL or not?

?

Should I not care at all about this? Does the FSF care at all about this? Maybe, I can find a replacement library and forget about it.

?

If I have a GPL'ed program which has as a dependency some (otherwise compatible) library that itself links to OpenSSL, does this taint my GPL?

?

Should I myself cease distributing my program and request that packagers cease packaging it until the conflict is resolved (e.g. by re-licensing my project, replacing the library, or waiting until OpenSSL re-licenses)?

?


Interpretation and Caveats

The following are among the most opaque but pragmatic points to be underlined as it concerns project maintainers and packagers:

RFC-1

Does the FSF concur with the FedoraProject that OpenSSL is a "System Library" exempted per the GPL "System Library Exception"; or does the FSF concur with Debian that OpenSSL is non-essential and not protected by the GPL "System Library Exception"? They are, above all, the authority on the matter, aren't they?

If Shane Coughlan's account or Brett Smith's statement is accurate, then the FSF does not consider OpenSSL to be an essential "System Library" and so does not qualify for the GPL "System Library Exception" (at least not on a Debian system). No such statements have been found regarding other distros however.

RFC-2

Would the FSF prefer to be the authority on what qualifies as a "System Library" exempted per the GPL "System Library Exception"; or would the FSF prefer to delegate this to each distro, providing that they do so formally as a matter of published policy?}

RFC-3

How feasilbe would it be for the FSF to maintain a white-list of "Essential Core System Libraries" in order to remove any doubt. After all, leaving any such caveat as subject to interpretation is practically the same as omission - is it not?

RFC-4

Can a GPLv2 or GPLv3 main program (with or without an explicit linking exception) link itself to a library licensed under the corresponding LGPL version that, in turn, links itself to OpenSSL, or any other library, regardless of the license of latter sub-dependency? If not, may the LGPLv2 or LGPLv3 library provide a "Linking Exception" to explicitly permit this. All of the language in the LGPLv3 speaks in terms of a GPL-incompatible main program's ability to link itself to LGPL'ed libraries; but says nothing of linkage in the other direction (e.g. an LGPL'ed library that itself requires a proprietary or otherwise incompatibly licensed helper). This is a point of confusion for many people.

RFC-5

If the answer to RFC-4 is negatory, that is, it is in no way possible for an LGPL'ed library to, itself, require a proprietary or otherwise incompatibly licensed helper legitimately, then can it be made compliant by disabling that feature as the default behavior and requiring the user to enable it with a compile-time switch? In other words, does the licensing conflict exist simply because the code is capable of producing a binary that may, at the user's option, link to an incompatibly licensed library; or does the conflict not arise until compile-time or runtime, such that anyone can distribute the source code and the end user is free to compile with the switch enabled as long as they do not distribute the resulting binary? Only one instance of someone raising this specific concern of a compile-time switch has been found; but the concern was not addressed. [31]

RFC-6

Conversely, if the answer to RFC-4 is affirmative, that is, it is indeed possible for an LGPL'ed library to itself require a proprietary or otherwise incompatibly licensed helper library as a sub-dependency, then does this taint the license of any main GPL'ed client program, such that it must, itself, re-license to the same LGPL version as the intermediate library (or more permissively) in order to use it (and the incompatibly licensed sub-dependency by proxy)? This case is presumably fallacious but some people do believe this is a valid option [6], so it is probably noteworthy of contrasting this to the preceding concern (RFC-5). Otherwose, if this is permissible, then one can easily imagine a plethora of LGPL'ed libraries which are nothing more than thin wrappers around GPL-incompatible libraries. Indeed, one can imagine a project devoted to consolidating such wrappers and/or a website devoted to indexing them. It would be quite ironic to see such a wrapper indexed on the FSF Free Software Directory.

RFC-7

If the answer to RFC-4 is affirmative, then what does this imply for any GPLv3 program that links itself to such a library? Could one add a "Linking Exception" to the license of the main program allowing it's dependency to link to OpenSSL as a sub-dependency (even if the dependency does not provide such an exception)? If the dependency already provides such an exception, then must the main program also provide the same exception?

RFC-8

Instead of a "Linking Exception", could one state a disclaimer such as: "You may not run this program on any distro that links this program's dependencies to OpenSSL unless you compile those dependencies yourself with OpenSSL disabled and link this program to those instead."? Could one further add something like, "... unless your distro has a public policy declaring OpenSSL to be an essential "System Library" on their distro and so exempted by the GPL "System Library Exception"."?

RFC-9

An important caveat regarding the definition of “Corresponding Source” in GPLv3 Section 1 is that it requires that the source can be compiled as to "... run the object code ..." but makes no accommodations nor constraints on any particular operating environment in which it must be able to run. Presumably, it is not the intention that all GPL-licensed software must be executable on all architectures and operating systems. So, it would follow that project maintainers are free to support only certain operating environments; and it can be easily argued based on dependency trees alone that Fedora and Debian (for example) are different operating environments; and so project maintainers should be free to support only certain distros and not necessarily all distros. Otherwise, if the distribution requirements in GPLv3 Section 6d and the “Corresponding Source” definition are interpreted too stringently, the overall requirement would be that all GPL-licensed software projects must themselves distribute cross-platform source code for all dependencies (and sub-dependencies) in the dependency chain all the way down to the vaguely defined "System Libraries" allowing "The Program" to compile on any all operating systems and distros past, present, and future. That is presumably not the intention and would likely lead to everyone distributing nothing but docker images. If project maintainers are indeed free to selectively support only certain environments, then the GPL "System Library Exception" along with GPLv3 Sections 6d and 6e would seem to allow some isolation from this sort of licensing conflict as long the following conditions are met:

  1. The Program must be licensed with a version of the GPL that allows third parties to distribute sources for dependencies of The Program (this is currently only the GPLv3)
  2. If the potentially conflicting dependency is LGPLv3 licensed, then the project maintainer of The Program must comply with the LGPL "Combined Works" section of the dependency's license (LGPLv3 Section 4) opting to "... Use a suitable shared library mechanism for linking with the Library ... already present on the user's computer system ..." (LGPLv3 Section 4d1) [12]
  3. The end user's distro includes the potentially conflicting dependencies in it's base distribution media; or a "... third-party ..." (such as the user's distro) distributes them "... on a different server ..." than The Program "... for as long as needed ..." (which the GPL FAQs clarify to be "... as long as you distribute the object code ...") [32]
  4. The project maintainer insists that end users obtain the dependencies themselves through their package manager but only if their distro hosts all of the dependencies in a form that does not conflict with the license of The Program
  5. At least one such known distro is designated as "supported" by The Program
  6. The project maintainer insists that end users of distros hosting The Program's dependencies in a form that conflicts with the it's license and end users of distros that do not host The Program's dependencies are not to expect a usable result (any more of than a Windows user could expect while compiling systemd in VisualStudio. If such users can not obtain the source code for the dependencies somehow and compile themselves in a way that does not conflict with the license of The Program; they are still free to install a supported distro or run one in a VM to use The Program legitimately. How could it be argued that such users are being deprived of their freedom in this way?
  7. If the day ever arrives that no distro that is designated as supported by The Program any longer hosts compatible versions of the tainted dependencies then The Program's maintainer would be obliged only to cease to "... distribute the object code ..." per GPLv3 Section 6d

In this way the responsibility of resolving dependency and licensing compatibility conflicts is delegated to distro packagers and package management software which exist precisely for that purpose. Note, that this is all assuming that the binary dependency with the previously mentioned conflict-enabling compile-time switch is not itself inherently illegitimate (per the previous RFC-5); but is GPLv3-compatible if the switch is not activated. Also, this proposal depends on a loose but reasonable interpretation of “Corresponding Source” which is defined somewhat inconsistently to include "... the source code for shared libraries and dynamically linked subprograms ..." but to exclude "... generally available free programs which are used unmodified ...". It can be easily argued that shared binary libraries are both "generally available" and "used unmodified".


User Feedback

---


( ... add your feedback here ... )


References


[1] https://people.gnome.org/~markmc/openssl-and-the-gpl.html
[2] https://www.gnu.org/licenses/old-licenses/gpl-2.0.html
[3] https://www.gnu.org/licenses/gpl.html
[4] https://spdx.org/licenses/BSD-4-Clause
[5] https://www.openssl.org/source/license.txt
[6] https://github.com/JulyIGHOR/QtBitcoinTrader/issues/27#issuecomment-32726728
[7] http://www.lawseminars.com/materials/08OPSMA/opsma%20m%20fontana%2010-29%20new%20up.pdf (slide #10)
[8] https://lists.debian.org/debian-legal/2005/06/msg00033.html
[9] http://www.ulduzsoft.com/libircclient/index.html#required-libraries
[10] https://www.gnu.org/licenses/license-list.html#OriginalBSD
[11] https://www.gnu.org/licenses/license-list.html#OpenSSL
[12] https://www.gnu.org/licenses/lgpl.html
[13] https://fedoraproject.org/wiki/Licensing:FAQ?rd=Licensing/FAQ#What.27s_the_deal_with_the_OpenSSL_license.3F
[14] http://koji.fedoraproject.org/koji/rpminfo?rpmID=8042289
[15] http://rpmfind.net/linux/RPM/fedora/24/x86_64/l/libircclient-1.8-6.fc24.x86_64.html
[16] https://lists.debian.org/debian-legal/2004/05/msg00595.html
[17] https://packages.debian.org/jessie/libircclient1
[18] https://lintian.debian.org/tags/possible-gpl-code-linked-with-openssl.html
[19] https://www.archlinux.org/packages/community/x86_64/libircclient/
[20] https://aur.archlinux.org/packages/libircclient-openssl-ipv6/
[21] https://packages.gentoo.org/packages/net-libs/libircclient
[22] https://build.opensuse.org/package/view_file/devel:libraries:c_c++/libircclient/libircclient.spec?expand=1
[23] http://packages.ubuntu.com/xenial/libircclient1
[24] https://www.openssl.org/docs/faq.html#LEGAL2
[25] https://lists.debian.org/debian-legal/2007/07/msg00194.html
[26] https://www.softwarefreedom.org/resources/2014/SFLC-Guide_to_GPL_Compliance_2d_ed.html#gplv3
[27] https://www.openssl.org/blog/blog/2015/08/01/cla/
[28] https://www.openssl.org/blog/blog/2016/10/24/f2f-roadmap/
[29] https://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs
[30] http://www.softwarefreedom.org/resources/2008/foss-primer.html#x1-170002.5.4
[31] https://lists.debian.org/debian-legal/2005/09/msg00024.html
[32] https://www.gnu.org/licenses/gpl-faq.html#SourceAndBinaryOnDifferentSites

NOTES:

  • regarding link #6 - the project maintainer refused the initial patch (relicensing to LGPL) and chose to add an exception for OpenSSL to it's existing GPLv3
Retrieved from "https://libreplanet.org/wiki?title=Using_the_GPL_with_OpenSSL/BSD-4-clause&oldid=41240"