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 <[EMAIL PROTECTED]> ----- From: Kern Sibbald <[EMAIL PROTECTED]> Date: Thu, 7 Jun 2007 16:05:37 +0200 To: John Goerzen <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> To: "bacula-users" <[EMAIL PROTECTED]> CC: "bacula-devel" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> ----- From: Kern Sibbald <[EMAIL PROTECTED]> Date: Thu, 7 Jun 2007 17:34:52 +0200 To: John Goerzen <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] > 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]