<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<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">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" 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>