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] [Commented] (LEGAL-250) US Export declaration of transitive dependencies?
Date Thu, 05 May 2016 14:14:12 GMT

    [ https://issues.apache.org/jira/browse/LEGAL-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15272430#comment-15272430

Stian Soiland-Reyes commented on LEGAL-250:

If I understand the [2010 rule change|https://www.bis.doc.gov/index.php/policy-guidance/encryption/identifying-encryption-items#Three],
it basically meant that encryption for DRM purposes is no longer classified. Usual SSL encryption
for communication [still is|https://www.bis.doc.gov/index.php/policy-guidance/encryption/identifying-encryption-items].

The question comes down to what "designed to be used with" means - does it have to be the
primary purpose? Or just that you use some API calls?

E.g. any software designed to be using HTTP Components is not primarily designed for encryption
purposes - however it could still be used for making https connections. 

Bouncy Castle is used as a test dependency in VFS - I don't think that is a problem. (Actually
for me the tests work fine even without it). 

However Commons VFS also include a SFTP component that IS primarily designed to be used with
encrypted SSH communications - so although VFS do not bundle the SSH libs, VFS (or part of
VFS) is certainly designed for use with that encryption functionality.

> 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

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

View raw message