www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stian Soiland-Reyes (JIRA)" <j...@apache.org>
Subject [jira] [Created] (LEGAL-250) US Export declaration of transitive dependencies?
Date Tue, 26 Apr 2016 08:45:13 GMT
Stian Soiland-Reyes created LEGAL-250:

             Summary: 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


I'm preparing the changes to eccnmatrix.xml for Apache Taverna (TAVERNA-959) - my current
draft is at

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

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

View raw message