[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bacula and OpenSSL

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

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.


Attachment: signature.asc
Description: Digital signature

Reply to: