SHA1 implementation by Steve Reid

2017-11-09 Thread Carsten Leonhardt
Hi, the bacula upstream sources contain the SHA1 implementation from the RFC. For the Debian packages, we delete the files sha1.* and repackage the source (for the complete history, see bug #658326). Using codesearch, I found that other packages use the implementation by Steve Reid and submitted

Re: SHA1 implementation by Steve Reid

2017-11-09 Thread Carsten Leonhardt
Florian Weimer writes: > The apparent intent, as evidenced by the copyright statement in the > source code parts of RFC 6234, is that the code parts are available > under that licensing option, even though they are not otherwise marked > as code components under the TLP. So in essence the code i

Re: SHA1 implementation by Steve Reid

2017-11-10 Thread Carsten Leonhardt
Florian Weimer writes: > * Carsten Leonhardt: > >> Florian Weimer writes: >> >>> The apparent intent, as evidenced by the copyright statement in the >>> source code parts of RFC 6234, is that the code parts are available >>> under that licensing opti

Re: SHA1 implementation by Steve Reid

2017-11-15 Thread Carsten Leonhardt
Ian Jackson 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 pre

Re: SHA1 implementation by Steve Reid

2017-11-16 Thread Carsten Leonhardt
Ian Jackson writes: > The main point of my message, which you are replying to, was that: > this is pointless makework. > 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. Thank you for this very