Re: Bacula: GPL and OpenSSL
On Friday 08 June 2007 01:46, Steve Langasek wrote:
> Hi Kern,
> On Thu, Jun 07, 2007 at 11:53:19PM +0200, Kern Sibbald wrote:
> > Well, the above is total Greek to me. However, I must say that there is
> > absolutely no reason why Bacula would every accompany OpenSSL in any sense
> > of the the English meaning of accompany that I am aware of
> Bacula doesn't accompany OpenSSL when you distribute it, but they certainly
> do accompany one another when we distribute them both as part of the Debian
> OS. This is a plain English meaning of "accompany".
Yes, sorry, I was looking at distribution from the Bacula standpoint rather
than from a Debian distribution until I though this through last night.
However, the "strict" interpretation would imply that the GPL is not fair (in
the sense of compaints about the Novell - Microsoft contract), because I can
distribute Bacula binaries because no where on any of the project sites do we
distribute OpenSSL, but then the strict definition says that you cannot
distribute Bacula because you have OpenSSL someplace on the distribution
disks, or on your servers.
> I have seen various FSF FAQs over the years that have claimed that
> distributing binaries linked against OpenSSL is ok, but these FAQs have been
> mute on the matter of distribution as part of an OS.
I haven't seen them, but that doesn't surprise me as I don't believe that FSF
ever really wanted to prohibit linking against OpenSSL, and if they did, they
have clearly changed their minds since the GPL v3 permits it.
> In recent times, it
> appears that some Unix vendors such as Sun and Apple have also begun
> distributing GNU software as part of systems whose cores are not licensed
> compatibly with the GPL, with the FSF's tacit consent; that seems
> ill-advised to me, but in any case the FSF's interpretations of the GPL
> aren't binding on other copyright holders where those interpretations don't
> follow logically from the text of the license.
I'm not sure Sun and Apple are so ill-advised. While I admit that the strict
interpretion is possible and one never knows what a judge would decide, it is
sort of like the possibility of a magic asteroid striking earth. It is
possible that an asteroid could strike earth, but it is so remote that it
doesn't make sense to work in caves rather than skyscrapers to try to avoid
being killed. In the case of the strict interpretation, IMO it is equally
unlikely to create a court case, and in any case, the consequences would be
rather minor -- simply remove OpenSSL.
> > By the way, just to be clear, I consider all this (not you guys but these
> > license difficulties) to be a real pain. As long as the code is Open
> > (i.e. I can get it, see it and modify it), I have no problem with it being
> > linked with Bacula.
> Ah, well, that right there is sufficient for us to use as a license
> exception grant. :) But of course it's not binding on other copyright
If that resoves the problems, great. Here is what I have just added to the
LICENSE file -- hopefully it should be clear. Here is a snippet from the
LICENSE file ...
For the most part, Bacula is licensed under the GPL version 2
this code is listed under Copyright Free Software Foundation
Europe e.V. A small part of the code (less than 20 files) is
copyrighted under the GPL by other people (FSF, Sun, ...).
What follows is information from the authors of the code:
Bacula may be linked with any libraries permitted under the GPL.
However, if configured with encryption Bacula does use the
OpenSSL libraries which are, unfortunately, not compatible with
GPL v2. To the best of our knowledge these libaries are not
distributed with Bacula code because they are shared objects, and
as such there is no conflict with the GPL according what I (Kern)
understand in talking to FSFE, and in any case, for the code that
I have written, I have no problems linking in OpenSSL (of course
this does not speak for the few files in Bacula that are
copyrighted by others). If you take a more severe stance on this
issue, and you are going to distribute Bacula, then simply do not
use the --with-openssl when building your package, and no use of
OpenSSL even through dynamic linking will be included.
> > > So the question really is: how can we have Bacula in Debian, with SSL
> > > support, but without that clause?
> > This is apparently possible because GNUTLS seems to have an OpenSSL
> > compatiblity layer.
> Not much of one, I fear...
Yes, and they don't have an official certification of their code as OpenSSL
does, so I for one (and I suspect it applies even more to corporate users)
would much prefer to use OpenSSL -- at least at the current time.
> > The problem is that those third-party sources are linked into the Bacula
> > binaries, and since they are licensed as GPL with no modifications, I
> > include them in a binary that has code that is licensed in a way that is
> > incompatible with the GPL. Adding the OpenSSL exception to my license
> > my code incompatible with the non-modified GPL, and hence I was violating
> > license on those 3rd party files (copyrighted by FSF, ATT, Sun, and a few
> > others ...).
> To be clear here, it's not incompatible with the GPL for you to grant
> additional linking permissions, which is what is being done. The only real
> issue is that you can't grant such permission on behalf of other copyright
That is what I believed, but according to Fedora/Red Hat and FSFE, the fact
that I have mixed code in a single binary that is "pure" GPL for which I
(FSFE) do not hold the copyright and GPL with a modified license violates the
license given by the authors of the "pure" GPL. Since that is serious to me,
and I am not a lawyer, and I have first hand experience in how "illogical"
(IMO) judges can be, I prefer to avoid the problem and not modify the GPL.
So now Bacula is all "pure" GPL with no modifications with my explanations in
notes rather than as modifications of the license.
> Steve Langasek Give me a lever long enough and a Free OS
> Debian Developer to set it on, and I can move the world.
> email@example.com http://www.debian.org/