[bind10-dev] [svn] commit: r1108 - in /branches/each-nsec3/src/lib/dns/cpp: Makefile.am base32.cc base32.h sha1.cc sha1.h tests/Makefile.am tests/base32_unittest.cc tests/sha1_unittest.cc

[JINMEI Tatuya / 神明達哉]

At Thu, 4 Mar 2010 15:33:54 +0000,
Evan Hunt <each at isc.org> wrote:

> > But, the code the sha1 is based on is not open source -- well at least 
> > the license is unclear. It does not say we have the right to modify nor 
> > distribute the modified code.
> 
> RFC 5378, Section 5.3:
> 
>   To the extent that a Contribution or any portion thereof is protected
>   by copyright or other rights of authorship, the Contributor and each
>   named co-Contributor grant a perpetual, irrevocable, non-exclusive,
>   royalty-free, world-wide, sublicensable right and license to the IETF
>   Trust under all such copyrights and other rights in the Contribution:
>    [...]
>    c. to modify or prepare derivative works (in addition to
>       translations) that are based on or incorporate all or part of the
>       Contribution, and to copy, publish, display, and distribute such
>       derivative works, or portions thereof unless explicitly disallowed
>       in the notices contained in a Contribution (in the form specified
>       by the Legend Instructions)

The "derivative work" part of the RFC had been substantially changed
in recent versions of this RFC.  We cannot assume this in its literal
sense for RFCs that are not explicitly covered by this version of RFC.

I encountered this issue about copying part of API RFCs into man pages
when I worked on an open source project for IPv6 protocol stack.  We
consulted the IAB and lawyers, and the conclusion was we should drop
the copy and write everything from the scratch.

IIRC, this was one of the reasons why the contributor rights RFC was
revised about derivative works.  Even though everyone agreed the
revised version represents the original intent (rather than amends
it), lawyers may not agree.

I don't know the copied SHA1 code is explicitly covered by the latest
version of RFC, but if not, I suggest we take a safer approach, e.g.
reuse BIND9's lib/isc/sha1.c for this short term purpose.

---
JINMEI, Tatuya