On Fri, Sep 2, 2011 at 11:55 AM, Dennis E. Hamilton <dennis.hamil...@acm.org> wrote: > How about we worry about the downstream cases when there are any to worry > about. We are not close to a release. > > The code is *now* on the SVN. Isn't there some in-scope case that can be > covered it being there where people can lift it and do whatever they want > with it? > > [OK, a shallow appraisal. But is the ODF Toolkit case much different, when > those encryption implementations are committed?] >
I've started a new thread on this at legal-discuss. Maybe we can help them hurry things along if we all go over there and post 4 or 5 messages saying that the code is already in SVN and they should hurry up and do something, anything. On second, thought, let's not do that. It really wouldn't help much at all. > - Dennis > > -----Original Message----- > From: Rob Weir [mailto:robw...@apache.org] > Sent: Friday, September 02, 2011 08:26 > To: ooo-dev@incubator.apache.org > Subject: Re: Request dev help: Info for required crypto export declaration > > On Fri, Sep 2, 2011 at 11:12 AM, Dennis E. Hamilton > <dennis.hamil...@acm.org> wrote: >> 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. >> > > It is not clear to me that ECCN 5D992 follows the same procedures as > 5D002, at least from the EAR perspective. Since I see no other Apache > software classified as 5D992, it is also not clear to me that the same > Apache procedures would apply. > > The Apache notifications are based on the exemption in EAR 740.13(e). > But Mass Market software is covered by 740.13(d). This does not have > the same reporting requirement as 740.13(e). But it appears to have a > different requirement. Still trying to figure that out. > > http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfr&sid=ba2d5996d28cc22033ea2bfb857555cc&rgn=div5&view=text&node=15:2.1.3.4.25&idno=15#15:2.1.3.4.25.0.1.13 > >> Then we can worry about whether there needs to be some expansion of scope or >> other adjustment. >> > > I'd rather not file false information with the government. Of course, > you are welcome to do so, if you think the need is urgent. > > > -Rob > >> 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 >> >> > >
