Carsten Leonhardt writes ("Re: SHA1 implementation by Steve Reid"):
> Ian Jackson <ijack...@chiark.greenend.org.uk> writes:
> > And, if at any point in the future somebody takes a more legalistic
> > view and starts sending takedown notices, we can just throw away our
> > existing version based on the old RFC's code and redo the integration
> > using the nearly-identical code from the new RFC.
>
> Hm, the previous maintainers of bacula removed the code because of bug
> #658326, submitted 2012-02-02. The new RFC 6234 is dated "May 2011", so
> before the bug report.
There is no evidence in #658326 that anyone was aware of the new RFC.
> > So there is, I think, very little risk to us or our downstreams, of
> > leaving this situation as is - ie, there is no point going and trying
> > to weed out code based on the old RFC (even if we could somehow
> > reliably determine whether some code was based on the old RFC
> > directly, or via the new RFC with the better licence).
>
> I'll point upstream to this thread and ask if he'd consider using the
> code from the new RFC.
The main point of my message, which you are replying to, was that:
this is pointless makework.
> (By the way, the situation "as is" is to repackage the upstream source,
> removing sha1.[ch].)
If I were the Bacula maintainer I would drop the sha*.[ch]-related
Debian delta, in my next upload, based on the arguments I make in this
thread.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
