Re: enabling transport and on storage encryption in bacula on debian build
* Kern Sibbald:
> Problems of mismatched licenses apparently occur when forming and
> distributing a "mixed" binary program or when mixing different
> licenced source code in the same file and distributing it. As far
> as I know Bacula 2.4.x does not mix source code with different
> licenses in the same source file (we simply call libraries that when
> executed are incompatible), and Debian as well as its derivatives
> have decided not to form a Bacula binary using the offending
> libraries.
Some folks claim that merely referencing a dynamic shared object makes
a program a derived work of the dynamic shared object. In my opinion,
this is an argument based on an extensionist copyright policy, and I
therefore reject it. However, something like this is necessary to
preserve the self-enforcing nature of the various GPL versions for
dynamic shared objects (and other library code which is only
incorporated per reference). As a result, the
derived-work-by-reference concept has several prominent followers,
including the FSF.
The OpenSSL situation is special because it's the only relict of the
old BSD-vs-GPL fight which is still relevant. It's a real shame that
this was not solved in the GPL renewal process, but this was
predictable. But it still hurts that the FSF does not want us to ship
software released under the GPL which uses the OpenSSL library, but
has no problem with proprietary software vendors shipping compiled
third-party programs licensed under the GPL which are linked to
proprietary system libraries, perhaps even including a copy of
OpenSSL. There is something seriously wrong about this.
In short, I share your frustration, but I also think that the John's
decision is quite reasonable.
Reply to: