<div dir="auto">Hi John,<div dir="auto"><br></div><div dir="auto">Thanks for your input.</div><div dir="auto"><br></div><div dir="auto"><br><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'd be a little worried about what people might define as a "fix". Is<br>
there any opportunity there to shoehorn other things into that category<br>
/ what's the check on that? Since many companies have over the years<br>
called things security fixes or bundled things with security fixes that<br>
are either clearly not or that very much depend on who is defining both<br>
"security" and "fix".</blockquote></div></div><div dir="auto"><br></div><div dir="auto">I am very worried about that too. That is why most of the clause is limitations designed to prevent gaming of the provision:</div><div dir="auto"><br></div><div dir="auto">- It has to be new</div><div dir="auto">- It can't apply to all modifications only to a "particular" modification addressing a security vulnerability</div><div dir="auto">- It has to significantly affect a user</div><div dir="auto">- It has to be part of a coordinated release with others (so it isn't just one licensee's idea of a "fix")</div><div dir="auto">- And it doesn't prevent sources from being released, it just delays them by a set amount of time</div><div dir="auto"><br></div><div dir="auto">But I would be open to any other anti-gaming provisions as well.</div><div dir="auto"><br></div><div dir="auto">Thanks,</div><div dir="auto">Van</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"></div></div>