Bacula: GPL and OpenSSL

Hi legal folks,

Kern Sibbald, author of Bacula, contacted me today regarding its
license.

Some years ago, Jose Luis Tallon -- then the maintainer of Bacula --
asked Kern to add a clause to the Bacula license that would explicitly
permit linking with OpenSSL. Kern did. Kern also subsequently assigned
copyright to FSF Europe (FSFE).

Recently, Fedora developers noticed that there were a few files in the
Bacula source tree that were not copyrighted by Kern or FSFE. Since
Kern did not have written permission from these developers to relicense
Bacula with the OpenSSL exemption, Fedora believed the license as
written was problematic.

Kern approached me about this situation (see full correspondence below,
forwarded with his permission). He added that Bacula does not
statically link with OpenSSL, that OpenSSL support can be disabled at
build time, and that FSFE does not believe that an exception clause to
the GPL is necessary to legally link to OpenSSL in the manner that
Bacula is (dynamic linking). Further, could we not consider OpenSSL to
be a major component of the OS on which the executable runs, and thus
fall under that exemption in the GPL anyway?

I have not been able to pull up a succinct statement of why Debian
believes this is a problem when FSFE doesn't, or what we ought to do.
Can somebody please comment on the OpenSSL linking issue when OpenSSL is
only dynamically linked?

Kern believes that he must remove the explicit OpenSSL exemption from
the license in order to be fully GPL-compliant, and it appears that FSFE
agrees.

Thanks,

-- John

----- Forwarded message from Kern Sibbald <kern.TakeThisOut@sibbald.com> -----

From: Kern Sibbald <kern.TakeThisOut@sibbald.com>
Date: Thu, 7 Jun 2007 16:05:37 +0200
To: John Goerzen <jgoerzen.TakeThisOut@complete.org>
Subject: Bacula license

Hello John,

I hope things are going well for you.

There is an interesting issue that has come up with the Bacula license mainly
because of a request by Debian for me to add a specific clause that reads:

Linking:
Bacula may be linked with any libraries permitted under the GPL,
or with any non-GPLed libraries, including OpenSSL, that are
required for its proper functioning, providing the source code of
those non-GPLed libraries is non-proprietary and freely
available to the public.

Now, this was added because Debian asked me to add it because of the fact that
Bacula uses OpenSSL. However, in researching the issue a bit further, I
realize that Bacula does not link OpenSSL into the Bacula binary because the
OpenSSL (like glibc) is a shared object. Thus, no non-GPLed code is being
mixed with GPLed code, and hence there is no need for the above clause.

My question to you is: will there be any problems with Bacula in the Debian
distribution if I remove this clause and make the Bacula code simply pure GPL
v2?

Best regards,

Kern

PS: Here is an email that I sent to the Bacula list a while ago, that explains
in more detail the licensing problem.

==============================================
FYI An annoying GPL catch-22 concerning Bacula
Date: Today 11:38:01
From: Kern Sibbald <kern.TakeThisOut@sibbald.com>
To: "bacula-users" <bacula-users.TakeThisOut@lists.sourceforge.net>
CC: "bacula-devel" <bacula-devel.TakeThisOut@lists.sourceforge.net>


Hello,

For non-English speakers, a "catch-22" in English means a situation in which
there is no way out.

The following annoying and frustrating issue has come up with regard to the
Bacula source code:

As you probably know, Bacula is released with a modified GNU GPL licence. The
Bacula license modifies the GPL to permit Bacula to link to OpenSSL. This was
necessary because using MySQL libraries requires OpenSSL. This modification
was suggested by Debian to bring Bacula in compliance with their procedures.

The problem comes from including pure GNU GPL code, which is not compatible
with the OpenSSL license, inside Bacula itself (there are something like 8
such files). This works in the same way that Debian would not allow Bacula
as pure GNU GPL to link with OpenSSL. If Bacula uses any pure GNU GPL code
then that code cannot be subject to the GNU GPL modifications, and that code
technically cannot linked and distributed with Bacula because of OpenSSL.

I suspect that a lot of GPL projects are in a similar situation, but they do
not explicitly point out the exception as Bacula does. The real bummer here
is that this issue was flagged by someone involved in the Fedora packaging
process. From what I understand (I may be wrong here), Fedora and hence Red
Hat will not use Bacula because it uses some pure GPL code and OpenSSL
together raising potential license problems -- after the problems with SCO
and threats from Microsoft, their license concerns are quite understandable.

This is not a show-stopping issue because at least for the moment, no author
of pure GNU GPL code is lodging a complaint. In addition as I mentioned in a
previous email, this issue could potentially be resolved by GPL v3 (due at
the end of the month, if I remember right) because it is compatible with the
Apache license, which is apparently what OpenSSL uses.

In the mean time, until this problem is resolved, I've freezed all inclusion
of new GPL code (copyrighted by others) in Bacula.

The really complicated aspect of the above is that if you build a program such
as Bacula using all your own code, and you use OpenSSL then in linking it,
you just happen to drag some GPL'ed code from some library directly into your
binary (most libararies are shared objects so do not become part of your
binary), as is the case with the statically linked Bacula used in the rescue
package, you are in violation of the GPL if you distribute such a binary.

It seems that the only solution is that if you use GPL code, you must use
*all* GPL compatible code (not so easy), and if you don't use it, you
shouldn't even use the system libraries if there is any chance they could be
accidentally linked into your program.


Best regards,

Kern


----- End forwarded message -----
----- Forwarded message from Kern Sibbald <kern.TakeThisOut@sibbald.com> -----

From: Kern Sibbald <kern.TakeThisOut@sibbald.com>
Date: Thu, 7 Jun 2007 17:34:52 +0200
To: John Goerzen <jgoerzen.TakeThisOut@complete.org>
Subject: Re: Bacula license

On Thursday 07 June 2007 16:34, John Goerzen wrote:
> On Thu, Jun 07, 2007 at 04:05:37PM +0200, Kern Sibbald wrote:
> > Hello John,
> >
> > I hope things are going well for you.
>
> Hi Kern,
>
> > Now, this was added because Debian asked me to add it because of the fact
that
> > Bacula uses OpenSSL. However, in researching the issue a bit further, I
> > realize that Bacula does not link OpenSSL into the Bacula binary because
the
> > OpenSSL (like glibc) is a shared object. Thus, no non-GPLed code is being
> > mixed with GPLed code, and hence there is no need for the above clause.
>
> I remember, though somewhat vaguely, when all of this came up. I
> believe that the FSF considers dynamic linking to be linking that falls
> under the relevant clauses of the GPL. So I believe that the notice is
> still necessary.

I've been in conversation with FSFE, and from what they tell me, the GPL
prevents distribution of non-GPLed code not loading it in dynamic modules,
which is done quite frequently. Bacula does not distribute any OpenSSL code,
and there is no OpenSSL code mixed with the Bacula binaries, therefore
according to FSFE there is no problem.

>
> > My question to you is: will there be any problems with Bacula in the
Debian
> > distribution if I remove this clause and make the Bacula code simply pure
GPL
> > v2?
>
> I believe that this would cause us to have to stop distributing Bacula,
> because we can't do so in a way that meets the requirements of all
> licenses.

I've modified the license so that there are no changes to the GPL. If Debian
wants to be so strict as not allow dynamic linking to OpenSSL, which
according to FSFE is not prohibited, then my suggestion would be for Debian
to build and distribute a Bacula without the openssl option. That should in
the strictest sense solve the problem -- it would be a pity for the Debian
users if they could not have encryption.

>
> [ snip ]
>
> > I suspect that a lot of GPL projects are in a similar situation, but they
do
> > not explicitly point out the exception as Bacula does. The real bummer
here
> > is that this issue was flagged by someone involved in the Fedora packaging
> > process. From what I understand (I may be wrong here), Fedora and hence
Red
> > Hat will not use Bacula because it uses some pure GPL code and OpenSSL
> > together raising potential license problems -- after the problems with SCO
> > and threats from Microsoft, their license concerns are quite
understandable.
>
> This sounds like Fedora raised the same question that Debian did? Is
> your workaround clause not acceptable to them for some reason?

The Fedora problem was that there are something like 8 files included in
Bacula that are GPL and copyrighted by other people. Hence there is a
conflict if I modify the GPL for the Bacula code. I.e. the solution found
for Debian was technically not workable.

Personally, I really don't care if OpenSSL or any other program is linked in
to it providing the source is available, and I feel these license details are
a real pain in the neck for Open Source developers such as myself.

I believe that the current license as in the SVN, which has no modifications
to the GPL is perfectly fine.

>
> You might also want to seek advice on debian-legal.TakeThisOut@lists.debian.org.
> They are (usually) very helpful and are happy to help upstream authors
> over there. I do skim the list, and would be happy to help if there is
> a need for that.

Best regards,

Kern

>
> -- John
>


----- End forwarded message -----


--
To UNSUBSCRIBE, email to debian-legal-REQUEST.TakeThisOut@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.TakeThisOut@lists.debian.org

John Goerzen writes:

> Kern approached me about this situation (see full correspondence below,
> forwarded with his permission). He added that Bacula does not
> statically link with OpenSSL, that OpenSSL support can be disabled at
> build time, and that FSFE does not believe that an exception clause to
> the GPL is necessary to legally link to OpenSSL in the manner that
> Bacula is (dynamic linking). Further, could we not consider OpenSSL to
> be a major component of the OS on which the executable runs, and thus
> fall under that exemption in the GPL anyway?
>
> I have not been able to pull up a succinct statement of why Debian
> believes this is a problem when FSFE doesn't, or what we ought to do.
> Can somebody please comment on the OpenSSL linking issue when OpenSSL is
> only dynamically linked?

Debian generally distributes OpenSSL logically near the packages that
dynamically link against it, so the major system component option is
not available to Debian ("... unless that component itself accompanies
the executable").

GPL section 3(a) also uses "accompany" in a way that Debian and others
interpret to include distribution in the same directory tree on a
particular server, so -- the usual line of reasoning goes -- it would
be inconsistent to interpret "accompany" one way at the start of
section 3 and a different way at the end of section 3.

Michael Poole


--
To UNSUBSCRIBE, email to debian-legal-REQUEST.TakeThisOut@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.TakeThisOut@lists.debian.org