Armchair opinion: I'm not sure it matters how you get cryptographic functions. If they are used in your code, it may be prudent to go through the registration process or at least obtain assurance sure that use of libraries that you don't distribute is excluded.
However, you might not be doing anything that fits inside the requirements for the export-control steps in the first place. (Computing digest values using hash algorithms is usually not considered cryptography, for example.) It is wise to simply review all of the requirements and see what applies and then go through the process if still necessary to remove all doubt. This is probably someplace where any assertion needs to be revisited for each release, just as the IP-clearance attestation has to be revisited. - Dennis -----Original Message----- From: Andy Seaborne [mailto:[email protected]] On Behalf Of Andy Seaborne Sent: Tuesday, November 22, 2011 04:34 To: [email protected] Subject: Re: Handling Cryptography within an ASF Release (Was: Re: Project setup) Where are we on this? Do we need an entry in /licenses/exports/? Would it be helpful even if not needed? (I think that's a "yes") As far as I know, we only use std Java stuff (there will be no need for an additional jar for ARQ). Andy On 28/10/11 13:15, Paolo Castagna wrote: > Andy Seaborne wrote: > > There various tasks that we wil have to do sometime, e.g. "Handling > > Cryptography within an ASF Release" > > > > http://www.apache.org/dev/crypto.html > > http://www.apache.org/licenses/exports/ > > In relation to this, I am not sure what we need to do. > > I think we are good with Apache Jena... but some confirmation > on this would be good. I know we briefly touched on this already: > http://markmail.org/search/?q=ECCN%20jena > > Andy, are you aware of specific tasks we need to do for Jena in > relation to this? > > Paolo > > > > > Andy >
smime.p7s
Description: S/MIME cryptographic signature
