poi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yegor Kozlov <ye...@dinom.ru>
Subject Re: Legal concerns/questions with exporting/importing Apache Poi 3.5
Date Fri, 22 Jan 2010 18:03:48 GMT
> One of our product teams has expressed an interest in upgrading to Apache Poi 3.5. I also
expect other products to express an interest in future releases. During the third party review
process our Legal department expressed some concern regarding Poi's cryptography notice (http://poi.apache.org/legal.html)
and its classification as 5D002.C.1 under ECCN. This classification requires us to report
all exports of the product (and our products containing the product) twice each year. This
is an administratively intensive task for our Legal Department and not one we are currently
equipped to handle very efficiently.  Therefore we are looking for a solution which allows
our products to upgrade to v3.5 without placing an additional burden on our Legal department.
 Can you answer the following questions which should help us decide what options we have available?
> 
I think this Cryptography Notice is outdated. At some point we attempted to use javax.crypto
and javax.xml.crypto 
packages for implementation of Digital Signature support in OOXML documents. The initial patch
was checked-in but then 
reverted until we have consensus on legal and patent issues. The Java code was reverted but
the notice remained.

> Legal Questions:
> 1)      Does Apache Poi 3.5 use the java.security and javax.crypto packages from the
JRE, JCE, or a different product? If it is the JRE packages, then why is the Apache product
classified as 5D002. Based upon our legal department's analysis the JRE is classified as 54992
(which is a more favorable classification that does not require reporting).

At the moment POI does not use any of javax.crypto  classes. We have our own implementation
of RC4 which is equivalent 
to the RC4 cypher from javax.crypto - we use RC4 to read password protected workbooks. This
implementation is based on 
public information and was inspired by Wikipedia's RC4 article http://en.wikipedia.org/wiki/RC4.

The only class that POI uses from java.security is MessageDigest. As far as I know it is not
classified by the US export 
regulations.

> 2)   Has the Apache Poi product been reviewed by BIS? Does it have any CCATS#? If Poi
3.5 has been reviewed, was any type of reporting exception granted in the review?
> 

> Technical Questions:
> 1)      Would it be possible to obtain a copy of Apache POI 3.5 that does not have the
encryption (or encryption calls)? Or could we build our own version (without the encryption
support)?

Yes, it is possible. The source code of POI 3.5 ( and any other releases) is publicly available
and if you want, you can 
root out the encryption  classes, the Apache license allows you to do it.

Regards,
Yegor

> 
> Thanks.
> Rob
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
> For additional commands, e-mail: dev-help@poi.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org


Mime
View raw message