<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>I did my own markup in ODT, and I tried to show where the moved
      definitions differ from those in Apache 2.0 (as well as where
      Apache 2.0 definitions have been removed from this license). See
      attached. This may or may not be easier for people to see the
      differences between the two licenses than what Pam sent.</p>
    <p><br>
    </p>
    <p>A few observations:<br>
      There are still some basic drafting issues with the submitted
      version: missing close quotes, missing close parentheses, missing
      apostrophe, inconsistent use of terminology (Definition of "Source
      Form" and "Object Form" is different than in Apache, but body of
      license uses the formulation of Apache: "Source form" and "Object
      form."). Another issue is the defined term "Model Materials" is
      used but the text of the license only calls out "Models." These
      are fairly minor but some cleanup would need to be done on this
      license to fix these various issues). </p>
    <p><br>
    </p>
    <p>I have a slightly different take on some of the questions that
      Pam raised below.</p>
    <p><br>
    </p>
    <p>Patent grant (Sec 2B). The grant itself is internally
      inconsistent and even if those inconsistencies are reconciled I
      really have a hard time understanding the rationale for why anyone
      would want to use a license with the type of patent grant that
      this license attempts to articulate. As Pam notes, "Work" and
      "Contributor Version" are not articulated as meaningfully
      different (and "Contributor Version" is not a term used in Apache
      2.0, although other licenses use that term but without the
      separate defined term "Work"). GIven that these two terms are used
      together in the disclaimer of combinations grant there needs to be
      articulation of what this disclaimer means as right now it doesn't
      make any sense nor can (I believe) anyone figure out what
      combinations are being disclaimed from the patent grant.</p>
    <p>Also, the patent grant does initially purport to cover Derivative
      Works ("to make, have made, use, offer to sell, sell, import, and
      otherwise transfer the Work *and Derivative Works*") but this
      grant to Derivative Works is then taken away by the disclaimer of
      "*your* or any other party s (sic) Derivative Works." As currently
      written, the only patent grant is from the original author to
      their original version of the Work. This seems to significantly
      disadvantage the original author as they would be granting a
      license to their work but not receiving one in return from
      subsequent contributors. This seems ill advised and I don't see
      why any original work author would select this license for use
      because of that.</p>
    <p>Finally, this license removes the perpetual nature of the patent
      license from Apache 2.0 but there's no explanation as to why
      (perhaps it is based on the patent grant surviving for the life of
      the licensed patents but I don't see a need to strike out
      perpetual in that case given that once any particular patent
      expires no license is needed.</p>
    <p><br>
      On the non-patent rights grant, as it is now intended to cover
      things other than copyright, it probably shouldn't use only the
      verbs that come from 17 USC (US copyright law), as it could
      otherwise be construed as just a copyright license.</p>
    <p><br>
    </p>
    <p>I share Pam's concerns about the additional attribution
      requirement, and will add that it purports to impose this
      obligation even when there is no use of copyrighted material ("any
      portion of the Work included with or integrated into Your
      Derivative Work"). Apache 2.0 already includes a source code
      attribution requirement in 4.3 as well as an attribution
      requirement via a Notice file for source and non-source versions;
      this additional notice requirement adds yet another notice
      compliance burden that doesn't seem to add anything beyond what
      Apache already does (FWIW I find Apache 2.0's burdensome too and
      think it would be better to just modify 4.3 to include both source
      and object code and remove the Notice file requirement
      altogether).</p>
    <p><br>
    </p>
    <p>I also echo Pam's comments on the HIPAA clause. This seems like
      just another "you have to comply with the law" clause which are
      generally unnecessary and are falling away (thankfully) from newer
      better licenses (I think I was the first one to ever deprecate a
      license due to this issue: <a
href="https://www.linux.com/news/intel-withdraws-open-source-license-receives-applause/">Intel
        withdraws open source license, receives applause - Linux.com</a>) 
      Although the clause also purports to include a disclaimer of
      warranties under HIPAA, the broad disclaimer in Apache 2.0 (which
      this license reproduces) should already cover that.</p>
    <p><br>
    </p>
    <p>In summary, there's a lot of cleanup that this license needs, as
      well as some structural changes that probably would need to be
      made in order to make it coherent enough to approve.</p>
    <p><br>
    </p>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 9/19/2025 5:41 PM, Pamela Chestek
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:91c6f3e8-b584-a9cb-82e7-b85c64782142@chesteklegal.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <p>I believe this license is still problematic for several
        reasons.</p>
      <p><br>
      </p>
      <p><u>Section 2(B), patent grant</u> (why is B uppercase here, but
        lowercase in Section 3?)<br>
      </p>
      <p> </p>
      <blockquote type="cite">For clarity, no patent license is granted
        by a Contributor for infringements caused by: <br>
        <br>
        (i) your or any other party's Derivative Works, ... <br>
      </blockquote>
      This language withholds the patent license the moment a change is
      made to the software, whether it has anything to do with the
      patented function or not. In other words, no one who makes any
      change downstream has a patent license. This is unacceptable for
      an open source license.<br>
      <p><br>
      </p>
      <p> </p>
      <blockquote type="cite">(ii) the combination of the Work with
        anything other than the Contributor Version. </blockquote>
      I can't parse this language, because I don't think you mean "Work"
      as it is defined in the license. As you've defined it, the
      "Contributor Version" <i>is</i> the "Work," so how can there be a
      combination of these two things? I assume what you're trying to
      get at is the concept of combining your Contributor Version with
      some other software, but I don't think that's what it says.
      However, my understanding of what you're trying to say is
      problematic too, because, like above, you are withholding the
      patent license even though the combination may not create a new
      infringement. New infringement is the only kind of patent claims
      that can be excluded in an open source license.<br>
      <p><br>
      </p>
      <p><u>Section 3(d), new attribution requirement</u><br>
      </p>
      <p><br>
      </p>
      <p>The newly added 3(d) is problematic. First, it's unclear. The
        requirement is to "conspicuously mark[] any portion of the Work
        ..." Mark it where? In the source code? In the marketing
        materials? In the documentation? It is also atypical, in that it
        appears to require a user to add new information that is not
        already contained in the software. Your license (and the Apache
        license) state that copyright notices have to be retained, so
        why isn't it sufficient for you to include the copyright notice
        you desire, which then others cannot remove? Why are you putting
        an affirmative burden on a user to figure it out? What problem
        are you trying to solve with this?<br>
      </p>
      <p><br>
      </p>
      <p><u>Section 4, Personal Information</u></p>
      <p><br>
      </p>
      <p>It's questionably written and I believe unnecessary. It has the
        wording of a limit on the license grant, "The Work may include
        data, graphs, and Models, and if so, You may use and modify such
        data, graphs, and Models, <i>provided that</i> ..." "Provided
        that" is typically interpreted as a condition on the previous
        permission. However, what follows isn't a condition, just a
        statement of fact, "You may have obligations to comply with laws
        concerning privacy or protected health information ...." But are
        you trying to condition the license grant on compliance with the
        privacy laws? If you are, that would be a violation of OSD6. <br>
      </p>
      <p><br>
      </p>
      <p>The section is also problematic because it cites US law. Open
        source licenses are ideally for an international audience. The
        waiver of warranty is redundant to Section 8. I would weigh
        whether it really is necessary to tell people what they should
        already know, which is that they have to abide by the law, and
        consider taking the entire paragraph out.<br>
        <br>
        Pam<br>
      </p>
      <p><br>
      </p>
      <p>Pamela S. Chestek</p>
      <div class="moz-signature"> Chestek Legal<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 9/19/2025 9:03 AM, Barksdale,
        Marvin via License-review wrote:<br>
      </div>
      <blockquote type="cite"
cite="mid:DM6PR04MB65586E11DA343C3C53CC9519CE11A@DM6PR04MB6558.namprd04.prod.outlook.com">
        <meta http-equiv="Content-Type"
          content="text/html; charset=UTF-8">
        <style type="text/css" style="display:none;">P {margin-top:0;margin-bottom:0;}</style>
        <div
style="line-height: 1.38; margin: 0in 0in 8pt; font-family:
        Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri,
        Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"
          class="elementToProof"> I Marvin Barksdale JD, the license
          steward and license submitter, attests that this new \u201cMGB 1.0\u201d
          license complies with the Open Source Definition, including:</div>
        <div
style="line-height: 1.38; margin: 0in 0in 8pt; font-family:
        Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri,
        Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"
          class="elementToProof"> OSD 3 \u2013 The license must allow
          modifications and derived works and must allow them to be
          distributed under the same terms as the license of the
          original software.</div>
        <div
style="line-height: 1.38; margin: 0in 0in 8pt; font-family:
        Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri,
        Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"
          class="elementToProof"> OSD 5 \u2013 The license must not
          discriminate against any person or group of persons.</div>
        <div
style="line-height: 1.38; margin: 0in 0in 8pt; font-family:
        Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri,
        Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"
          class="elementToProof"> OSD 6 \u2013 The license must not restrict
          anyone from making use of the program in a specific field of
          endeavor.</div>
        <div
style="line-height: 1.38; margin: 0in 0in 8pt; font-family:
        Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri,
        Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"
          class="elementToProof"> and OSD 9 \u2013 The license must not place
          restrictions on other software that is distributed along with
          the licensed software. For example, the license must not
          insist that all other programs distributed on the same medium
          must be open source software.</div>
        <div
style="line-height: 1.38; margin: 0in 0in 8pt; font-family:
        Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri,
        Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"
          class="elementToProof"> License Rationale</div>
        <div
style="line-height: 1.38; margin: 0in 0in 8pt; font-family:
        Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri,
        Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"
          class="elementToProof"> The MGB Open Source License 1.0 (\u201cMGB
          1.0\u201d) is a permissive open source license that was created to
          catalyze open source distribution and open science among the
          health care innovator and research development community,
          particularly those employed at Academic Medical Centers (AMCs)
          receiving federal grant funding, such as Mass General Brigham
          Incorporated (MGB).  AMCs are collectively organized hospitals
          and laboratories that are integrated with a medical school,
          featuring a federally regulated mission to provide patient
          care, train healthcare professionals, and conduct innovative
          research.  In recent years these complex organizations have
          evolved to perform several ancillary commercial functions
          including IP co-development, administration, and
          out-licensing, all of which aimed to support their central
          mission of the advancement of medicine.  Aligned with this
          central mission is the proliferation of open science activity
          at AMCs, in that many of their researchers and developers have
          shifted to open collaborative approaches where research data,
          methodologies, source code and findings are shared at no cost
          to spur innovation. But, despite the alignment with system
          goals, AMCs have been slow to adopt open source best
          practices.    At Mass General Brigham, for example, despite
          receiving over $77M in NIH funding over the past 10 years to
          support 200+ software research projects in yielding fruitful
          open source communities and innovations, instead there is a
          large silo of health care researchers, clinicians, and
          developers who operate in the grey areas of open source, NIH,
          Open Access Journal, and MGB compliance.</div>
        <div
style="line-height: 1.38; margin: 0in 0in 8pt; font-family:
        Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri,
        Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"
          class="elementToProof"> The goal of MGB 1.0 is to provide
          developers who are building innovative technology within
          highly regulated health care environments with a permissive
          open source license that incorporates the best practices of
          digital health licensing, enabling compliant open source
          collaboration both across and external to AMCs.</div>
        <div
style="line-height: 1.38; margin: 0in 0in 8pt; font-family:
        Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri,
        Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"
          class="elementToProof"> Beyond addressing the open data, open
          source, and open access approaches of digital health
          researchers and software developers, MGB 1.0 also looks to
          support the rise of open AI model development that often
          utilizes sensitive health data for training purposes. Thus,
          although MGB 1.0 uses a similar licensing approach as Apache
          2.0, it expands its applicability to AI models and other
          shared works and derivatives spanning \u201cmodel architecture,
          code, data descriptions, data, and the model weights.\u201d This
          expanded scope is important because there are few open source
          licenses in current use that are suitable for releasing AI
          models and their related artifacts.</div>
        <div
style="line-height: 1.38; margin: 0in 0in 8pt; font-family:
        Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri,
        Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"
          class="elementToProof"> Through internal cross-functional
          approval MGB 1.0 is now the default open source license for
          emerging MGB research and innovations involving open science,
          and for over 500 active GitHub repositories authored and / or
          controlled by MGB clinicians, researchers, labs, and
          developers. The MGB Open Science Program Office manages the
          MGB IP Policy pertaining to open source licensing and drives
          compliance through the promotion of open science best
          practices.</div>
        <div
style="line-height: 1.38; margin: 0in 0in 8pt; font-family:
        Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri,
        Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"
          class="elementToProof"> Legal Analysis</div>
        <div
style="line-height: 1.38; margin: 0in 0in 8pt; font-family:
        Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri,
        Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"
          class="elementToProof"> Although MGB 1.0 uses a
          pro-commercialization, pro-modification, highly compatible
          licensing scheme similar to Apache 2.0, it is critically
          different in three ways: clarified patent terms, coverage of
          AI artifacts, and clarified interaction with data regulation.
          Licensors of open source software have long struggled with the
          ambiguities of the patent license grant in Apache 2.0. In this
          license each Contributor grants a no-charge patent license to
          the Work, applying to \u201cpatent claims that are necessarily
          infringed by their Contribution(s) or by the combination of
          their Contribution to the Work.\u201d  As evidenced by the AFL, and
          later, the GNU v3 licenses, all approved by OSI, there has
          been a shift in OSI license patent grants to language that
          \u201capplies only to specific set of patent claims\u2026that are
          embodied in the in the Original Work as furnished by the
          Licensor. [They are] not license[s] to the Licensor\u2019s entire
          patent portfolio.\u201c [Lawrence Rosen \u201cOpen Source Licensing \u2013
          Software Freedom and Intellectual Property Law\u201d p 189].</div>
        <div
style="line-height: 1.38; margin: 0in 0in 8pt; font-family:
        Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri,
        Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"
          class="elementToProof"> As Apache 2.0\u2019s patent grant features
          a broad patent grant application extending to those claims
          infringed by the combination of the original Work and a
          Contribution,  MGB 1.0 builds on Rosen\u2019s focused approach:
          \u201cclaims embodied by the original work,\u201d to explicitly apply to
          patent claims claiming inventions embodied in contribution.
          The license also leverages clarifying patent language from
          Section 2.3 of the Mozilla Public License version 2.0 also
          approved by OSI.     </div>
        <div
style="line-height: 1.38; margin: 0in 0in 8pt; font-family:
        Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri,
        Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"
          class="elementToProof"> MGB 1.0 was co drafted by myself,
          Marvin Barksdale JD, Preston Regehr Esq. of Tech Law Ventures
          PLLC, and Heather Meeker Esq. of Tech Law Partners LLP before
          being reviewed and approved for system use by Mass General
          Brigham\u2019s Office of General Counsel\u2019s IP Group. </div>
        <div
style="line-height: 1.38; margin: 0in 0in 8pt; font-family:
        Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri,
        Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"
          class="elementToProof"> Summary</div>
        <div
style="line-height: 1.38; margin: 0in 0in 8pt; font-family:
        Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri,
        Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"
          class="elementToProof"> MGB 1.0 provides express licensing
          provisions that are best practice in digital health, while
          explicitly preserving opportunities for commercial activity by
          licensors who are patent portfolio holders and innovators.  
          To these ends, MGB 1.0 utilizes a clearer approach than the
          MIT, BSD and Apache 2.0 licenses. Furthermore, MGB 1.0,
          explicitly contemplates the inclusion of AI model artifacts in
          the licensed work. Beyond the clarified patent grant, MGB 1.0
          also adds HIPAA acknowledgement language that will provide
          AMC\u2019s and other open source innovators sharing models trained
          on health data comfort that they can release materials under
          this license and still comply with law in a heavily regulated
          field. MGB 1.0 provides developers who are building innovative
          software within highly regulated health care environments with
          a permissive open source license that incorporates the best
          practices of digital health licensing, catalyzing compliant
          open source collaboration.</div>
        <div
style="line-height: 1.38; margin: 0in 0in 8pt; font-family:
        Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri,
        Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"
          class="elementToProof">  </div>
        <div
style="font-family: Aptos, Aptos_EmbeddedFont,
        Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size:
        11pt; color: rgb(0, 0, 0);" class="elementToProof"> <br>
        </div>
        <div class="elementToProof" id="Signature">
          <div
style="font-family: Aptos, Aptos_EmbeddedFont,
          Aptos_MSFontService, Calibri, Helvetica, sans-serif;
          font-size: 11pt; color: rgb(0, 0, 0);" class="elementToProof">
            <br>
          </div>
          <p
style="margin: 0in; font-family: Calibri, sans-serif;
          font-size: 11pt;" class="elementToProof"> <span
style="font-family: &quot;Calibri Light&quot;,
            sans-serif; font-size: 14.6667px; color: rgb(0, 0, 0);"><br>
            </span></p>
          <p
style="margin: 0in; font-family: Calibri, sans-serif;
          font-size: 11pt;" class="elementToProof">  </p>
        </div>
        <p class="MsoNormal">The information in this e-mail is intended
          only for the person to whom it is addressed.  If you believe
          this e-mail was sent to you in error and the e-mail contains
          patient information, please contact the Mass General Brigham
          Compliance HelpLine at <a
            href="https://www.massgeneralbrigham.org/complianceline"
            moz-do-not-send="true" class="moz-txt-link-freetext">https://www.massgeneralbrigham.org/complianceline</a>
          .</p>
        <br>
        <p class="MsoNormal">Please note that this e-mail is not secure
          (encrypted).  If you do not wish to continue communication
          over unencrypted e-mail, please notify the sender of this
          message immediately.  Continuing to send or respond to e-mail
          after receiving this message means you understand and accept
          this risk and wish to continue to communicate over unencrypted
          e-mail.  </p>
        <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>