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
|