Bacula and OpenSSL

Kern Sibbald · External Since: Jun 29, 2006 Posts: 43

Hello Shane,

Bacula is nearing the end of a development cycle and the next version will be
released in a matter of weeks, so I would like to revisit the problem that
recently came up with the Bacula license. My purpose is not to debate the
issues but rather come up with a plan forward for Bacula so that all
distributions can use it with OpenSSL or any other Open Source code without
problems. Please excuse me if I provide you with a bit of my reasoning and
thoughts -- the idea is to help you target responses so I can end up with an
accpetable solution.

History:
Bacula originally used the GPL v2 license, but I added some modifications to
it -- most if not all are (IMO) now contained in the GPL v3. However, some
of my original modifications created objections with Debian, so I removed
them. In addition, Debian has an issue with distributing Bacula linked with
OpenSSL and as a consequence, I added a modification to the GPL permitting
Debian to link Bacula with OpenSSL.

In more recent discussions with you, it seems that some of my modifications to
the GPL (particularly the "Debian" clause) created a legal problem with
Fedora and hence Red Hat because the GPL v2 is incompatible with the OpenSSL
license and because there are about 10-20 files in the Bacula source that are
copyrighted by third-parties under the GPL, so by modifying my license, I was
or could have been technically violating their licenses.

Most recently, I removed all modifications I had made to the GPL so the Bacula
code written by myself and Bacula contributors is copyrighted under GPL v2.

Where we are:
As the Bacula source code currently stands, I expect that since it is pure GPL
that it is acceptable as is to most distros. However, my understanding is
that Debian will not be able to build the next version with OpenSSL due to
their interpretation of the GPL. I find this a pity -- particularly because
Debian was the first distro to officially package Bacula, and because I am
also moving my systems over time to a Debian base.

What I would like:
I would like Bacula to be able to be freely used by all distros without
licensing problems with any Open Source software including OpenSSL.

How do we get there?
It seems to me that there are a number of alternatives:

1. Convert Bacula to use gnutls. One Debian user is working on this, but it
is not a small nor an easy project. And though it is something I consider
very worthwhile for Bacula to work with gnutls, it doesn't resolve the
problem of using Bacula with OpenSSL.

2. You recently mentioned to me that GPL v3 may be a solution. Like Linus, I
don't see any reason to switch to GPL v3, but if using GPL v3 makes Bacula
compatible with OpenSSL AND all distros are happy with that, it seems to me
to be an easy solution. I know that GPL v3 is compatible with the Apache
license, but can you confirm whether or not it is compatible with whatever
OpenSSL uses? I would also appreciate having Debian's legal view on this
question.

3. Barring item 2, it seems to me that the only solution is to eliminate all
third party software from Bacula and change the license to less restrictive
one that permits Bacula being linked with any Open Source software.

Does anyone see any other solutions that I am missing?

If at all possible, I would like to get at least the direction on how to
resolve this defined within the next several weeks. If alternative 2 is
viable, it is something that I can probably do for release 2.2.0.

Best regards,

Kern

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

Gervase Markham · External Since: Jun 18, 2005 Posts: 31

Kern Sibbald wrote:
> 2. You recently mentioned to me that GPL v3 may be a solution. Like Linus, I
> don't see any reason to switch to GPL v3, but if using GPL v3 makes Bacula
> compatible with OpenSSL AND all distros are happy with that, it seems to me
> to be an easy solution. I know that GPL v3 is compatible with the Apache
> license, but can you confirm whether or not it is compatible with whatever
> OpenSSL uses? I would also appreciate having Debian's legal view on this
> question.

I don't believe that Debian provides "legal views"...

My personal view is that GPLv3 is not compatible with the OpenSSL license.

The problematic part of the OpenSSL license is the "BSD advertising clause":

* 3. All advertising materials mentioning features or use of this
* software must display the following acknowledgment:
* "This product includes software developed by the OpenSSL Project
* for use in the OpenSSL Toolkit. (http://www.openssl.org/)"
(From http://www.openssl.org/source/license.html)

The only way this might be compatible with GPLv3 is if this clause was
permitted by one of the clauses in GPLv3 section 7, "Additional Terms".
The only one under which it might fit is clause b):

Notwithstanding any other provision of this License, for material you
add to a covered work, you may (if authorized by the copyright holders
of that material) supplement the terms of this License with terms:
...
* b) Requiring preservation of specified reasonable legal notices
or author attributions in that material or in the Appropriate Legal
Notices displayed by works containing it;
(From http://www.gnu.org/licenses/gpl.html)

However, this only permits requiring preservation of notices "in the
material". An advertisement mentioning OpenSSL is not part of OpenSSL,
and so this clause does not make point 3. of the OpenSSL license
GPLv3-compatible.

> 3. Barring item 2, it seems to me that the only solution is to eliminate all
> third party software from Bacula and change the license to less restrictive
> one that permits Bacula being linked with any Open Source software.

This seems the correct way forward in the long term.

Gerv

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

Shane M. Coughlan · External Since: Jul 12, 2007 Posts: 9

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Kern

Kern Sibbald wrote:
> What I would like:
> I would like Bacula to be able to be freely used by all distros without
> licensing problems with any Open Source software including OpenSSL.
<snip>
> 1. Convert Bacula to use gnutls. One Debian user is working on this, but it
> is not a small nor an easy project. And though it is something I consider
> very worthwhile for Bacula to work with gnutls, it doesn't resolve the
> problem of using Bacula with OpenSSL.

I understood that you require OpenSSL for Bacula due to user demand, so
you could not replace it by GNUTLS entirely. Is that correct?

> 2. You recently mentioned to me that GPL v3 may be a solution. Like Linus, I
> don't see any reason to switch to GPL v3, but if using GPL v3 makes Bacula
> compatible with OpenSSL AND all distros are happy with that, it seems to me
> to be an easy solution. I know that GPL v3 is compatible with the Apache
> license, but can you confirm whether or not it is compatible with whatever
> OpenSSL uses? I would also appreciate having Debian's legal view on this
> question.

There was the possibility that the final GPLv3 might turn out compatible
with the OpenSSL licence. However, the published GPLv3 is not compatible
with the OpenSSL licence. To be sure I also confirmed this with Brett
Smith at FSF in Boston.

> 3. Barring item 2, it seems to me that the only solution is to eliminate all
> third party software from Bacula and change the license to less restrictive
> one that permits Bacula being linked with any Open Source software.

The issue flagged by Fedora concerned that third-party code. In essence:
If you remove all the vanilla GPLv2 or later software from Bacula you
could also move back to your previous GPL+extra clauses license, or to a
GPLv3 + OpenSSL exception license.

Regards

Shane

- --
Shane Coughlan
FTF Coordinator
Free Software Foundation Europe
Office: +41435000366 ext 408 / Mobile: +41792633406
coughlan DeleteThis @fsfeurope.org
Support Free Software > http://fsfe.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iQCVAwUBRpZRctGa7CzA5hXyAQJ1UAP/S1VHW5iA9MR0dl+i4C3PEoYnpdgbPSVa
nsJp68tErT9QXnnhKBDb0HVZtzHEpTryknssXkFCEeFTy7GllKRUfRys0zKQWF5Q
EWSoKooUcZsLMnJpoqgG0P4AX+Nl/3Ft46TtHhe+WFCGAdij8B2puUmx1oq4Uetl
hoJ0BlSk40A=
=vHfw
-----END PGP SIGNATURE-----

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

Steve Langasek · External Since: Dec 13, 2004 Posts: 2140

On Thu, Jul 12, 2007 at 06:06:14PM +0200, Shane M. Coughlan wrote:
> > 2. You recently mentioned to me that GPL v3 may be a solution. Like Linus, I
> > don't see any reason to switch to GPL v3, but if using GPL v3 makes Bacula
> > compatible with OpenSSL AND all distros are happy with that, it seems to me
> > to be an easy solution. I know that GPL v3 is compatible with the Apache
> > license, but can you confirm whether or not it is compatible with whatever
> > OpenSSL uses? I would also appreciate having Debian's legal view on this
> > question.

> There was the possibility that the final GPLv3 might turn out compatible
> with the OpenSSL licence. However, the published GPLv3 is not compatible
> with the OpenSSL licence. To be sure I also confirmed this with Brett
> Smith at FSF in Boston.

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?

> > 3. Barring item 2, it seems to me that the only solution is to eliminate all
> > third party software from Bacula and change the license to less restrictive
> > one that permits Bacula being linked with any Open Source software.

> The issue flagged by Fedora concerned that third-party code. In essence:
> If you remove all the vanilla GPLv2 or later software from Bacula you
> could also move back to your previous GPL+extra clauses license, or to a
> GPLv3 + OpenSSL exception license.

Is there some reason that marking only his code as GPLv2 + OpenSSL
exception, making it clear that other code (and which other code) included
in Bacula does not have such an exception, would not be acceptable to all
parties? Granting an additional permission is not modifying the GPL, and as
long as the permission is detachable it would not make the license
incompatible with the vanilla GPLv2 used in other parts of the work; and
that would permit distributors to make an informed decision whether to
excise the GPLv2-only code in order to distribute binaries linked against
OpenSSL.

Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon.RemoveThis@debian.org http://www.debian.org/

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

Kern Sibbald · External Since: Jun 29, 2006 Posts: 43

On Thursday 12 July 2007 18:06, Gervase Markham wrote:
> Kern Sibbald wrote:
> > 2. You recently mentioned to me that GPL v3 may be a solution. Like
Linus, I
> > don't see any reason to switch to GPL v3, but if using GPL v3 makes Bacula
> > compatible with OpenSSL AND all distros are happy with that, it seems to
me
> > to be an easy solution. I know that GPL v3 is compatible with the Apache
> > license, but can you confirm whether or not it is compatible with whatever
> > OpenSSL uses? I would also appreciate having Debian's legal view on this
> > question.
>
> I don't believe that Debian provides "legal views"...

Perhaps it was a bad choice of words. Debian has in the past provided me with
their take on my license as it applies to their distribution, which is what
interests me.

>
> My personal view is that GPLv3 is not compatible with the OpenSSL license.

That has been confirmed by FSFE (Shane).

>
> The problematic part of the OpenSSL license is the "BSD advertising clause":
>
> * 3. All advertising materials mentioning features or use of this
> * software must display the following acknowledgment:
> * "This product includes software developed by the OpenSSL Project
> * for use in the OpenSSL Toolkit. (http://www.openssl.org/)"
> (From http://www.openssl.org/source/license.html)

I personally see no particular issue with the advertising clause from two
points of view:
- if he really wants such an acknowledgement, why not. For me, it doesn't
violate any of my fundamental rights. If one mentions Windows, in any
documentation whatsoever, one is required to mention that it is a trademark
of Microsoft -- the same applies to a lot of other things as well, including
the name Bacula Smile

- Bacula does no advertisment (we have a users manual, but that is not
advertisement, IMO), so this clause would have no effect anyway.

>
> The only way this might be compatible with GPLv3 is if this clause was
> permitted by one of the clauses in GPLv3 section 7, "Additional Terms".
> The only one under which it might fit is clause b):
>
> Notwithstanding any other provision of this License, for material you
> add to a covered work, you may (if authorized by the copyright holders
> of that material) supplement the terms of this License with terms:
> ...
> * b) Requiring preservation of specified reasonable legal notices
> or author attributions in that material or in the Appropriate Legal
> Notices displayed by works containing it;
> (From http://www.gnu.org/licenses/gpl.html)
>
> However, this only permits requiring preservation of notices "in the
> material". An advertisement mentioning OpenSSL is not part of OpenSSL,
> and so this clause does not make point 3. of the OpenSSL license
> GPLv3-compatible.
>
> > 3. Barring item 2, it seems to me that the only solution is to eliminate
all
> > third party software from Bacula and change the license to less
restrictive
> > one that permits Bacula being linked with any Open Source software.
>
> This seems the correct way forward in the long term.

Yes, that is the conculsion I have come to as well. Thanks.

It seems a real pity to me that the GPL is so restrictive -- it should make my
life as a programmer easier, but it has in fact made it harder.

Best regards,

Kern

>
> Gerv
>

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

Kern Sibbald · External Since: Jun 29, 2006 Posts: 43

On Thursday 12 July 2007 18:06, Shane M. Coughlan wrote:
> Hi Kern
>
> Kern Sibbald wrote:
> > What I would like:
> > I would like Bacula to be able to be freely used by all distros without
> > licensing problems with any Open Source software including OpenSSL.
> <snip>
> > 1. Convert Bacula to use gnutls. One Debian user is working on this, but
it
> > is not a small nor an easy project. And though it is something I consider
> > very worthwhile for Bacula to work with gnutls, it doesn't resolve the
> > problem of using Bacula with OpenSSL.
>
> I understood that you require OpenSSL for Bacula due to user demand, so
> you could not replace it by GNUTLS entirely. Is that correct?

Yes, that is essentially correct. gnutls could replace OpenSSL for nearly
everyone, but some institutions such as banks and financial instututions may
need the extra certification that OpenSSL has.

>
> > 2. You recently mentioned to me that GPL v3 may be a solution. Like
Linus, I
> > don't see any reason to switch to GPL v3, but if using GPL v3 makes Bacula
> > compatible with OpenSSL AND all distros are happy with that, it seems to
me
> > to be an easy solution. I know that GPL v3 is compatible with the Apache
> > license, but can you confirm whether or not it is compatible with whatever
> > OpenSSL uses? I would also appreciate having Debian's legal view on this
> > question.
>
> There was the possibility that the final GPLv3 might turn out compatible
> with the OpenSSL licence. However, the published GPLv3 is not compatible
> with the OpenSSL licence. To be sure I also confirmed this with Brett
> Smith at FSF in Boston.

OK, thanks for the confirmation -- too bad.

>
> > 3. Barring item 2, it seems to me that the only solution is to eliminate
all
> > third party software from Bacula and change the license to less
restrictive
> > one that permits Bacula being linked with any Open Source software.
>
> The issue flagged by Fedora concerned that third-party code. In essence:
> If you remove all the vanilla GPLv2 or later software from Bacula you
> could also move back to your previous GPL+extra clauses license, or to a
> GPLv3 + OpenSSL exception license.

OK, I think the possible solutions are pretty clear to me. Thank you for the
rapid response.

Best regards,

Kern

>
> Regards
>
> Shane
>
> --
> Shane Coughlan
> FTF Coordinator
> Free Software Foundation Europe
> Office: +41435000366 ext 408 / Mobile: +41792633406
> coughlan DeleteThis @fsfeurope.org
> Support Free Software > http://fsfe.org
>

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

Joe Smith · External Since: Jun 12, 2005 Posts: 78

"Kern Sibbald" <kern.RemoveThis@sibbald.com> wrote in message
news:200707121641.53917.kern@sibbald.com...
> Hello Shane,
>
> Bacula is nearing the end of a development cycle and the next version will
> be
> released in a matter of weeks, so I would like to revisit the problem that
> recently came up with the Bacula license. My purpose is not to debate the
> issues but rather come up with a plan forward for Bacula so that all
> distributions can use it with OpenSSL or any other Open Source code
> without
> problems. Please excuse me if I provide you with a bit of my reasoning
> and
> thoughts -- the idea is to help you target responses so I can end up with
> an
> accpetable solution.
>
> History:
> Bacula originally used the GPL v2 license, but I added some modifications
> to
> it -- most if not all are (IMO) now contained in the GPL v3. However,
> some
> of my original modifications created objections with Debian, so I removed
> them. In addition, Debian has an issue with distributing Bacula linked
> with
> OpenSSL and as a consequence, I added a modification to the GPL permitting
> Debian to link Bacula with OpenSSL.
>
> In more recent discussions with you, it seems that some of my
> modifications to
> the GPL (particularly the "Debian" clause) created a legal problem with
> Fedora and hence Red Hat because the GPL v2 is incompatible with the
> OpenSSL
> license and because there are about 10-20 files in the Bacula source that
> are
> copyrighted by third-parties under the GPL, so by modifying my license, I
> was
> or could have been technically violating their licenses.

Well it is not a violation to have a mechanism to allow third parties to
link to openSSL. The third parties
would be violating licences by linking the work (assuming the FSF's linking
theories are in fact leagally sound),
however that is not your concern. What would be your concern is that
distributions are often not willing to
distribute the linked executables, for obvious reasons.

However, for you the ideal situation would be to get permission from the
copyright holders of the gpl'ed code you did not write to add a clause
allowing linking to openssl. If you could do that, then just add the clause
and everything is fine.

One other possibility you did not list in your message would be to convince
openSSL to change the licence to one that is GPL-compatible. This seems
highly unlikely (nearly impossible), but would finally fix this problem once
and for all. (The OpenSSL team feels the licence is GPL-compatible. It's
unclear why, as it has a BSD like-advertising clause that is infamous for
its GPL-incompatibility).

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

Kern Sibbald · External Since: Jun 29, 2006 Posts: 43

On Thursday 12 July 2007 22:52, Josselin Mouette wrote:
> Le jeudi 12 juillet 2007 à 16:41 +0200, Kern Sibbald a écrit :
> > How do we get there?
> > It seems to me that there are a number of alternatives:
> >
> > 1. Convert Bacula to use gnutls. One Debian user is working on this, but
it
> > is not a small nor an easy project. And though it is something I consider
> > very worthwhile for Bacula to work with gnutls, it doesn't resolve the
> > problem of using Bacula with OpenSSL.
>
> This looks like a good thing to do in the long term anyway, and not only
> for licensing matters.
>
> > 2. You recently mentioned to me that GPL v3 may be a solution. Like
Linus, I
> > don't see any reason to switch to GPL v3, but if using GPL v3 makes Bacula
> > compatible with OpenSSL AND all distros are happy with that, it seems to
me
> > to be an easy solution. I know that GPL v3 is compatible with the Apache
> > license, but can you confirm whether or not it is compatible with whatever
> > OpenSSL uses? I would also appreciate having Debian's legal view on this
> > question.
>
> The GPL v3 is not compatible with the OpenSSL license. However, section
> 6 states:
> A separable portion of the object code, whose source code is
> excluded from the Corresponding Source as a System Library, need
> not be included in conveying the object code work.
> Apart from the very bad wording, I think the OpenSSL libraries can be
> perfectly considered as part of the "System libraries".
>
> This flaw of the GPLv3 is at least good for something. If your GPL
> software can now be included in the HP-UX or AIX distribution, it can
> also be included in Debian.

Well, I don't consider the above a flaw. The flaw (restriction of my freedom)
is in GPL if it does not permit linking with OpenSSL (IMO).

I agree with your interpretation, but I'm pretty sure that is not
the "official" interpretation that Debian takes or am I mistaken?

In fact, I consider for linking with Bacula as a separately installed piece of
the system libraries that OpenSSL is part of the "operating" system in the
same way that tcp wrappers or glibc is or any other library is, which would
mean that there should be no problem with GPL v2. However, I know as a fact
that as far as GPL v2 goes, Debian definitely does not agree with my
interpretation.

>
> Please note that this is only applicable if your third-party
> contributions are licensed under GPL v2 or later.

Bacula code is GPL v2, but all third party GPL'ed code (mostly FSF) is GPL v2
or later.

>
> > 3. Barring item 2, it seems to me that the only solution is to eliminate
all
> > third party software from Bacula and change the license to less
restrictive
> > one that permits Bacula being linked with any Open Source software.
>
> GPL + OpenSSL exception would be enough to be sure. You may have more
> luck convincing copyright owners to grant an OpenSSL exception than to
> accept an entirely new license.

I am told that FSF never grants exceptions so this is a hopeless path that I
have already explored.

Regards,

Kern

Unless Debian finds that GPL v3 will work with OpenSSL, barring one more
unexplored avenue, over time, I'll purge all third party GPL'ed code and
either modify or more likely switch off the GPL license ...

>
> Cheers,
> --
> .''`.
> : :' : We are debian.org. Lower your prices, surrender your code.
> `. `' We will add your hardware and software distinctiveness to
> `- our own. Resistance is futile.
>

Kern Sibbald · External Since: Jun 29, 2006 Posts: 43

On Thursday 12 July 2007 22:59, Josselin Mouette wrote:
> Le jeudi 12 juillet 2007 à 20:18 +0200, Kern Sibbald a écrit :
> > It seems a real pity to me that the GPL is so restrictive -- it should
make my
> > life as a programmer easier, but it has in fact made it harder.
>
> The main point of the GPL is not to make your life easier, but to
> prevent your code from being used unfairly.
>
> If you want to go the easy way you should choose the MIT license Smile

I would like a tit-for-a-tat clause so that those who modify it and distribute
it are obligated to publish their modifications. The MIT license does not
provide that.

>
> --
> .''`.
> : :' : We are debian.org. Lower your prices, surrender your code.
> `. `' We will add your hardware and software distinctiveness to
> `- our own. Resistance is futile.
>

Kern Sibbald · External Since: Jun 29, 2006 Posts: 43

On Friday 13 July 2007 01:31, Josselin Mouette wrote:
> Le jeudi 12 juillet 2007 à 23:42 +0200, Kern Sibbald a écrit :
> > > This flaw of the GPLv3 is at least good for something. If your GPL
> > > software can now be included in the HP-UX or AIX distribution, it can
> > > also be included in Debian.
> >
> > Well, I don't consider the above a flaw. The flaw (restriction of my
freedom)
> > is in GPL if it does not permit linking with OpenSSL (IMO).
>
> This is a flaw in the copyleft, because it allows proprietary software
> distributors to benefit from the software more than they deserve. As for
> not being compatible with the OpenSSL license, this is intentional and
> the fact the GPLv3 wasn't changed to allow it confirms this intention.
> The advertising clause is not problematic for Bacula, but it may be so
> for much other software.
>
> > I agree with your interpretation, but I'm pretty sure that is not
> > the "official" interpretation that Debian takes or am I mistaken?
>
> The GPLv3 is quite new and I don't think all consequences have been
> explored. Anyway, it would be more relevant to know whether the
> copyright holders (here, the FSF) agree that this clause applies to
> OpenSSL in Debian (which is priority important and required by key
> components of the windowing system).
>
> > In fact, I consider for linking with Bacula as a separately installed
piece of
> > the system libraries that OpenSSL is part of the "operating" system in the
> > same way that tcp wrappers or glibc is or any other library is, which
would
> > mean that there should be no problem with GPL v2. However, I know as a
fact
> > that as far as GPL v2 goes, Debian definitely does not agree with my
> > interpretation.
>
> This is true for Bacula packages you would distribute yourself, but this
> is *not* the case for packages included in Debian. The GPLv2 reads:
>
> However, as a special exception, the source code distributed
> need not include anything that is normally distributed (in
> either source or binary form) with the major components
> (compiler, kernel, and so on) of the operating system on which
> the executable runs, *unless that component itself accompanies
> the executable*.
>
> This clause couldn't be more explicit. Debian ships all its software at
> the same place, which means the exception doesn't apply.

I think you are misreading the above. It simply says that for us who
distribute Bacula code only, we are not required to distribute the source
code for other "major components" that Bacula may use, such as glibc,
tcpwrappers, or OpenSSL.

However, you (Debian) who distribute a whole operating system, must also
include all the source to all the packages, which is exactly what you do.
The source code that you distribute includes the source to OpenSSL. There is
no issue here since the source code must just be available on request, which
is the case. It doesn't have to ship with the binaries.

>
> > Bacula code is GPL v2, but all third party GPL'ed code (mostly FSF) is GPL
v2
> > or later.
>
> Then, unless I have seriously misunderstood the reworded system
> libraries exception, I think relicensing Bacula under the GPLv3 (or
> dual-licensing under v2 and v3) should be fine for Debian.

Sorry, but could you run it by me one more time why GPL v3 will work for
Debian and why GPL v2 will not. The problem on GPL v2 for me was I needed to
make an exception, which I cannot do without violating the 3rd party GPL
licensed code I use. Why does GPL v3 resolve this? From what I
understood, you are saying that in GPL v3 any separate object code does not
require releasing the source for that object code -- i.e. it is now possible
for a GPLed program to link to a separate object that is built from
proprietary source?

>
> > I am told that FSF never grants exceptions so this is a hopeless path that
I
> > have already explored.
>
> Indeed.

There is a certain logic in that response since they have pushed hard for
reducing the number of licenses, it makes sense that they are not going to
favor making "derivatives" themselves to their own licenses ...

>
> --
> .''`.
> : :' : We are debian.org. Lower your prices, surrender your code.
> `. `' We will add your hardware and software distinctiveness to
> `- our own. Resistance is futile.
>

Josselin Mouette · External Since: Nov 09, 2004 Posts: 1057

Le vendredi 13 juillet 2007 à 07:20 +0200, Kern Sibbald a écrit :
> > Then, unless I have seriously misunderstood the reworded system
> > libraries exception, I think relicensing Bacula under the GPLv3 (or
> > dual-licensing under v2 and v3) should be fine for Debian.
>
> Sorry, but could you run it by me one more time why GPL v3 will work for
> Debian and why GPL v2 will not. The problem on GPL v2 for me was I needed to
> make an exception, which I cannot do without violating the 3rd party GPL
> licensed code I use. Why does GPL v3 resolve this? From what I
> understood, you are saying that in GPL v3 any separate object code does not
> require releasing the source for that object code -- i.e. it is now possible
> for a GPLed program to link to a separate object that is built from
> proprietary source?

In my opinion the GPLv3 is more liberal with the licensing of the system
libraries. This is what makes Nexenta legal now (it links dpkg which is
GPL to the Solaris libc which is CDDL) and it applies to the Bacula case
as well.

Cheers,
--
.''`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`- our own. Resistance is futile.

Thomas Dickey · External Since: Aug 09, 2006 Posts: 96

Kern Sibbald <kern.DeleteThis@sibbald.com> wrote:

> I would like a tit-for-a-tat clause so that those who modify it and distribute
> it are obligated to publish their modifications. The MIT license does not
> provide that.

On the other hand, the MIT license permits even use by the objectionable
persons who contribute to this thread.

regards.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

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

Simon Josefsson · External Since: Oct 24, 2006 Posts: 82

Kern Sibbald <kern.DeleteThis@sibbald.com> writes:

>> GPL + OpenSSL exception would be enough to be sure. You may have more
>> luck convincing copyright owners to grant an OpenSSL exception than to
>> accept an entirely new license.
>
> I am told that FSF never grants exceptions so this is a hopeless path that I
> have already explored.

That is incorrect. The FSF has granted OpenSSL license exceptions to
some software that links to OpenSSL. For example, GNU wget.

Exactly what FSF code are you using? It couldn't hurt to ask them. If
it is general purpose code, I suspect they won't give it, but if it is
network or even TLS related, there could be a chance.

/Simon

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

Kern Sibbald · External Since: Jun 29, 2006 Posts: 43

On Saturday 14 July 2007 11:03, Simon Josefsson wrote:
> Kern Sibbald <kern DeleteThis @sibbald.com> writes:
>
> >> GPL + OpenSSL exception would be enough to be sure. You may have more
> >> luck convincing copyright owners to grant an OpenSSL exception than to
> >> accept an entirely new license.
> >
> > I am told that FSF never grants exceptions so this is a hopeless path that
I
> > have already explored.
>
> That is incorrect. The FSF has granted OpenSSL license exceptions to
> some software that links to OpenSSL. For example, GNU wget.

Interesting. Shane would you comment on this?

>
> Exactly what FSF code are you using? It couldn't hurt to ask them. If
> it is general purpose code, I suspect they won't give it, but if it is
> network or even TLS related, there could be a chance.

Well, it is pretty general purpose. None of the FSF code is network or TLS
related. The FSF files involved are:

src/lib/fnmatch.h FSF
src/lib/fnmatch.c FSF
src/lib/enh_fnmatch.h FSF
src/lib/enh_fnmatch.c FSF (fnmatch enhanced by us)

src/lib/idcache.c FSF (from tar I think)
src/findlib/save-cwd.c FSF (from tar I think)
src/findlib/makepath.c FSF (from tar I think)

In addition, there are two files copyrighted by Anders Carlsson, two by Sun
Microsystems in the tray-monitor directory, and a number of files by AT&T
all in the win32 subdirectories.

My status on this "project" is:
- I have already removed or replaced(with BSD code) three files that were
copyrighted by FSF

- idcache.c, I will re-write in any case (I've been planning this long before
this problem).

- I have a BSD licensed replacement for fnmatch, which I can substitute after
the 2.2.0 (next) release of Bacula.

- Probably enh_fnmatch will follow, but it is a good deal of extra work since
it involves a good number of modifications.

- save-cwd.c and makepath.c are heavily modified and will be more difficult to
replace (confusion of the original code and the heavy modifications make the
task harder).

- I will rewrite the AT&T copyrighted code after 2.2.0 is released, but this
code is used only in the Win32 release so does not concern the Debian
problem.

- The Anders Carlsson and Sun copyrighted code is used in the GTK tray monitor
and is problematic because I don't like working on GTK (makes it harder) and
I am not familar with the code. I doubt that there is any BSD GTK tray
monitor code Sad

If you do not build the tray monitor binary with OpenSSL
this will eliminate that problem.

Regards,

Kern

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

Thomas Dickey · External Since: Aug 09, 2006 Posts: 96

Simon Josefsson <simon.RemoveThis@josefsson.org> wrote:
> Kern Sibbald <kern.RemoveThis@sibbald.com> writes:

>>> GPL + OpenSSL exception would be enough to be sure. You may have more
>>> luck convincing copyright owners to grant an OpenSSL exception than to
>>> accept an entirely new license.
>>
>> I am told that FSF never grants exceptions so this is a hopeless path that I
>> have already explored.

> That is incorrect. The FSF has granted OpenSSL license exceptions to
> some software that links to OpenSSL. For example, GNU wget.

That's not an example (unless you're intending to show a case where
FSF allows itself to do things that it forbids others Wink

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

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

Shane M. Coughlan · External Since: Jul 12, 2007 Posts: 9

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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 am discussing this in detail with Brett Smith of FSF.

Kern Sibbald wrote:
> OK, I think the possible solutions are pretty clear to me. Thank you
for the
> rapid response.

No problem.

Kern, if it would be useful to you I can arrange a physical meeting or
telephone call to discuss these things in more detail. After all, we
are only a few kilometres from each other in Switzerland and we might be
able to explore options more quickly that way.

Regards

Shane

- --
Shane Coughlan
FTF Coordinator
Free Software Foundation Europe
Office: +41435000366 ext 408 / Mobile: +41792633406
coughlan DeleteThis @fsfeurope.org
Support Free Software > http://fsfe.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iQCVAwUBRpkLutGa7CzA5hXyAQKT5AQAnm8Rf+mzyNtRf29/zhrT/PNQ5agRlJyn
zN7LGecsMiFlCfEPI/0OAeu4Y4rE56QnFiJJQjEp4gUw7ybKeNFzCguLegBIUyoi
HME3kurobaAgBKA1Bt6dZClE4N1bQ3u9sVmhH9QjWL+HU4ldoLtI6OduqBDNUyin
H3OOojb1/Jw=
=qI0F
-----END PGP SIGNATURE-----

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

Shane M. Coughlan · External Since: Jul 12, 2007 Posts: 9

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Kern

Kern Sibbald wrote:
> On Saturday 14 July 2007 11:03, Simon Josefsson wrote:
>> That is incorrect. The FSF has granted OpenSSL license exceptions to
>> some software that links to OpenSSL. For example, GNU wget.
>
> Interesting. Shane would you comment on this?

As Simon said, in certain special circumstances selected GNU tools
related to networking have been granted exceptions. I suggest that such
a grant is not likely in the case of the general purpose code included
with Bacula.

However, please bear in mind that I don't speak for FSF Smile

> In addition, there are two files copyrighted by Anders Carlsson, two by Sun
> Microsystems in the tray-monitor directory, and a number of files by AT&T
> all in the win32 subdirectories.

All of the authors of third-party code would need to be contacted for a
linking exception, though from your last email it sounds like you have
already removed a substantial amount of the third-party code.

I have some availability this week. I could do a physical meeting or a
phone call during Wednesday and Thursday afternoon if you think it would
be useful. Smile

Regards

Shane

- --
Shane Coughlan
FTF Coordinator
Free Software Foundation Europe
Office: +41435000366 ext 408 / Mobile: +41792633406
coughlan.RemoveThis@fsfeurope.org
Support Free Software > http://fsfe.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iQCVAwUBRpszBdGa7CzA5hXyAQJjYAQA4eT1gTBTujQ89GyIXlMFmBd8ONJEO4Bn
fQrn70lo4WkhFPlzWGnlm28JqAlzEH/Q31FDAntVScMf9AXEpGysIL62Y0E7Q80u
bLnJwBfWfinOTtXw07qywiG9g6dqyxFHlB7mzg9rj3JbUyafsitlGveOUKpV7tf3
DKwLekVRt3U=
=DrGS
-----END PGP SIGNATURE-----

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

Kern Sibbald · External Since: Jun 29, 2006 Posts: 43

On Monday 16 July 2007 10:57, Shane M. Coughlan wrote:
> Hi Kern
>
> Kern Sibbald wrote:
> > On Saturday 14 July 2007 11:03, Simon Josefsson wrote:
> >> That is incorrect. The FSF has granted OpenSSL license exceptions to
> >> some software that links to OpenSSL. For example, GNU wget.
> >
> > Interesting. Shane would you comment on this?
>
> As Simon said, in certain special circumstances selected GNU tools
> related to networking have been granted exceptions. I suggest that such
> a grant is not likely in the case of the general purpose code included
> with Bacula.
>
> However, please bear in mind that I don't speak for FSF Smile

Yes, and in addition, after Josselin's email, I did a bit of research, and for
at least one of the files that we use (fnmatch.c), the FSF license was
changed from GPL to LGPL sometime in 2004 the best I can tell.
Unfortunately, we are still using the old GPL'ed version rather than the
newer LGPL'ed version.

While it would be best to convert to the newer version, it is not so easy as
the we have made some modifications to the old one to support Win32 systems
(stupid difference of path separators, ...).

Question: for old GPL'ed versions of fnmatch.c and fnmatch.h that we are using
copyrighted in 1997 by FSF, would it be possible to modify them to use the
LGPL as you are currently doing?

That would give me a bit of breathing room (i.e. no recoding for the moment).
Long term, I am probably going to use your newer LGPLed version since it
supports UTF-8, but that will take some modifications and lots of testing.

>
> > In addition, there are two files copyrighted by Anders Carlsson, two by
Sun
> > Microsystems in the tray-monitor directory, and a number of files by AT&T
> > all in the win32 subdirectories.
>
> All of the authors of third-party code would need to be contacted for a
> linking exception, though from your last email it sounds like you have
> already removed a substantial amount of the third-party code.

Yes, all the authors would have to be contacted, but given they involve
institutions such as FSF and ATT and Sun, I don't plan to go that route, it
has little chance of succeeding.

For files like fnmatch.c where FSF has already changed the license, I think it
makes sense to ask for a change to the old code. For all the rest, I will
work on replacing the files and/or rewriting them myself. It is a terrible
waste of time, but it is not a monster project, and the only hard part is the
testing that will be necessary to validate the changes ...

>
> I have some availability this week. I could do a physical meeting or a
> phone call during Wednesday and Thursday afternoon if you think it would
> be useful. Smile

I appreciate your offer, and I think that meeting at some point will be
important, especially if FSF is willing to put the older fnmatch.c/h that we
use under the LGPL license that is being used by the current version.

However, one important issue to work through is Josselin's claim that due to
the wording in GPL v3, I could switch to it, and it would be OK to link
OpenSSL in as shared objects.

If that is the case, it would provide a short term solution to this problem so
that Debian can continue to release Bacula with OpenSSL enabled in the next
version.

Switching to GPL v3 is something I could do before the next release (in a week
or two), but I would do it only if I can get FSFE and Debian to confirm that
it will resolve the OpenSSL linking problem -- for the moment, I don't have
any "official" confirmation from either of you.

Longer term, I am definitely removing all 3rd party copyrighted code that is
GPL'ed, and unless GPL v3 turns out to be the magic bullet and does not
encomber me with additional constraints, I'll either add back the OpenSSL
modification I previously added for Debian, or switch to a less restrictive
Open Source License such as Sun's. I'm still looking at other licenses and
switching will require a good deal of thought ...

Before swtiching to any other license, should that be the case, and possibly
before adding any license modifications, Shane and I will very likely need to
meet.

Regards,

Kern

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

Shane M. Coughlan · External Since: Jul 12, 2007 Posts: 9

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Kern

Kern Sibbald wrote:
> Yes, and in addition, after Josselin's email, I did a bit of research, and for
> at least one of the files that we use (fnmatch.c), the FSF license was
> changed from GPL to LGPL sometime in 2004 the best I can tell.
> Unfortunately, we are still using the old GPL'ed version rather than the
> newer LGPL'ed version.
> While it would be best to convert to the newer version, it is not so easy as
> the we have made some modifications to the old one to support Win32 systems
> (stupid difference of path separators, ...).
> Question: for old GPL'ed versions of fnmatch.c and fnmatch.h that we are using
> copyrighted in 1997 by FSF, would it be possible to modify them to use the
> LGPL as you are currently doing?
> That would give me a bit of breathing room (i.e. no recoding for the moment).
> Long term, I am probably going to use your newer LGPLed version since it
> supports UTF-8, but that will take some modifications and lots of testing.

FSF would need to answer this question directly. FSF and FSFE are
sister organisations but we are administratively separate. I will pass
this question onward off-list. Smile

> However, one important issue to work through is Josselin's claim that due to
> the wording in GPL v3, I could switch to it, and it would be OK to link
> OpenSSL in as shared objects.

I am discussing this with Brett Smith at the moment.

Regards

Shane

- --
Shane Coughlan
FTF Coordinator
Free Software Foundation Europe
Office: +41435000366 ext 408 / Mobile: +41792633406
coughlan DeleteThis @fsfeurope.org
Support Free Software > http://fsfe.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iQCVAwUBRpuLqNGa7CzA5hXyAQL84gP8DyjLbDbgKtoyXdvIukFnmOzgBjcs6EsF
oQ3eLqo/mml21UfowSBjYWo6xFePogi+ILhfWfq3eDJ6bYEP+ilysQtgfeHXxxx1
sVbTSHfS+hOtIdnsiCZ6j2O10jYaBMEIedJKkakWHXCbaYwYzvZNGOfC9Nxle8Fz
/8q6YlR2R0s=
=6XPy
-----END PGP SIGNATURE-----

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

Kern Sibbald · External Since: Jun 29, 2006 Posts: 43

On Monday 16 July 2007 17:15, Shane M. Coughlan wrote:
> Hi Kern
>
> Kern Sibbald wrote:
> > Yes, and in addition, after Josselin's email, I did a bit of research, and
for
> > at least one of the files that we use (fnmatch.c), the FSF license was
> > changed from GPL to LGPL sometime in 2004 the best I can tell.
> > Unfortunately, we are still using the old GPL'ed version rather than the
> > newer LGPL'ed version.
> > While it would be best to convert to the newer version, it is not so easy
as
> > the we have made some modifications to the old one to support Win32
systems
> > (stupid difference of path separators, ...).
> > Question: for old GPL'ed versions of fnmatch.c and fnmatch.h that we are
using
> > copyrighted in 1997 by FSF, would it be possible to modify them to use the
> > LGPL as you are currently doing?
> > That would give me a bit of breathing room (i.e. no recoding for the
moment).
> > Long term, I am probably going to use your newer LGPLed version since it
> > supports UTF-8, but that will take some modifications and lots of testing.
>
> FSF would need to answer this question directly. FSF and FSFE are
> sister organisations but we are administratively separate. I will pass
> this question onward off-list. Smile

OK, understood thanks. This is not really extremely urgent since its
determination will not change the immenent 2.2.0 release.

>
> > However, one important issue to work through is Josselin's claim that due
to
> > the wording in GPL v3, I could switch to it, and it would be OK to link
> > OpenSSL in as shared objects.
>
> I am discussing this with Brett Smith at the moment.

Thanks. This point is important (pressing) as it could provide a quick
solution for Debian.

Best regards,

Kern

>
> Regards
>
> Shane
>
> --
> Shane Coughlan
> FTF Coordinator
> Free Software Foundation Europe
> Office: +41435000366 ext 408 / Mobile: +41792633406
> coughlan.RemoveThis@fsfeurope.org
> Support Free Software > http://fsfe.org
>

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