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

Re: Bacula and OpenSSL

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 
> > 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 
> > mean that there should be no problem with GPL v2.  However, I know as a 
> > 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 
> > 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 
> > 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.

Reply to: