You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by "Stian Soiland-Reyes (JIRA)" <ji...@apache.org> on 2016/05/02 04:18:13 UTC
[jira] [Updated] (LEGAL-250) US Export declaration of transitive
dependencies?
[ https://issues.apache.org/jira/browse/LEGAL-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stian Soiland-Reyes updated LEGAL-250:
--------------------------------------
Description:
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..
was:
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+Crypto+draft+XML
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..
> 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