<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <br>
    <div class="moz-cite-prefix">On 5/19/2025 7:34 PM, Moming Duan
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:4012051A-E999-485F-BEC7-11D10BDA4DAA@gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      Hi Pam an Richard,</blockquote>
    &lt;snip&gt;<br>
    <blockquote type="cite"
      cite="mid:4012051A-E999-485F-BEC7-11D10BDA4DAA@gmail.com">
      <div><font color="#0affff"><span style="caret-color: rgb(10, 255,
            255);"><br>
          </span></font></div>
      <blockquote type="cite">
        <div>Response to Pam\u2019s comments<span style="caret-color: rgb(0,
            0, 0); color: rgb(0, 0, 0);">: </span><span
            style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">Not
            necessarily a bar to license approval, but I am skeptical
            that copyleft is a workable concept for models, particularly
            where the Model is used for training of new models through
            distillation or generating synthetic data. This is a known
            problem for databases and I expect it will be even more
            challenging for models. It can easily become unmanageable. </span></div>
        <div><span style="color: rgb(12, 255, 255);"></span></div>
      </blockquote>
      [R: this is a difficult issue, and I agree with Pam that it will
      be challenging to <em>actually </em>implement copyleft for models,
      which in turn <em>could</em> expose downstream users to liability
      from the Licensor. But as a practical matter, how many Licensors
      would actually sue users for failing to comply with copyleft? Only
      (a small number of) commercial users would be worth suing for
      failing to comply with copyleft. This means that in practice,
      including a copyleft obligation only makes the license risky for
      commercial users, but probably makes no difference to other users.
      Further, the copyleft obligations in Section 2.2(a) only apply to
      Licensed Materials and Derivative Materials - I would argue that
      once something is sufficiently transformed or changed such that it
      cannot be considered Licensed Materials or Derivative Materials,
      copyleft no longer applies. This is especially so for models,
      which, unlike software, cannot be easily decomposed into its
      component libraries/routines/functions etc. In my view, this means
      that the copyleft obligation will only catch the most egregious
      violations/copying by commercial users (who, arguably, should know
      better). Overall, I would include the copyleft obligation, but I\u2019m
      interested to hear OSI\u2019s comments on my analysis.]<span
        style="caret-color: rgb(0, 0, 0);"> <br>
      </span></blockquote>
    <p>I continue to be troubled by the position that it's ok to put in
      a provision because it will be ignored. We want people to do their
      best to comply with licenses, which means that the license should
      be a clear as possible and it is possible to comply with the
      license requirements. It's harmful from policy and compliance
      standpoints to set up a situation where you expect and ratify
      people not holding up their end of the bargain. <br>
    </p>
    <p>You say "I would argue that once something is sufficiently
      transformed or changed such that it cannot be considered Licensed
      Materials or Derivative Materials, copyleft no longer applies.
      This is especially so for models, which, unlike software, cannot
      be easily decomposed into its component
      libraries/routines/functions etc. In my view, this means that the
      copyleft obligation will only catch the most egregious
      violations/copying by commercial users (who, arguably, should know
      better)." <br>
    </p>
    <p>This is exactly the problem -- when copyleft will apply is
      subject to interpretation, and even perhaps entirely unknowable.
      This is perfectly setting up a troll, which you seem to find
      acceptable because it will only catch commercial companies - but
      why are you so dismissive of commercial companies? I might go so
      far as to say that a provision that is designed to trap some
      categories of users, but not others, is a violation of OSD 6, No
      Discrimination Against Field of Endeavor. You know who else it
      harms? Individuals who want to do the right thing and so will not
      use the model because the license compliance obligations are too
      ambiguous.<br>
    </p>
    <blockquote type="cite"
      cite="mid:4012051A-E999-485F-BEC7-11D10BDA4DAA@gmail.com"><span
        style="caret-color: rgb(10, 255, 255);"></span><br
        id="lineBreakAtBeginningOfMessage">
      <span style="caret-color: rgb(10, 255, 255);"></span>
      <div>
        <div><br>
        </div>
        <div><br>
        </div>
        <blockquote type="cite">Response to the Model Output Provision
          and the Editor Hypothetical:</blockquote>
        <br>
      </div>
      <div>[R: I agree with Moming that the model output provision does
        not violate any of the 10 Open-Source Definition criteria. The
        OSI<span style="caret-color: rgb(12, 255, 255);">\u2019</span>s
        responses appear to be against this model output provision,
        mostly on the basis that it restricts the conditions of use of
        the output (ie the \u201ceditor argument\u201d).<br style="caret-color:
          rgb(0, 0, 0);">
        <br style="caret-color: rgb(0, 0, 0);">
        I think I would counter that open-source software is <em>not</em> free
        (or \u2018libre\u2019) software (in FSF parlance). To quote, "Why Open
        Source Misses the Point of Free Software" <font color="#000000"><a
href="https://www.gnu.org/philosophy/open-source-misses-the-point.html"
            moz-do-not-send="true" class="moz-txt-link-freetext">https://www.gnu.org/philosophy/open-source-misses-the-point.html</a> .
          Further, "the criteria for open source are concerned solely
          with the use of the source code. Indeed, almost all the items
          in the Open Source Definition are formulated as conditions on
          the software's <em>source license</em> rather than on what
          users are <em>free to do.\u201d </em></font></div>
      <div><br style="caret-color: rgb(0, 0, 0);">
        If so, then imposing conditions on use of the output is <em>not</em> against
        the 10 OSD criteria (does not appear to be in violation of OSD6
        and OSD8).<br style="caret-color: rgb(0, 0, 0);">
      </div>
    </blockquote>
    I agree with Carlo's email on this point. We look at it holistically
    too, particularly where it's a license for new subject matter, an AI
    model.<br>
    <blockquote type="cite"
      cite="mid:4012051A-E999-485F-BEC7-11D10BDA4DAA@gmail.com">
      <div><br style="caret-color: rgb(0, 0, 0);">
        I would even say that an editor which required any file created
        with the editor to have an attribution notice could be
        open-source, but not free. Of course, in practice, such an
        attribution requirement is silly for editors, but as Moming
        pointed out, an LLM is <em>not</em> a code editor.<br
          style="caret-color: rgb(0, 0, 0);">
        <br style="caret-color: rgb(0, 0, 0);">
        More importantly, while the principles of \u2018free\u2019 software point
        in favour of having <em>no </em>conditions on use/output, the
        unique nature of LLMs also mean that some conditions on
        use/output are desirable. And although this is a value-judgment
        (on how AI-created content should be treated), I would say that
        (1) adherence to the 4 FSF freedoms is itself a value-judgment
        in favour of freedom (understood a certain way) in software, and
        (2) labelling AI-generated content is something that is
        compatible with, and necessary, for the 4 FSF freedoms to be
        desirable. I would analogise this to how even the right of free
        speech is limited in specific contexts. This point is more
        germane to the \u201cadvertisement\u201d requirement (previously 2.4(b),
        which had the purpose of targeting misinformation and misleading
        claims), but also applies to the current Section 2.2(b) (which
        has the narrower purpose of ensuring sustainability in
        open-source LLM development).<br style="caret-color: rgb(0, 0,
          0);">
      </div>
    </blockquote>
    As you correctly state, "the principles of \u2018free\u2019 software point in
    favour of having <em>no </em>conditions on use/output." For the few
    conditions that exist, there was indeed a value judgment made that
    the benefit gained was worth the impairment. I don't see anything in
    your answer that explains what benefit there is to your proposed
    impairment on output, much less that it's significant enough that a
    new condition should be allowed. What is its purpose?<br>
    <blockquote type="cite"
      cite="mid:4012051A-E999-485F-BEC7-11D10BDA4DAA@gmail.com">
      <div><br style="caret-color: rgb(0, 0, 0);">
        In the most recent threads, there was also some discussion about
        whether copyright or patent law grants the Licensor
        rights/control over the output. My view is that copyright/patent
        law does <em>not</em> need to grant the Licensor rights/control
        over the output, since the License is imposing conditions on the
        use of the Model (ie Licensed Materials), and is making the
        License grant conditional on compliance with these conditions of
        use. I would suggest not approaching the issue from the point of
        view of IP rights over output (since that is a thorny issue -
        requires further analysis), but merely as an issue of whether
        imposing certain conditions on use is OSD-compliant.<br
          style="caret-color: rgb(0, 0, 0);">
      </div>
    </blockquote>
    As mentioned, we don't allow any conditions lightly and I haven't
    seen an adequate justification for this one.<br>
    <blockquote type="cite"
      cite="mid:4012051A-E999-485F-BEC7-11D10BDA4DAA@gmail.com">
      <div><br style="caret-color: rgb(0, 0, 0);">
        Finally, I agree entirely with your response to Pam that
        although "attribution information may be lost over several
        generations... it would be unreasonable to respond to this
        challenge by altering data licenses to allow unrestricted reuse
        and removal of attribution simply for the sake of convenience or
        ease of crawling\u201d. In the case of downstream reuse of the
        Output, the difficulty in knowing whether \u201cthe original Output
        is still there several generations later\u201d, in fact works in our
        favour, because it means that the attribution obligation is not
        overly onerous and will only catch the most egregious
        violators/copiers.</div>
    </blockquote>
    <p>As explained above, this is a highly problematic outlook on
      licenses. <br>
    </p>
    <p>Pam<br>
    </p>
    <p><br>
      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></p>
  </body>
</html>