<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Lucy:<br>
You've received a lot of feedback on this but have not provided
any revisions or comments in response. Should we consider this
submission withdrawn?</p>
<div class="moz-cite-prefix">On 7/19/2025 5:13 PM, Pamela Chestek
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:8f5abdef-197a-9c15-8c8d-3d470743bde7@chesteklegal.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Putting the substance aside, this license is problematic from a
contract drafting perspective. It uses words in ways that are
ambiguous, which means they can cause interpretive problems in
the future. Legal writing can be as formulaic as software coding
is -- there are interpretive rules for contracts that are
designed to help everyone reach the same conclusion on what it
means, so when you don't follow the rules it leaves room for
interpretive disagreements.<br>
</p>
<p>For example, the definitions use the phrase "refers to." That's
open-ended language, meaning that, for example, "Standard
Version," could refer to what follows in the definition but it
doesn't eliminate the possibility that the term could "refer to"
something else too. The standard language construction of a
definition is to use the word "means," "Standard Version means
..." - that is closed-ended language that doesn't allow for the
possibility that Standard Version can mean something in addition
to how it's defined. And why is it "Standard Version," singular,
but "Modified Versions," plural?</p>
<p>"Undue hassle, as mentioned in this license ..." It should be
"Undue hassle, as <i>used </i>in this license ..." You're not
just "mentioning" it, your intention is that the phrase has a
very specific, defined meaning that you are providing. <br>
</p>
<p>And while on "undue hassle," the audience would be much better
served by simply saying how the source code has to be provided,
an objective standard, rather than the subjective standard of
"acts which may prevent users from requesting" code. A
subjective standard allows for the possibility that the degree
of difficulty might be be measured by someone's personal
sensibilities, even if irrational, e.g., "I don't use email,
therefore it is an undue hassle for me to ask for the code via
email." You may think that of <i>course</i> it's a rational or
ordinary person standard, but I promise you that if this license
was ever litigated, whether it was an ordinary person standard
or the actual user's sensibilities would be be a point of
contention, to the tune of mid-five figures of dollars. You can
never write a contract that doesn't require some interpretation,
but where you can use objective, measurable standards, like
here, the better off everyone is because it prevents disputes.<br>
</p>
<p>Under III.1. you refer to "source form" but use "source code"
elsewhere. There is a principle in contract interpretation that
when you use different words it's because you meant it to have
different meanings. So if you mean source code here, then you
should use "source code," not "source form." If you mean that
"source form" is something different from "source code," then
you need to clarify that. Find-and-replace is the contract
drafter's friend, to make sure that the same term is used
consistently throughout.<br>
</p>
<p>The structure of the rights grants is:</p>
<p>III.1. Copyright grant of some scope</p>
<p>III.2. Copyright grant of some scope</p>
<p>III.3. Copyright grant of some scope</p>
<p>III.4. Copyright grant of some scope</p>
<p>III.5. Can add your own attribution</p>
<p>III.6. Patent grant of some scope</p>
<p>III.7 Copyright grant of some scope that has some optional
variables (also refers to 6a, which should be 7a)<br>
</p>
<p>III.8 No advertisement clause</p>
<p>III.9 No warranties and limitation of liability</p>
<p>You should be able to spot the problem - there are five
different sections that carve up rights under copyright law.
Some of them use terms of art and some do not. How is "giving
away" under III.1. different from "distributing" under III.3 or
"redistributing" under III.4.? Some of the grants are for
"Standard Version" and some for "Software," which are
overlapping categories. The copyright grants aren't even grouped
together. This all makes it exceedingly difficult to understand
this license and, when you have so many different overlapping
scopes, there is bound to be a loophole somewhere. If you need
to have all these separate grants, then they should to be
written in parallel structure so the reader can easily see how
they fit together.<br>
</p>
<p>I haven't read this license thoroughly, this is just what I
picked up on a quick read, so I'm not suggesting that there
aren't other inconsistencies elsewhere. But on a rewrite you
should consider these structural drafting problems.<br>
</p>
<p>Pam<br>
</p>
<div class="moz-signature">Pamela S. Chestek<br>
Chestek Legal<br>
PLEASE NOTE OUR NEW MAILING ADDRESS<br>
4641 Post St.<br>
Unit 4316<br>
El Dorado Hills, CA 95762<br>
+1 919-800-8033<br>
pamela@chesteklegal<br>
<a class="moz-txt-link-abbreviated"
href="http://www.chesteklegal.com" moz-do-not-send="true">www.chesteklegal.com</a><br>
<br>
<br>
</div>
<div class="moz-cite-prefix">On 7/10/2025 11:24 AM, Josh Berkus
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:029f07d4-5bc1-450d-b39a-12edd1b66382@opensource.org">On
6/30/25 17:33, Josh Berkus wrote: <br>
<blockquote type="cite">Lucy Randall, <br>
<br>
We are approaching 2 months from the submission of this
license, our usual interval for examination. You've received
some critical feedback from our volunteer attorneys. Do you
plan to revise the license submission, or keep it as it is? <br>
<br>
</blockquote>
<br>
For the record, the submitter plans to submit a revised text. <br>
<br>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
The opinions expressed in this email are those of the sender and not necessarily those of the Open Source Initiative. Communication from the Open Source Initiative will be sent from an opensource.org email address.
License-review mailing list
<a class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:License-review@lists.opensource.org"
moz-do-not-send="true">License-review@lists.opensource.org</a>
<a class="moz-txt-link-freetext"
href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org"
moz-do-not-send="true">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a>
</pre>
</blockquote>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre wrap="" class="moz-quote-pre">_______________________________________________
The opinions expressed in this email are those of the sender and not necessarily those of the Open Source Initiative. Communication from the Open Source Initiative will be sent from an opensource.org email address.
License-review mailing list
<a class="moz-txt-link-abbreviated" href="mailto:License-review@lists.opensource.org">License-review@lists.opensource.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a>
</pre>
</blockquote>
</body>
</html>