Re: ITP: BIND 9
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
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
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 <firstname.lastname@example.org> you wrote:
> Why does the (non)existence of crypto code in a package make it
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
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.
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.