Re: Bacula and OpenSSL (original) (raw)

On Tue, Jul 24, 2007 at 05:10:32PM +0200, Shane M. Coughlan wrote:

Following comments on FSF's position regarding OpenSSL as a System Library in Debian, Brett Smith at FSF sent the following message:

=== I apologize for my misunderstandings about OpenSSL's status in Debian, and appreciate the corrections. However, even given all this information, I still don't see how OpenSSL meets part (a) of the System Library definition. What is the Major Component that OpenSSL accompanies? Kernels always come with C libraries, [...]

I don't think it's accurate to say that glibc is any more tightly bound to the Linux kernel than OpenSSL is -- you can certainly use different libc implementations to access the kernel, just as you could use different SSL implementations such as gnutls.

In particular, going by the GPLv3:

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

then libc can't treat the kernel as its Major Component because it's not "included in the normal form of packaging [that] Major Component".

That's somewhat fundamental technically, in so far as the kernel provides the hardware abstraction to a fairly static userspace/kernel ABI, and libc provides an implementation of the C (or POSIX or GNU) API based on the kernel's ABI.

Up to that point you can just call it "enabling use of the kernel (by people who can only speak C and POSIX)", but the problem then comes if, say, you choose to implement some C or POSIX API (such as POSIX threads) entirely in userspace rather than using the kernel's features, and to take things a step further, perhaps decide to package that separately. Your cases are then:

- libc implements pthreads as a thin layer over the kernel

- libc implements pthreads in userspace, with all pthreads looking
  like a single thread/process to the kernel

- libpthreads implements pthreads in userspace, with all pthreads
  looking like a single thread/process to the kernel, with libpthreads
  being a standard component of the operating system

- libpthreads implements pthreads in userspace, with all pthreads
  looking like a single thread/process to the kernel, with
  libpthreads being a optional and rarely installed component
  of the operating system

- libpkthreads implements pthreads as a thin layer over the kernel
  threads, but is an experimental implementation looking to
  replace libpthreads, that's optional and (currently) rarely
  installed

To me, the most natural line to draw when considering whether the pthreads implementation is a system library in the above is between the two libpthreads -- in the first three cases, how it's implemented is irrelevant, it's a standard library, implementing a standard API, that doesn't contaminate the GPLed software any more or less in any case, and is available to everyone who's going to use the GPLed software on the operating system in question.

For the latter two cases, there's no reason to consider the pthreads implementations particularly important parts of the operating system, so they shouldn't be considered system libraries no matter how thin or heavy-weight they are compared to the kernel.

If you're arguing that libc is only relevant in that it provides access to the kernel, I think you end up with the wrong answer in a few levels:

- libc doesn't provide access to the kernel; it uses the kernel to
  provide a C API; printf() isn't a kernel call, eg, it's something
  native to libc

- the clause becomes implementation dependent: if you implement
  something in the kernel, and provide it via libc it's can
  be used by GPLv3 programs, but if you implement it in libc,
  it's only accessible if it's an "official standard"

- it becomes packaging dependent: if you implement an official
  standard in libc, that's okay, but if you implement it in a
  package of its own, that's not

To take a more direct situation: under that interpretation, if you take glibc, implement a new, non-standard feature along the lines of obstacks, say, in glibc -- perhaps a rewrite of talloc -- and only make your new version of glibc available under the GPLv2. Then, even if that's included as a standard part of all Debian or Hurd or OpenSolaris installs, it's no longer possible to compile GPLv3 apps against that library, because the argument becomes:

myglibc (prospective System Library) is included in the normal form
of packaging the kernel (a Major Component), but is not part of
the kernel, and serves to enable use of the work with the kernel
and to implement the POSIX API (a Standard Interface for which an
implementation is available in source code form) _BUT_ in addition
to those things provides a non-standard feature of its own.

Thus myglibc is not a System Library, and cannot avail itself
of the System Library exclusion as Corresponding Source, so in
order to distribute a GPLv3 executable linked against myglibc,
myglibc is included in the Corresponding Source, and thus must be
conveyed in machine-readable form under the terms of the GPLv3,
which is not permitted as myglibc is only available under GPLv2.

As such the GPLv3 binary can't be distributed, QED

I suspect glibc as it currently stands probably fails the System Library definition under that interpretation thanks to neat, non-standard, userspace features like obstacks, though since it's under the LGPLv2.1 which allows relicensing under the GPLv3 anyway, that's not an issue.

I'd be surprised if OpenSolaris libc didn't include some similar features that would likewise make it fail that inerpretation of the System Library exception, which would then be a problem both for third party distributors of GPLv3 apps for OpenSolaris, and for groups such as the FSF that are promoting copyright infringement by claiming that binaries of third-party GPLv3 apps (such as Samba) built for OpenSolaris are distributable.

I suspect there's a good chance that also causes problems for GPLv3 apps built for Windows or OS X -- though it depends on implementation and packaging and I'm not sufficiently familiar with it to say.

and GCC always comes with libgcc.

libgcc doesn't always comes with gcc, however. In comparison, glibc always comes with the kernel, but the kernel doesn't always come with glibc. I don't think that really ends up meaning a lot.

What package comes with OpenSSL?

The only interpretation of the System Library exception that makes sense to me is (as per [0]) to treat "OpenSSL" as the Major Component of the operating system, and the System Library to be the headers that get incorporated directly into the binary, and working on the assumption that the libssl.so that's used at compile time is not actually needed for compilation in the strictest sense, and thus isn't part of the Corresponding Source.

[0] http://lists.debian.org/debian-legal/2007/07/msg00076.html

However, to answer the question directly, libssl-dev "comes with" libssl0.9.8, and serves only to provide (source-level) access to that component of the core Debian operating system. (libssl-dev includes the man pages, the header files, the libssl.so symlink, the libssl.a for static linking, and the pkgconfig files)

I understand that there are some pretty important applications that require OpenSSL, such as apt, but that's not the same thing as accompanying apt.

apt doesn't require OpenSSL. OpenSSL does accompany apt, by the dictionary definition of "accompanying", however:

 1. To go with or attend as a companion or associate; to keep
    company with; to go along with; -- followed by with or by;
    as, he accompanied his speech with a bow.
    [1913 Webster]

They're included in the same archive, at the same priority. In fact, OpenSSL accompanies apt in a slightly stronger sense than glibc accompanies the kernel -- given our kernel packages are lower priority and installed via a separate mechanism to glibc, apt and libssl.

That's only relevant in defining OpenSSL as a Major Component though.

Moreover, "pretty important" isn't the same thing as "essential" in the very narrow sense the license aims to define it in.

That's fine, but the "pretty important" is only useful as understatement; given the examples in the GPLv3, OpenSSL is essential in the sense the license defines it, and is in fact more essential than some of the examples.

To clarify: having free reign to link GPLv3 stuff against OpenSSL isn't really the issue here, it's understanding the System Library exception so that we know how to apply it.

As far as I can see, OpenSSL clearly needs to come under the exception in Debian if anything will; and if nothing does, the redrafting of the exception has failed in its apparent aims which is a bit disappointing, and we're going to have some significant problems dealing with GPLv3 apps that link to anything non-GPLv3 compatible (including GPLv2 stuff) which will be a real pain.

We could just refer all requests to make use of the system library exception to the FSF, but we'd definitely prefer to have a consistent understanding of the clause overselves that we can apply directly. I'm really hoping we can find such an understanding that matches the goals and interpretation of the FSF -- I really don't want to have to deal with the possibility of the FSF and Debian ending up with competing interpretations of the GPL; but I suspect not being able to apply the system library exception would be even worse.

I hope that helps explain where I'm coming from here. The dialogue's sincerely appreciated.

Cheers, aj

Attachment:signature.asc
Description: Digital signature

Reply to: