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 15:18:12 GMT

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

Stian Soiland-Reyes commented on LEGAL-250:
-------------------------------------------

I think I stand corrected, Sebb.

>From https://www.bis.doc.gov/index.php/policy-guidance/encryption/identifying-encryption-items#Three

{quote}

The decontrols note appears as Note 4 to Category 5, Part 2 of the CCL and provides as follows:

Note 4: Category 5, Part 2 does not apply to items incorporating or using "cryptography" and
meeting all of the following:

(a) The primary function or set of functions is not any of the following:
     (1) "Information security";
     (2) A computer, including operating systems, parts and components therefor;
     (3) Sending, receiving or storing information (except in support of entertainment, mass
commercial broadcasts, digital rights
          management or medical records management); or
     (4) Networking (includes operation, administration, management and provisioning);
(b) The cryptographic functionality is limited to supporting their primary function or set
of functions; and
(c) When necessary, details of the items are accessible and will be provided, upon request,
to the appropriate authority in the exporter’s
     country in order to ascertain compliance with conditions described in paragraphs (a)
and (b) above.

Note 4 completely removes the decontrolled items from control under Category 5, Part 2 of
the CCL.
{quote}


You need all (a), (b) and (c) to be exempt.   IF you are exempt, that means you are not "designed
to use cryptography". But 


(b) is generally true for the cases we are talking about here - someone just using encryption
as part of something else (non-encryption related) they need to do.

(c) is true for ASF because we deliver open source - and would be true also for closed-source
downstream redistibutors as long as they don't modify the ASF code. If we depend on closed-source
(category B) CDDL code for encryption, then we need to be more careful. OpenJDK is dual-licensed
as CDDL and GPL - so the GPL bit should be in clear. (In fact OpenJDK supports strong encryption
out of the box, not needing the magic policy file)


So this should support Sebb's side - if your software's primary function is 4.5.2(a) exempt:

* NOT doing "[information security|http://www.bis.doc.gov/index.php/policy-guidance/encryption/classification#One]"
(this would trap Commons Crypto I guess)
* NOT be part of computer hardware or operating system
* NOT primarily "Sending, receiving or storing information" (uhu..)
* NOT doing [Networking|http://www.bis.doc.gov/index.php/policy-guidance/encryption/classification#One]
(e.g. managing Cisco routers or IP package level inspection)



Then you are free to go with no ECCN registration needed, collect $200 at Start. 

However if any of those are true, then you need to do ECCN registration,  go through which
encryption functionality is (ultimately) involved and list it in the registration. From what
I read, this is true even if encryption is not part of that - e.g. Derby is primarily storing
information - but even if storage is not done in an encrypted manner they can't use this exception
and have to register.

However someone using Derby or HTTP Component are in the clear, as long as they are exempt
from the (a-c) lists. 

And if you need to register, then I think your use of say Derby and HTTP Component should
be included, even if they are not used for encryption purposes.


So if you agree on this - then I suggest we can summarize this lengthy threads (sorry about
this..) with a new FAQ entry for http://www.apache.org/dev/crypto.html that somehow lists
the above.



As for the particular projects discussed, then I suggest to conclude:


Commons VFS has a set of function which includes "Sending, receiving or storing information"
and should be registered. Registration would list Apache MINA, SSHD and JCSH (which it directly
uses the encryption functionality of), but not BouncyCastle, Hadoop nor Jetty - as they are
not used for encryption and are not bundled.

Commons Crypto is primarily doing "information security" and should be registered.

Commons Compress remains listed because its primary function is "Storing information".

Jena, includes a functionality to store information (The TDB triple store) and so it unfortunately
should be registered even though no encryption is involved in that.


Taverna Language (while primarily an API for designing workflows) includes a component which
functionality is data storage in a ZIP file - the encryption functionality of HTTP Components
is however not used, and so Language should not be registered. (unless we make a binary distribution
that includes HTTP Components)

Taverna OSGi's Download API module is "Sending, receiving or storing information" and so should
be registered because it is using HTTP Components and can do https.

Taverna Engine's Credential Manager module is doing "information security" and should be registered.

Taverna Common Activities are "Sending, receiving or storing information" (talking to web
services) and should be registered.

Taverna Command Line is primarily running a workflow, and should NOT be registered (unless
you consider a workflow to be primarily sending/receiving information) - however if we make
a binary distribution it would include Bouncy Castle, Derby, HTTPComponents as JARs, and at
that point needs to be registered.

So I'll review Taverna's registration in light of this.
 

Usual IANAL disclaimer goes here..

> 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


Mime
View raw message