Re: ITP: BIND 9

[Bdale Garbee <bdale@gag.com>]

Paul, David,

As the BIND package maintainer for Debian GNU/Linux, I intend to build 
initial packages of BIND 9 shortly, in parallel with continued support for 
8.2.X.  

I indicated in my "intent to package" announcement to the debian-devel 
mailing list that I had not yet reviewed the licenses on the various pieces.  
I have now done so, as the following message indicates.  I am disappointed by
the results.

I would very much like to work with you to ensure that we can ship BIND 9 
with Debian.  I currently must use the 'noesw' target in the 8.2.2p5 
top-level Makefile to allow distribution of BIND 8 with Debian.

As a reminder, our Social Contract and accompanying Debian Free
Software Guidelines, which were used as the basis for the Open Source
Definition, are online at http://www.debian.org/social_contract .

In article <[🔎] 87em4vwhr3.fsf@hoss.orcus.priv.at> you wrote:

> Why does the (non)existence of crypto code in a package make it
> DFSG-compliant?

All the information anyone needs about BIND's DFSG compliance is in the 
debian-devel archives.  The short version is that the fact that it's crypto     
is irrelevant, that just happens to be the library in the 8.2.2 sources that    
is not DFSG compliant.

The same non-DFSG-compliant code *is* in the BIND 9 first release candidate.

I used a fairly simple find/grep process to locate all the copyright notices
in the source tree, and filter out the obviously-ok ones.  The two pieces I
was left pondering are

        lib/dns/sec/dnssafe

                This appears to be is the same RSA Data Security, Inc., code 
		that was in 8.2.2 and which is clearly not DFSG-compliant.

                If BIND cannot be built without this library (either by not
                providing the functionality, or by finding a DFSG-compliant
                replacement), then BIND 9 will not be distributable as part     
                of Debian main.

        lib/dns/sec/openssl

                This appears to carry one of those annoying "BSD with 
                advertising clause" licenses.  However, if I assume it's the
                same stuff that's in our openssl package, and it's ok for that
                to be in non-US/main, it's probably ok here, too.

One of the subdirectory README files refers to a COPYRIGHT file in the root of
the source tree that is not present.  I encourage the ISC to provide a  file 
in the source tree explicitly calling out the distribution terms for the
various pieces.  I also think it's mandatory for the dnssafe files to be
accompanied in the source tree by a copy of the explicit license from RSADSI.

Bdale