On Wed, 15 Feb 2012, Rob Weir wrote:
What I don't see is anything that removes the old TSU exception for open source. It is one thing if the revision adds a new path, but keeps the old option, versus a revision that eliminates TSU.
The 5d002 route still exists, but it's possible that it doesn't apply to cases like ODF Toolkit. It certainly applies to things like Bouncy Castle, and probably to mod_ssl (it's based on a 5d002 library), but I'm not certain it applies to open source software that doesn't use open source crypto. That would need confirming if we did decide to ignore the new options, and just try to follow the old one
I have no background in US Federal trade regulations. I assume this is true of most of us. Since this impacts all of ASF, not just this podling, there must be a way to revise current policy at a foundation-wide level. In other words, ASF is the legal distributor of the code, they claim the copyright on the aggregated code, so it is ASF interest to get this right. I'm happy to help, but this might be a good area to get confirming advice from a competent source (e.g., not me, but an attorney), to sign off on what we think the regulation says.
I think last time, someone read up a lot on all the rules, had a chat with the BIS to clarify some things, and got a lawyer to confirm it looked fine afterwards. While Apache does have some volunteer legal resources, I don't think any of them are trade specialists, so a similar process will likely be needed again.
If you have time to read up on it, it might be worth you ringing BIS. You'll need to have grasped the basics so you can ask the right questions, but I figure a call from a fellow American is likely to be better received than if some random Brit phoned them up... :)
Nick
