Colin Watson <cjwat...@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 >[cjwat...@ubuntu.com] > >-- >technical-board mailing list >technical-board@lists.ubuntu.com >https://lists.ubuntu.com/mailman/listinfo/technical-board -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
