Re: Export registration

[Andy Seaborne <an...@apache.org>]

Process executed and notice to US Gov sent.

I've also written to legal-discuss@ to check whats beendone. If theer is 
feedback there, I might need to refine the entry on the ASF exports page.

Thanks to Stian for making sure this was done.

     Andy

On 30/10/16 15:42, Stian Soiland-Reyes wrote:
> http://www.bis.doc.gov/index.php/policy-guidance/encryption/identifying-encryption-items
> says
>
>> Is the item designed to use cryptography or does it contain cryptography?
>
>> Almost all items controlled under Category 5, Part 2 of the EAR are controlled because they include encryption functionality. Items may be controlled as encryption items even if the encryption is actually performed by the operating system, an external library, a third-party product or a cryptographic processor. If an item uses encryption functionality, whether or not the code that performs the encryption is included with the item, then BIS evaluates the item based on the encryption functionality it uses.
>
> Similarly, if the item includes encryption functionality, even if the
> encryption functionality is not used by the item, then BIS evaluates
> the item based on the included encryption functionality.
>
>
> So "include encryption functionality" would be the case for the binary
> dists that embed Jetty, etc.
>
> If it is not included (as in the source code) then it's evaluated on
> which encryption functionality that is used - which would not be
> directly used by Jena's source code, but by HTTP Client's support for
> HTTPS etc. (We only use the HTTP Client encryption ITEM rather than
> the HTTP Client encryption FUNCTIONALITY). So I think you are right in
> the approach you suggest.
>
>
>
> On 30 October 2016 at 13:56, Andy Seaborne <an...@apache.org> wrote:
>> Jena does not implement any cryptographic but we do bundle dependencies that
>> include such software in the binary distributions for HTTPS and for web app
>> security (Shiro).
>>
>> Plan:
>>
>> 1/ Include a "Cryptographic Software Notice" in each of the binary
>> distribution README files.
>>
>>     apache-jena/dist/README
>>     jena-fuseki2/apache-jena-fuseki/README
>>     jena-fuseki1/apache-jena-fuseki/README
>>
>> This part is Apache-required and not part of the US export registration
>> process.
>>
>> The software bundled concerned is
>>   Apache HttpClient
>>   Apache HttpComponents Core
>>   Eclipse Jetty
>>   Apache Shiro
>>
>> PR#187
>>
>> 2/ Register a product
>>
>> NB "version" has a specific means, more like "usage"
>>
>> "Apache Jena (distribution)"
>>   Versions: development
>>             [for the snapshot maven repo]
>>             binary distribution
>>             [for the binaries and release maven repo]
>>
>> and send required email to the required US gov organisations and Apache
>> lists.
>>
>> ----
>>
>> I thought about 3 products (apache-jena, fuseki1, fuseki2). For stability,
>> the links ended up to the gernal area of repo or archives (as other projects
>> also have it) so 3 products did not make anything better.
>>
>> I also looked at various other projects - things are not uniform. Theer are
>> cases of "over register" where the crypto notice in the code base README.
>> That's unhelpful when the project itself does not provide crypto software
>> and wrong when the source-release gets made (it goes not contain any such
>> software). Like NOTICE, being minimal seemed more in the spirit of things.
>>
>>         Andy
>>
>> [1] http://www.apache.org/dev/crypto.html
>> [2] http://www.apache.org/licenses/exports/
>
>
>