openssl as a system library

Wed May 1 15:35:35 UTC 2013

Colin Watson <cjwatson at ubuntu.com> wrote:

>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:

There is also GPLv2 code in the package which refers to SSL, so I think the GPLv2 analysis is relevant as well. I just did a quick grep of the code. I didn't look into the details. 

Scott K

>   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]
>
>-- 
>technical-board mailing list
>technical-board at lists.ubuntu.com
>https://lists.ubuntu.com/mailman/listinfo/technical-board