[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bacula: GPL and OpenSSL



On Thursday 07 June 2007 19:00, Michael Poole wrote:
> John Goerzen writes:
> 
> > Kern approached me about this situation (see full correspondence below,
> > forwarded with his permission).  He added that Bacula does not
> > statically link with OpenSSL, that OpenSSL support can be disabled at
> > build time, and that FSFE does not believe that an exception clause to
> > the GPL is necessary to legally link to OpenSSL in the manner that
> > Bacula is (dynamic linking).  Further, could we not consider OpenSSL to
> > be a major component of the OS on which the executable runs, and thus
> > fall under that exemption in the GPL anyway?
> >
> > I have not been able to pull up a succinct statement of why Debian
> > believes this is a problem when FSFE doesn't, or what we ought to do.
> > Can somebody please comment on the OpenSSL linking issue when OpenSSL is
> > only dynamically linked?
> 
> Debian generally distributes OpenSSL logically near the packages that
> dynamically link against it, so the major system component option is
> not available to Debian ("... unless that component itself accompanies
> the executable").
> 
> GPL section 3(a) also uses "accompany" in a way that Debian and others
> interpret to include distribution in the same directory tree on a
> particular server, so -- the usual line of reasoning goes -- it would
> be inconsistent to interpret "accompany" one way at the start of
> section 3 and a different way at the end of section 3.

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, nor is Bacula in the 
same directory tree as any OpenSSL shared object unless you consider 
everything is under root thus everything on the server is in the same 
directory "tree".

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 Source 
(i.e. I can get it, see it and modify it), I have no problem with it being 
linked with Bacula. 

I modified the Bacula GPL license at Debian's request to remove the issue you 
find with OpenSSL, however, that created a much bigger problem for me -- it 
made Bacula in violation of other peoples GPLed code that is used in Bacula.  
As a consequence, I removed all Bacula modifications to the GPL making Bacula 
clean -- it violates no one's license.  Each person, distributor, packager 
can decide for himself whether or not to enable Bacula to use encryption.  At 
the current time if encryption is turned on, Bacula expects an OpenSSL 
interface.

I much appreciate that Debian has for a long time packaged Bacula as part of 
the Debian system.  If it were only a simple matter of keeping that clause 
rather than a question of violating other people's copyright, I would keep 
the clause despite what Fedora/Red Hat think/want.  So, sorry if this causes 
you problems, but I prefer to be in compliance.

Best regards,

Kern



Reply to: