Re: openssl as a system library
nterface 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!). I think another reading of "implement a Standard Interface" could describe the crypto communication side. The protocols OpenSSL implements are very public, so that seems to count. And even if not, since OpenSSL tends to be the cross-platform defacto standard for crypto communications, I would think "in the case of interfaces specified for a particular programming language, one that is widely used among developers working in that language." counts too. (See examples for OpenSSL in "Secure Programming Cookbook for C and C++", or how it is the recommended way to implement SSL in Wheeler's Secure Programs HOWTO: http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO.html#CRYPTO ) Additionally there is the note "is available to the public in source code form" for which OpenSSL certainly is again, which seems to follow my earlier assumption about wanting to make sure all source is available to the end user. > 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. Well, since I still consider it a system library, this isn't something that needs to be considered. But if I did, I think this isn't really a concern since the source for OpenSSL IS available. > So I'm afraid that, while the reasoning does
Re: openssl as a system library
On Wednesday, May 01, 2013 03:28:31 PM Colin Watson 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: > > 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
Re: openssl as a system library
Colin Watson 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 conside
Re: openssl as a system library
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
openssl as a system library
Hi, 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. I would suggest that an openssl derived libssl.so being included in the default Launchpad buildd chroots substantiates this, along with other core libraries. In addition, I do not believe any Ubuntu media avoids installing openssl by default. 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). I believe this to be both a usability and potentially more importantly, a security issue as a large volume of users are being compelled to use custom packages that does not benefit from the Main archive security support it normally would. An upstream exception has been sought, but due to lack of centralised copyright handling - it has not been viable to get all the copyright holders in agreement. Additionally, work to support gnutls could also be invested - This is making some progress, but has been slow. As Ubuntu’s primary intention is to be a distribution, we have not been able to justify resources to work on this. We are now seeing a similar issue with mongodb, and would ask for clarification that openssl is considered a “system library”, and therefore allow openssl support by-default, in packages that can make use of it. This would seem to be in the best interest of users. This being said, as good Free Software advocates - I would like to stipulate that every effort should be made to draw upstream copyright holders to granting an OpenSSL exception, and this is a pragmatic direction, whilst being faithful to Ubuntu’s free software commitments. I would like to draw contrast with other Linux distributions that consider such matters. One is distribution Fedora, where they seem to specifically outline that they consider openssl to be a system library[2]. [0] https://bugs.launchpad.net/ubuntu/+source/squid/+bug/16669 [1] https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1088971 [2] https://fedoraproject.org/wiki/Licensing:FAQ?rd=Licensing/FAQ#What.27s_the_deal_with_the_OpenSSL_license.3F Thanks. -- Kind Regards, Dave Walker Engineering Manager, Ubuntu Server -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
