<div dir="ltr">Hi Marvin,<div><br></div><div>I for one would ve very grateful if you would concisely highlight what you have changed here please.</div><div><br></div><div>Thanks</div><div><br></div><div>Simon</div><div>(in a personal capacity)</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Mar 3, 2025 at 6:28 PM Barksdale, Marvin <<a href="mailto:mbarksdale@mgb.org">mbarksdale@mgb.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg8913569016311582614">
<div lang="EN-US" style="overflow-wrap: break-word;">
<div class="m_7304349581277884727WordSection1">
<p class="MsoNormal"><i>I Marvin Barksdale JD, the license steward and license submitter, attests that this 2<sup>nd</sup> resubmission of the new “MGB 1.0” license complies with the Open Source Definition, including:</i><u></u><u></u></p>
<p class="MsoNormal"><i>OSD 3 – 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.</i><u></u><u></u></p>
<p class="MsoNormal"><i>OSD 5 – The license must not discriminate against any person or group of persons.</i><u></u><u></u></p>
<p class="MsoNormal"><i>OSD 6 – The license must not restrict anyone from making use of the program in a specific field of endeavor.
</i><u></u><u></u></p>
<p class="MsoNormal"><i>and OSD 9 – 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.<u></u><u></u></i></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u>License Rationale</u><u></u><u></u></p>
<p class="MsoNormal">The MGB Open-Source License 1.0 (“MGB 1.0”) is a permissive open-source software license that was drafted to catalyze open-source distribution and open science among the health care innovator and research community, particularly those employed
at Academic Medical Centers (AMCs) receiving federal grant funding, such as Mass General Brigham Incorporated (MGB). AMCs are hospitals, laboratories, and medical schools frequently collectively organized as systems, with a federally regulated mission to
provide patient care, train healthcare professionals, and conduct innovative research. As self-contained businesses, these complex organizations have evolved to perform several ancillary commercial functions including patent administration, licensing, co-development,
all of which to support their central mission of the advancement of medicine. Aligned with this central mission is the proliferation of open science innovation at AMCs. While AMCs have evolved their proprietary IP strategies, many of their research and
clinical employees have shifted to open science collaborative approaches where research data, methodologies, source code and findings are licensed to be shared at no cost to catalyze innovation. Despite both approaches purporting to be operating in the benefit
of AMC system goals, there has been a historical lack of alignment between open and proprietary licensing activity. At Mass General Brigham, for example, despite receiving over $77M in NIH funding over the past 10 years for 200+ software research projects
that should have yielded open-science results and commercial innovation, there is a large clandestine community of researchers, clinicians, developers, and other health care employees, who operate in the grey areas of open source, NIH, Open Access Journal,
and AMC compliance. The goal of MGB 1.0 is to bring open-source licensing into AMC licensing compliance, which mandates employees out-license AMC assets under express risk mitigation terms spanning several federal mandates and best practices including: HIPAA
laws not to share “Protected Health Information” and other personal info, federal 501 c-3 anti-endorsement laws, and licensing software on an “As-Is” basis without implied warranties, representations, and damages. These terms are not explicitly outlined in
similarly permissive licenses such as MIT and BSD, but all can align with fundamental principles of openness.
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Beyond bringing NIH funded researchers and health care innovators into an AMC compliant open-source licensing scheme, MGB 1.0 seeks to balance the modern AMCs mission driven commercialization activities with its scientific mission to break
down barriers to knowledge access and collaboration within healthcare. Although MGB 1.0 uses a similar pro-commercialization, pro-modification, highly compatible licensing scheme as Apache 2.0, MGB 1.0 aims to limit to its express patent license to the software
itself eg. claims embodied by the work, as well as to address the guidelines of the work’s inclusion of patient personal information. <u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u>Legal Analysis<u></u><u></u></u></p>
<p class="MsoNormal"><u><u></u><span style="text-decoration:none"> </span><u></u></u></p>
<p class="MsoNormal">Patent law’s broad definition of infringement and the courts broad interpretation of the Doctrine of Equivalence (DoE) sits at the center of MGB 1.0 patent grant approach. 35 USC 271 states that “for a licensee to successfully assert
that their contribution or derivative work is infringing on a patent, the licensee must show that they are making, using, selling, etc. some thing or process that is covered by the patent.” Thus, via 35 USC 271, showing infringement requires performing a
comparison between “a patented invention’s claim” and “whatever it is that the defendant makes, uses, offers to sell, or sells.” According to the court in Bai v. L L Wings, Inc., "determining whether a patent claim has been infringed involves two steps: (1)
claim construction to determine the scope of the claims, followed by (2) determination whether the properly construed claim encompasses the accused structure. The first step, claim construction, is a matter of law. . . . The second step, determination of infringement,
whether literal or under the doctrine of equivalents , is a question of fact." <u></u>
<u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Thus, while OSD 9 demands that the licensee must be free to use the licensed software free of any potential claim for infringement under any infringement theory,” Apache 2.0’s patent grant to infringing claims extends beyond the use of
the licensed software, to granting patents to claims that may contain other “equivalent” non-licensed software. This concept is consistent with, Winans v Denmead, where the courts found patent infringement reaching beyond literal infringement of patent claims
either by way of a “insubstantial differences” test or a ‘‘function-way-result” test, both of which requiring a difficult factual assessment for the jury (or judge in a bench trial). Presenting even more uncertainty for potential infringers, courts have
more recently found an additional way to prove equivalency by showing that the accused equivalent and the claimed patent feature were known “in the art” to be used interchangeably. Hilton Davis v Warner-Jenkinson. MGB 1.0 maintains the licensee’s ability
to use the licensed software free of infringement under even a DoE infringement theory, but ensures the patent grant is narrowed to the software only; without putting burden on contributors to decipher difficult questions of fact to figure out the extent of
the patent grant beyond literal infringement of the software. <u></u><u></u></p>
<p class="MsoNormal">MGB 1.0’s approach in narrowing the scope of the grant to the software itself eg the use of “embodied” over “infringed”, is similar to the patent grant mechanism utilized by the osi approved AFL and the GNU v3 license, which narrows the
claims granted only to “essential patent claims,” not including “claims that would be infringed only as a consequence of further modification of the contributor version.” Similarly these licenses intend to narrow their patent grants to claims that are essential
to open source distribution of the licensed copyrighted IP, and not to claims that aren’t embodied by the copyrighted IP or that would be infringed only as a consequence of further modification of the contributor version.
<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Accordingly, an example where the Apache 2.0 license can be utilized to obtain a patent license beyond what is embodied a claim, would be via MGB filing a patent with multiple claims; where open source code is embodied in one claim [A]
, and closed source software is embodied in another [B]. Under Apache 2.0, this patent filing scheme creates an opportunity for contributors to intentionally infringe on claim [B] (which includes separate non open source code), by contributing code that infringes
on [B] through DoE. Although this is accepted DoE infringement via us patent case law, infringing on other claims that include separate non open source code is beyond what is necessary for a licensee to freely use the open source licensed software itself.
This intent to “contract around" infringement overreach (eg beyond the software itself), to narrowly confine open source license patent grants to the licensed software itself, is observable across several osi licenses including the aforementioned AFL and BNU
v3. <u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">MGB 1.0 was co drafted by myself, Marvin Barksdale JD, and Preston Regehr Esq. of Tech Law Ventures PLLC, before being reviewed and approved for system use by Mass General Brigham’s Office of General Counsel’s IP Group.
<u></u><u></u></p>
<p class="MsoNormal"><br>
<u>Summary<u></u><u></u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">MGB 1.0 provides express licensing risk provisions required by AMC Tech Transfer and General Counsel Offices while protecting AMC commercial activity as a patent portfolio holder and as an ongoing code contributor via AMC resources. To
these ends MGB 1.0 utilizes a more direct risk mitigation approach than the MIT or BSD licenses. Furthermore, although MGB 1.0 uses a similar approach to Apache 2.0, MGB 1.0 narrowly confines the express license grant to the software itself or patent claims
owned or controlled by the Contributor that are embodied in the shared work. Beyond the patent grant, MGB 1.0 also adds HIPAA risk mitigation language that is imperative as osi has defined open source ai as including the shared data by which it was trained.
This language is imperative for AMC’s and their open source ai innovators potentially sharing patient data with licensees unfamiliar with HIPAA obligations.
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><b><span style="font-family:"Calibri Light",sans-serif;color:rgb(0,156,166)">__________________</span></b><span><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:16pt;font-family:"Calibri Light",sans-serif;color:black">Marvin Barksdale</span><span style="font-family:Calibri,sans-serif"><u></u><u></u></span></p>
<p class="MsoNormal"><u></u> <u></u></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" target="_blank">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></div>
_______________________________________________<br>
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 <a href="http://opensource.org" rel="noreferrer" target="_blank">opensource.org</a> email address.<br>
<br>
License-review mailing list<br>
<a href="mailto:License-review@lists.opensource.org" target="_blank">License-review@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" rel="noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a><br>
</div></blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div style="color:rgb(34,34,34)"><b>Simon Phipps</b> </div><div style="color:rgb(34,34,34)"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><font size="1"><i>Office:</i> <span title="Call with Google Voice"><span title="Call with Google Voice"><span title="Call with Google Voice">+1 (415) 683-7660</span></span></span> <i>or</i> +44 <span title="Call with Google Voice"><span title="Call with Google Voice"><span title="Call with Google Voice">(238) 098 7027</span></span></span></font></div><div><font size="1"><i>Signal/Telegram/Mobile</i>: +44 <span title="Call with Google Voice"><span title="Call with Google Voice"><span title="Call with Google Voice">774 776 2816</span></span></span></font></div></div></div></div></div></div></div></div><div><font size="1"><br></font></div></div></div></div></div></div>