Mark Hindess wrote: > I've added a patch that removes two classes: > > org/bouncycastle/asn1/misc/IDEACBCPar.class
Don't know what this asn1 class is, but I don't think we need to delete it. > org/bouncycastle/crypto/engines/IDEAEngine.class This is the key one to delete. See [1] and the patent reference here [2]. > to https://issues.apache.org/jira/browse/HARMONY-4810 in order to > facilitate testing. (Obviously, the signature files are also removed.) > > Tim, do we know if this is sufficient? In terms of fulfilling the avoidance of patented algorithm then, yes I think it is sufficient. Then there may be references to the class that need fixing elsewhere too. > I see lots of x-net failures after applying this patch! ;-( Something we have to fix for M3 me thinks :-< [1] http://www.bouncycastle.org/devmailarchive/msg05065.html [2] http://www.bouncycastle.org/docs/docs1.4/org/bouncycastle/crypto/engines/IDEAEngine.html Regards, Tim > On 18 September 2007 at 11:06, Tim Ellison <[EMAIL PROTECTED]> wrote: >> There is a discussion over at the incubator general mailing list (e.g. >> [1]), amongst other places, about the redistribution of BouncyCastle >> code from ASF machines. >> >> The crux is that we can't redistribute BC's IDEA implementation as it is >> subject to a known patent for which we don't have a grant/license. >> >> We'll have to change our current practice of publishing binaries that >> include BC unmodified. The resolution seems to be maintaining a local >> copy of the BC JAR without the offending algorithm. I expect we would >> have to unsign the JAR too when modified. >> >> Do we have any dependencies upon IDEA? I see some references in the >> JSSE cipher suite code, but likely we don't attempt use it if we don't >> have it. >> >> [1] >> http://mail-archives.apache.org/mod_mbox/incubator-general/200709.mbox/%3c46E >> [EMAIL PROTECTED] >> >> Regards, >> Tim >> > > >
