Backup Central

On Thu, 2007-06-07 at 11:38 +0200, Kern Sibbald wrote:
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.

Is it possible to provide some kind of placeholder instead that can be
replaced with working versions by the end user? Fedora includes the app.
Xmms with a dummy mp3 plugin which has to be replaced if you want to
play mp3s.

/Jens



Best regards,

Kern



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bacula-devel mailing list
Bacula-devel < at > li...
https://lists.sourceforge.net/lists/listinfo/bacula-devel

On Thursday 07 June 2007 11:53, Jens R. Victorin wrote:
On Thu, 2007-06-07 at 11:38 +0200, Kern Sibbald wrote:
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.

Is it possible to provide some kind of placeholder instead that can be
replaced with working versions by the end user? Fedora includes the app.
Xmms with a dummy mp3 plugin which has to be replaced if you want to
play mp3s.

Yes, but it is a lot of work that IMO should not be necessary -- after all
OpenSSL is Open Source. The other point is that for rpm users this would be
a real pain. Imagine that you want encryption, but after installing all the
rpms, now you either have to build an OpenSSL shared object or you must link
Bacula. Not very good.


/Jens



Best regards,

Kern



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bacula-devel mailing list
Bacula-devel < at > li...
https://lists.sourceforge.net/lists/listinfo/bacula-devel


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bacula-devel mailing list
Bacula-devel < at > li...
https://lists.sourceforge.net/lists/listinfo/bacula-devel

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

Sounds good so far.

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

So which 8 files are these and can they be re-written? Maybe I'm
misunderstanding what you mean by "Pure GPL" code? Are these files
from software released by the GNU organization?

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

Sure, I can understand this.

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

Yup, Openssl uses the Apache license.

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

So basically, you're saying that people who contribute code to bacula
under the GPL license (which is what they need to do to get it
distributed) can't contribute anymore?

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

Ah... now I see, it's the static linking part which causes the
problems.

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

It's an interesting point for sure. In this case, it all hinges on
the OpenSSL people and their use of the Apache license. Which I would
assume would actually be a bigger issue since Apache uses that license
and I'm SURE that there are alot more Apache setups out there than
Bacula.

So how does Debian/Fedora work around Apache using the MySQL libraries
with the openssl stuff? Or do they just punt because Apache (as they
distribute it) only does dynamic linking?

Honestly, I think you're over-reacting here to closing down
submissions from people. Just make sure they understand that they
must make all submissions be part of the license that Bacula itself is
under, which is the modified GPLv2 license.

I assume, since I haven't checked, that you are licensed like the
Linux Kernel to specifically use "GPLv2 only" and not the "GPLv2 or
later" clause that most GNU programs have?

Thanks,
John

On Thursday 07 June 2007 22:27, John Stoffel wrote:

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

Sounds good so far.

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

So which 8 files are these and can they be re-written? Maybe I'm
misunderstanding what you mean by "Pure GPL" code?

By pure GPL code, I meant code that has a non-modified GPL license (and is
copyrighted by other people).

Are these files
from software released by the GNU organization?

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

Sure, I can understand this.

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

Yup, Openssl uses the Apache license.

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

So basically, you're saying that people who contribute code to bacula
under the GPL license (which is what they need to do to get it
distributed) can't contribute anymore?

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

Ah... now I see, it's the static linking part which causes the
problems.

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

It's an interesting point for sure. In this case, it all hinges on
the OpenSSL people and their use of the Apache license. Which I would
assume would actually be a bigger issue since Apache uses that license
and I'm SURE that there are alot more Apache setups out there than
Bacula.

So how does Debian/Fedora work around Apache using the MySQL libraries
with the openssl stuff? Or do they just punt because Apache (as they
distribute it) only does dynamic linking?

Honestly, I think you're over-reacting here to closing down
submissions from people.

I never said that I was closing down submissions from people. I said that I
was not accepting any GPL'ed code. Submissions come from people who have
transferred their copyright.

Just make sure they understand that they
must make all submissions be part of the license that Bacula itself is
under, which is the modified GPLv2 license.

I assume, since I haven't checked, that you are licensed like the
Linux Kernel to specifically use "GPLv2 only" and not the "GPLv2 or
later" clause that most GNU programs have?

Yes, I don't believe in writing a blank check.

Attachments: novosirj.vcf

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

Kern Sibbald wrote:
On Thursday 07 June 2007 22:27, John Stoffel wrote:
Kern> As you probably know, Bacula is released with a modified GNU GPL
Kern> licence. The Bacula license modifies the GPL to permit Bacula
Kern> to link to OpenSSL. This was necessary because using MySQL
Kern> libraries requires OpenSSL. This modification was suggested by
Kern> Debian to bring Bacula in compliance with their procedures.

Sounds good so far.

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

So which 8 files are these and can they be re-written? Maybe I'm
misunderstanding what you mean by "Pure GPL" code?

By pure GPL code, I meant code that has a non-modified GPL license (and is
copyrighted by other people).

Are these files
from software released by the GNU organization?

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

Sure, I can understand this.

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

Yup, Openssl uses the Apache license.

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

So basically, you're saying that people who contribute code to bacula
under the GPL license (which is what they need to do to get it
distributed) can't contribute anymore?

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

Ah... now I see, it's the static linking part which causes the
problems.

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

It's an interesting point for sure. In this case, it all hinges on
the OpenSSL people and their use of the Apache license. Which I would
assume would actually be a bigger issue since Apache uses that license
and I'm SURE that there are alot more Apache setups out there than
Bacula.

So how does Debian/Fedora work around Apache using the MySQL libraries
with the openssl stuff? Or do they just punt because Apache (as they
distribute it) only does dynamic linking?

Honestly, I think you're over-reacting here to closing down
submissions from people.

I never said that I was closing down submissions from people. I said that I
was not accepting any GPL'ed code. Submissions come from people who have
transferred their copyright.

Would this only, the, apply to programmers who had written something
previously that was applicable to backups and then inserted into Bacula,
or perhaps situations in which people wrote code that was intended for
Bacula, but then instead of just making it part of the Bacula project,
they independently copyrighted it?

It's unclear to me what a developer would need to do differently.
Granted this doesn't matter a whole lot to me as I don't really do any
programming, but I'm curious as the explanation is a little confusing.
I'm not sure if that's just me since I'm unfamiliar with this stuff, or
whether it's the description.

Thanks!

- --
---- _ _ _ _ ___ _ _ _
|Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Systems Programmer III
|$&| |__| | | |__/ | \| _| |novosirj < at > um... - 973/972.0922 (2-0922)
\__/ Univ. of Med. and Dent.|IST/AST - NJMS Medical Science Bldg - C630
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGaLD4mb+gadEcsb4RAkIxAKC5GoGpIXRXOz9PKuYamEP+imADHwCfcOcA
W8oCPgyHu2GlgHN+4/K6sQM=
=wR9g
-----END PGP SIGNATURE-----

On Friday 08 June 2007 03:29, Ryan Novosielski wrote:
Kern Sibbald wrote:
On Thursday 07 June 2007 22:27, John Stoffel wrote:
Kern> As you probably know, Bacula is released with a modified GNU GPL
Kern> licence. The Bacula license modifies the GPL to permit Bacula
Kern> to link to OpenSSL. This was necessary because using MySQL
Kern> libraries requires OpenSSL. This modification was suggested by
Kern> Debian to bring Bacula in compliance with their procedures.

Sounds good so far.

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

So which 8 files are these and can they be re-written? Maybe I'm
misunderstanding what you mean by "Pure GPL" code?

By pure GPL code, I meant code that has a non-modified GPL license (and is
copyrighted by other people).

Are these files
from software released by the GNU organization?

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

Sure, I can understand this.

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

Yup, Openssl uses the Apache license.

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

So basically, you're saying that people who contribute code to bacula
under the GPL license (which is what they need to do to get it
distributed) can't contribute anymore?

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

Ah... now I see, it's the static linking part which causes the
problems.

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

It's an interesting point for sure. In this case, it all hinges on
the OpenSSL people and their use of the Apache license. Which I would
assume would actually be a bigger issue since Apache uses that license
and I'm SURE that there are alot more Apache setups out there than
Bacula.

So how does Debian/Fedora work around Apache using the MySQL libraries
with the openssl stuff? Or do they just punt because Apache (as they
distribute it) only does dynamic linking?

Honestly, I think you're over-reacting here to closing down
submissions from people.

I never said that I was closing down submissions from people. I said that
I
was not accepting any GPL'ed code. Submissions come from people who have
transferred their copyright.

Would this only, the, apply to programmers who had written something
previously that was applicable to backups and then inserted into Bacula,
or perhaps situations in which people wrote code that was intended for
Bacula, but then instead of just making it part of the Bacula project,
they independently copyrighted it?

There is no problem with code written by a Bacula developer who submits it
because he has filled out a FLA (i.e. transferred the copyright to FSFE).
The problem is in taking code developped by other people that is copyrighted
by them and using that code in Bacula without having a copyright assignment.


It's unclear to me what a developer would need to do differently.
Granted this doesn't matter a whole lot to me as I don't really do any
programming, but I'm curious as the explanation is a little confusing.
I'm not sure if that's just me since I'm unfamiliar with this stuff, or
whether it's the description.

Yes, I agree the whole thing is confusing and frustrating.


Thanks!

--
---- _ _ _ _ ___ _ _ _
|Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Systems Programmer III
|$&| |__| | | |__/ | \| _| |novosirj < at > um... - 973/972.0922 (2-0922)
\__/ Univ. of Med. and Dent.|IST/AST - NJMS Medical Science Bldg - C630