<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<div class="moz-cite-prefix">On 2/24/2025 10:15 AM, Carlo Piana
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:1688767557.11087695.1740420949313.JavaMail.zimbra@piana.eu">
<blockquote style="border-left:2px solid
#1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;">
<p>Given that I believe the intent and actual effect of the
language of AFL & OSL -- as well as the actual effect of
the language in MGB 1.0 under current law -- would be to
encompass equivalents, this submission raises an interesting
question on license text vs license intent and approval of
licenses. The patent grant of AFL & OSL has already been
approved, and MGB 1.0 attempts to use that same language in
its own grant.* Specifically, can the parol evidence of the
intent of the licensor in drafting language in a license be
considered in both the decision to approve or disapprove of a
license, or for that matter in interpreting the license itself
later when it is used? I tend to think if a license submitter
submits a license with language that under prevailing law does
not violate the OSB (and which has been approved in the past
as complying with the OSB), but the licensor in submitting the
license says they intend for the license text to violate the
OSD, the intent should play into approval even if the text
itself doesn't effectuate the intent. Which in this case, as
I've said before, the intent to carve out DoE from the license
in my opinion violates OSD and makes this license
non-approvable, even if the language which purportedly
accomplishes that intent has previously been approved.</p>
</blockquote>
<div><br>
</div>
<div>This is a recurrent item of discussion. I submit that in a
standard license, the intent of the drafter bears little to no
weight in the interpretation of a legal instrument that is
offered for the use of the many. It has little bearing also in a
situation where it is being used only by the drafter. In any
cases, being a matter of interpretation, which is heavily
impacted by the relevant rules of the applicable law, it would
be disingenuous by anyone to attempt any such interpretation,
especially in the absence of an interested counterpart.
Therefore, we, and the Licensing committee first and foremost,
should interpret the license for what it says and according to
the general understanding of similar wording, if there is a
customary use of it in the trade. But the intent, both pro o
against the OSD, should in principle not be considered, unless
-- and this is a notable exception -- if it is expressly stated
that one sought goal is against the OSD. Which includes carving
out any rights which, under any legal theory or instrument, is
required to fully exploit the grant and do Open Source. I long
time ago have been guilty of attempting to do so, and I have
long since repented of my nefarious deeds.</div>
<div><br data-mce-bogus="1">
</div>
<div>Despite we concentrate on legal text (maybe with an
hammer-nail attitude), the main purpose of clearing a license is
to certify that the text under scrutiny is a legal instrument
that enables the obstacles coming from of "all rights reserved"
default as well as from other potential obstacles coming from
other instruments; so that the recipient is allowed to use of
the freedoms that need to be granted. The scope of the
licensing approval, in other words, is IMHO that of making sure
that the software **is** Open Source, not that the license is
compliant (the OSD is a means to an end). The software is Open
Source if the distribution artifact grants everything that
legally is required and if it provides everything that
technically is necessary to use, study and modify, make copies
and distribute original or derivatives. Anything that does limit
or purports to limit the Open Source-ness of the software (as
opposed to imposing conditions to foster it) is aiming short of
Open Source and should be rejected because it falls short the
most important test.</div>
<div><br data-mce-bogus="1">
</div>
</blockquote>
<p>I think we agree? I'm less inclined than you to trust the
language of the instrument because language is so imperfect. But
you make allowances for the case where the intended goal is
against the OSD, which seems to be this case. I am wary of giving
a license our blessing where the license steward believes they
have not granted all rights necessary (even when their
interpretation doesn't seem to comport with existing law). I think
we have a duty to protect the users who will not have seen this
discussion and therefore learned that the licensor thinks that
some of its patent rights have not been licensed -- if they knew,
they surely would not use the software. I think the reasoning is
even more compelling here where the license is meant to be
essentially the same as the Apache license, that it it's a
redundant license, but for the change to the patent language. <br>
</p>
<p>Pam<br>
</p>
<div class="moz-signature">Pamela S. Chestek (in my personal
capacity)<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></div>
<p></p>
</body>
</html>