[openchange][devel] [Bacula-devel] Bacula and Exchange mail stores

Dan Shearer dan at shearer.org
Fri Sep 7 15:04:10 CEST 2007

On Fri, Sep 07, 2007 at 02:24:34PM +0200, Kern Sibbald wrote:
> From what you write, I'm not sure that you really understand the problem -- it 

I think (I hope) I understood the problem enough to focus on the one bit
that concerns me:

> Now, I am not immediately considering switching either to GPL (2 or later) or 
> to v3 because I find it too hard to understand v3, and it does not resolve 
> the problem with OpenSSL.  My solution for Bacula will probably be: keep 
> GPLv2, but add an exception, which I can do because it is all our own code -- 
> no 3rd party GPL copyrights.  The exception will be something like the 
> following:

Yes, this all makes sense. What I am suggesting is that you move to:

  GPLv2(or greater) plus an exception

rather than

  GPLv2(only) plus an exception

which is what I understood you to have written. 

>       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 license for said   
>       libraries is OpenSource as defined by OSI (i.e. the source code is
>       freely available and can be modified).

I understand this exception, I think it addresses the complicated nexus
of licenses you face very well. 

In our situation at OpenChange, we link very extensively to GPL (not
LGPL) Samba libraries. Samba has been GPLv2 or later, and recently
became GPLv3 or later. Samba has a very different set of constraints and
competitive environment to Bacula, and GPLv3 is what the Samba team have
chosen.  That has nothing to do with OpenChange: we can't replace Samba
even if we wanted to, right now we're peddling hard just to solve

However with OpenChange it is not impossible that one day another
provider of the underlying SMB services might come along to deliver what
we need client-side. We are very unlikely to stop linking to Samba (why
would we?) but it is feasible that we might start offering the option to
link to something else instead. An example project that, with some work,
might be able to do this is jCIFS. jCIFS is LGPLv2+, and potentially we
could start licensing OpenChange under both the GPLv3(or later) and the
LGPLv3(or later), or even something wildly different.

My point is that *regardless* of anything we do with dual licensing and
exceptions, it is all moot until a replacement for Samba GPL libraries
appears. There is no chance of persuading the Samba team to adopt a
GPL-with-exceptions license, nor do I think in the particular case of
Samba that would be a wise move.

> Were you to add something similar, it would probably solve the problem.  It 

So, I hope I have been clear, I'm afraid there is no solution like this
that will solve the problem unless it also comes with man-years worth of
coding to replace Samba libraries.

> might be a bit harder to write since in your case, you have libraries that 
> would be included in other programs, and you probably don't want your code to 

... and then as you rightly say, there is the downstream case. And how.

> If you are interested in working on something, let me know, and I can
> probably come up with something that would allow Bacula an OpenChange
> to work together.  In any case whatever clause I add to Bacula will be
> reviewed by FSFE (Free Software Foundation Europe) before it is
> included to ensure there is no loop hole in what I want to accomplish.

I am very interested. Given the extra explanations above, do you now see
it any differently to me?
As a minor technical point, it seems to me as a non-backup person that
having a plugin interface to call scripts for backup purposes is a good
idea?  I can think of commandline tools on Windows, Unix, VMS and
several other operating systems where everything you want to do certain
operations already exists in a command (eg, dump permissions for all
files on a volume.)

Dan Shearer
dan at shearer.org

More information about the devel mailing list