Re: Bacula and OpenSSL
On Thu, Jul 19, 2007 at 04:22:06PM +0200, Shane M. Coughlan wrote:
> Steve Langasek wrote:
> > I agree that the GPLv3 is not "compatible" with the OpenSSL license, in the
> > sense that code licensed under the OpenSSL license cannot be included in a
> > GPLv3 work. However, the GPLv3 does include a broader (if no more easily
> > understood) system exception clause, which seems to allow distributing GPLv3
> > binaries that are /dynamically linked/ against OpenSSL. Is this not the
> > position of FSF/FSF Europe?
> I discussed this issue with Brett Smith of FSF, and as a result of this
> he wrote the following brief summary:
> We do not believe that OpenSSL qualifies as a System Library in Debian.
> The System Library definition is meant to be read narrowly, including
> only code that accompanies genuinely fundamental components of the
> system. I don't see anything to suggest that that's the case for
> OpenSSL in Debian: the package only has important priority (as opposed
> to glibc's required), there are only about 350 packages depending on it
> (as opposed to glibc's 8500), and it isn't installed on a base system.
> To put it plainly, if OpenSSL actually were a System Library, I would
> expect it to look more like one.
> - -- Brett Smith Licensing Compliance Engineer, Free Software Foundation
IMHO that would be a rather unfortunate position for the FSF to take, as it
would mean the changes to the system exception clause are *only* of benefit
to distributors of proprietary operating systems, while GNU/Linux
distributors are left with the same license compatibility problems as ever.
But as AJ noted, the above analysis seems to get some facts wrong. In
addition to the fact that OpenSSL is part of the base system, the count of
reverse-dependencies seems to be off somewhat. There are 461 packages in
etch that depend on libssl0.9.8, plus another 11 depending on the
libssl0.9.7 that we aren't quite rid of. Of course that's nothing close to
glibc's 8500, but if we were to look at some of the individual libraries
within the libc6 package, like librt, libnsl, libm, or libdl, I would expect
that openssl's usage within Debian is at least within an order of magnitude
of some of these. Surely if libraries such as these qualify as System
Libraries (and I should hope they do!), shouldn't libssl qualify too?
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.