[jira] [Resolved] (LEGAL-250) US Export declaration of transitive dependencies?

["Stian Soiland-Reyes (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/LEGAL-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stian Soiland-Reyes resolved LEGAL-250.
---------------------------------------
    Resolution: Done

> US Export declaration of transitive dependencies?
> -------------------------------------------------
>
>                 Key: LEGAL-250
>                 URL: https://issues.apache.org/jira/browse/LEGAL-250
>             Project: Legal Discuss
>          Issue Type: Question
>            Reporter: Stian Soiland-Reyes
>
> Hi,
> I'm preparing the changes to eccnmatrix.xml for Apache Taverna (TAVERNA-959) - my current draft is at
> https://cwiki.apache.org/confluence/display/TAVERNADEV/Taverna+Cryptography+review
> Would you be able to help me review this? I was hoping to make it a bit shorter..
> I assume formally it would need to be the Incubator PMC who sends the email registration?
> At first we thought we would only need to declare our use of the Bouncy Castle encryption library (as used by Taverna Engine's Credential Manager to store a keychain) - however now I wonder if we need to also list any Apache dependencies that themselves are also listed on http://www.apache.org/licenses/exports/ (e.g. CXF, HTTP Components, WSS4J, XML Security) - or if they are exempt if you are not specifically using the encryption functionality?
> That is - a dependency like Apache HTTP Components have code to deal with SSL and JSSE - and is therefore classified. We use Apache Jena which rely on JSONLD-JAva which rely on HTTP Component just for network access (potentially loading from https://) - but we don't use that network access from Taverna code. Do we still list HTTP Component (and potentially Jena and JSONLD-Java) as classified?
> Does it make a difference if a classified item is used as a <dependency> in a source release, or if the JAR of the classified item is included in a binary distribution for dist?
> This would affect loads of projects - e.g. Jena binaries redistribute Apache HTTP Components (JENA-1169) - but doesn't do anything particular with encryption (except supporting RDF files hosted at https://) -- 
> Complicating matters is that Taverna have multiple git repositories - so if interpreted strictly all Taverna components that somehow depend on the classified Taverna component also become affected (even if they don't actually import taverna-credential-manager-impl) - do we need to list them all?   There is a lot of repetition - so I added just a single <Version> for all the "development" - even though each git repository has a different versioning scheme.  
> But do I still need to transitively expand the <Why> from its dependencies' dependencies, or is it enough to list what the item directly uses?  (e.g. taverna-plugin-bioinformatics just needs to list "use with Apache Taverna Engine" which then implies the other Taverna modules and JSSE, JCE, BouncyCastle  and HTTP Components?)
> I assume an indirection to http://taverna.incubator.apache.org/download/code/ is not valid and I need to list each of our git repositories? 
> I see for dist it's common practice to just link to the top-level tree which simplifies the release <Version> - however I was unable to give it a single version number so I just called it "All releases" - see https://archive.apache.org/dist/incubator/taverna/source/  
> Sorry for the long email.. I've been pondering on this all night long :)
> It sounds to me like we need some kind of Maven support for this.. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org