I'm certainly -1 on releasing the OOXML branch until the issue is resolved to the satisfaction of the ASF's legal counsel.I'm +1 on work proceeding on the OOXML branch. If the next release occurs without such assurance then I'm -1 on it until we are sure nothing from OOXML has spilled over into the release.
However, as is my right, I've vetoed the commit: http://www.apache.org/foundation/voting.htmlHowever, I've given you several ways to resolve my concern. Gianugo threatened to override it, and I escalated by saying essentially "I will take this to the logical conclusion if you do". If we start now working together to resolve the concern then we'll potentially avoid all of this as I'm willing to wait (despite the legal risk of doing so) while just waving a big red flag DO NOT USE POI'S OOXML STUFF OR YOU MAY BE IN LEGAL PERIL to users (there are production systems in large companies running snapshots of my code that hadn't even gone to release yet).
I ask you to be helpful in not participating on either side in surrogate proxy stuff from outer-interested parties and instead let's work to resolve the issue (as it is distracting, confusing and irrelevant). deal??
-- Buni Meldware Communication Suite http://buni.org Multi-platform and extensible Email, Calendaring (including freebusy), Rich Webmail, Web-calendaring, ease of installation/administration.
smime.p7s
Description: S/MIME Cryptographic Signature
