The GPLv2 and GPLv3 both include a requirement of the form: "You may not impose any further restrictions ..." (GPLv2 Section 6 - GPLv3 Section 10), 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 (such as that of the widely-used OpenSSL license) due to it's "obnoxious" advertising clause. \footnotemark[1] \footnotemark[2] \footnotemark[3] \footnotemark[4]  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 exempted by the GPL "System Library Exception" (GPLv2 Section 3 - GPLv3 Section 1) and whether or not the LGPL can be used as a remedy. \footnotemark[5]  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 ...". \footnotemark[6] 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. ...". \footnotemark[7]  Well, if you are reading this (and of course, you are), that makes at least three people.

  \item 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.

  \item Debian has taken the opposite stance that OpenSSL is non-essential and therefore not exempted by the GPL "System Library Exception"; and has generally recommended that upstreams of GPL'ed programs add an exception for OpenSSL to their licenses. \footnotemark[15]  As an example of an LGPL'ed library, Debian distributes the libircclient binary package with OpenSSL linkage disabled. \footnotemark[16]  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. \footnotemark[17]

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

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 exempted by the GPL "System Library Exception"?  They are, above all, the authority on the matter, aren't they?}

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?}

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?}

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.}

}

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.} \footnotemark[30]

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, so it is probably noteworthy of contrasting this to the preceding concern (RFC-5). \footnotemark[5]  Otherwise, 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.}

    \begin{quote}

?

    \end{quote}}

  \item{\bf{[RFC-7]\newline

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?}

    \begin{quote}

?

    \end{quote}}

  \item{\bf{[RFC-8]\newline

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"."?}

    \begin{quote}

?

    \end{quote}}

  \item{\bf{[RFC-9]\newline

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 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".