openssl as a system library

[Colin Watson]

On Wed, May 01, 2013 at 11:25:17AM +0100, Dave Walker wrote:
> I would like openssl to be considered a system library in Ubuntu.  As
> a developer, it seems very clear to me that it is essentially treated
> as such with it's penetration in packages probably as common as other
> shared libraries.

The key phrase in the GPL (at least v2) is "unless that component itself
accompanies the executable".  Debian and Fedora (to take two examples)
have historically disagreed about the interpretation of this phrase.
The Debian position is explained in
http://lists.debian.org/debian-legal/2002/10/msg00113.html, and in this
case boils down to "if we're shipping both mongodb and openssl, Debian
is a single OS and that constitutes the component accompanying the
executable".

I'm afraid I agree with Debian's position on this and disagree with
Fedora's, and would similarly require for Ubuntu that any GPLed package
linking against OpenSSL contain an explicit exception sufficiently
general to apply to both us and to people who make derivative works
based on our package or who mirror our package.  If the upstream thinks
that it does not infringe upon their particular requirements to use
OpenSSL then in general we ought to be able to extract such an exception
from them, while if they do think that it's an infringement then we
shouldn't be shipping it that way anyway.

A further reason beyond Steve's explanation in the linked mail why I am
wary of ever attempting to use the system library exception for
libraries shipped as part of Ubuntu is that I think it's a subversion of
the original intent of that clause of the GPL.  My understanding is that
the original reason that clause is there was to permit distributing
GPLed executables for non-free operating systems where for instance the
C library was not available under a GPL-compatible licence; the
bootstrapping problem there is obvious and it makes sense for the GPL to
have provision for that case.  The GPL FAQ gives a modern example of
distributing a binary linked against the Windows Visual C++ runtime
library, and says (for GPLv2, I think) "To prevent unscrupulous
distributors from trying to use the System Library exception as a
loophole, the GPL says that libraries can only qualify as System
Libraries as long as they're not distributed with the program itself".

Now, MongoDB appears to be AGPLv3, and the GPLv3 is a bit more specific
here.  It's thus worth a little reanalysis based on the text of the
GPLv3.  Here it is:

    A "Standard Interface" means an interface that either is an official
  standard defined by a recognized standards body, or, in the case of
  interfaces specified for a particular programming language, one that
  is widely used among developers working in that language.
  
    The "System Libraries" of an executable work include anything, other
  than the work as a whole, that (a) is included in the normal form of
  packaging a Major Component, but which is not part of that Major
  Component, and (b) serves only to enable use of the work with that
  Major Component, or to implement a Standard Interface for which an
  implementation is available to the public in source code form.  A
  "Major Component", in this context, means a major essential component
  (kernel, window system, and so on) of the specific operating system
  (if any) on which the executable work runs, or a compiler used to
  produce the work, or an object code interpreter used to run it.
  
    The "Corresponding Source" for a work in object code form means all
  the source code needed to generate, install, and (for an executable
  work) run the object code and to modify the work, including scripts to
  control those activities.  However, it does not include the work's
  System Libraries, or general-purpose tools or generally available free
  programs which are used unmodified in performing those activities but
  which are not part of the work.  For example, Corresponding Source
  includes interface definition files associated with source files for
  the work, and the source code for shared libraries and dynamically
  linked subprograms that the work is specifically designed to require,
  such as by intimate data communication or control flow between those
  subprograms and other parts of the work.

Now, first, we must consider whether it is possible to regard OpenSSL as
a System Library here.  I am not entirely sure I understand the
qualification in (a), but I think that it's trying to talk about glue
libraries that you need to make use of system facilities: for example,
in this model libc is merely a library that enables use of the work with
the system's kernel.  But, in any case, if we only consider (b) (which
we can do since it's "and"), OpenSSL does not merely serve to enable use
of a work with anything (it provides significant facilities itself), and
it does not implement a Standard Interface in any reading I can make of
that term (this is usually interpreted to mean "if the GPL-incompatible
library is just one choice of many that plug into the same generic slot,
then it doesn't matter" - but the problem at hand here only arises
because it hasn't been made to work with GnuTLS!).

Secondly, we need to consider whether OpenSSL meets the requirements of
"general-purpose tools or generally available free programs which are
used unmodified in performing those activities but which are not part of
the work".  The example that follows appears to suggest that this is for
things you use using narrow arm's-length interfaces, for example forking
sed and reading its output, and it specifically calls out "shared
libraries ... that the work is specifically designed to require" as
cases that still fall under Corresponding Source.  Again, if MongoDB
were not specifically designed to require OpenSSL - if it were possible
to plug in something like GnuTLS - then we wouldn't be having this
discussion in the first place.

So I'm afraid that, while the reasoning does seem to differ for the
GPLv3, I think the general position still stands.  In fact, since it
isn't grounded in a dispute about whether two packages we ship
"accompany" each other, the argument seems if anything stronger for the
(A)GPLv3.

> One of the common bug and feature requests we get is squid to support
> SSL[0][1].  We know that a significant volume of openssl users, take
> the source package and make minimal modifications to rebuild it
> locally, with openssl support.  Judging from the bug reports, this
> also seems to affect ubuntu.com’s services that use SSL (ie, the
> Ubuntu packages are not even fit for Ubuntu infrastructure).

In this specific case, at least one squid upstream developer has
explicitly stated fairly recently that it's a violation to distribute
squid linked against OpenSSL, so I have an extremely hard time seeing
how we could possibly start doing so without a similarly explicit
statement of permission, regardless of any unilateral decision about how
we interpret the system library exception:

  http://www.squid-cache.org/mail-archive/squid-dev/201206/0075.html

Cheers,

-- 
Colin Watson                                       [cjwatson at ubuntu.com]