We're already behind the 8-ball on having not done this when it was expected. I suggest that the established procedure be followed so that the ASF requirement is satisfied, the XML files are updated, etc.
Then we can worry about whether there needs to be some expansion of scope or other adjustment. Perhaps legal-discuss@ or general-incubator is a place to take that additional concern? - Dennis PS: I suspect that notices in the released implementations would be appropriate, considering responsibilities that users of the software may also have in the jurisdiction where usage is occuring. But I think that we need to acquit ourselves of the fact that the various OO.o employment of cryptographic methodologies are now in source-code form on the Apache SVN. -----Original Message----- From: Rob Weir [mailto:robw...@apache.org] Sent: Friday, September 02, 2011 08:01 To: ooo-dev@incubator.apache.org Subject: Re: Request dev help: Info for required crypto export declaration Starting fresh. The more I look into this the more I'm starting to think that the Apache export control instructions [1] are leading us in the wrong direction. >From what I've been able to determine, the classification code comes not only from the strength of the encryption, but also the use of the software. For example, strong encryption (based on key length) might end up in different classifications depending on whether it is a general purpose encryption library, a "mass market" product, a server product, etc. It is not just about key length. The Apache instructions seem to say that all paths lead to 5D002. Maybe this is true for strong encryption in the typical Apache developer libraries or server-side products. But OpenOffice.org is not your typical Apache product, is it? If you look at how commercial derivatives of OpenOffice.org are treated, such as IBM Lotus Symphony or LibreOffice Novell Edition, you see that they are classified as 5D992, not 5D002. But I do not see 5D992 mentioned at all on the Apache page on handling cryptography. Until we better understand that discrepancy, I don't think we should blindly follow the 5D002 route. Is there anyone at Apache who really understands these things in a more general way, e.g., understands the implications of "mass market" software? -Rob [1] http://www.apache.org/dev/crypto.html
