<div>Marvin,</div><div style="font-family: Arial, sans-serif; font-size: 14px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);"><br></div><div style="font-family: Arial, sans-serif; font-size: 14px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">As a non-lawyer, this seems to not be OSD compliant as it does not clearly provide a patent license to allow a user to run the software.<br><br>Could you elaborate on the problems that all AMCs are having in open source licensing? In particular, is there an AMC that has figured out how to license any software under any open source license? If so, why not use that license?</div><div class="protonmail_signature_block protonmail_signature_block-empty" style="font-family: Arial, sans-serif; font-size: 14px;">
<div class="protonmail_signature_block-user protonmail_signature_block-empty">
</div>
<div class="protonmail_signature_block-proton protonmail_signature_block-empty">
</div>
</div>
<div style="font-family: Arial, sans-serif; font-size: 14px;"><br>Eric<br></div><div class="protonmail_quote">
On Tuesday, February 4th, 2025 at 5:51 PM, Barksdale, Marvin <mbarksdale@mgb.org> wrote:<br>
<blockquote class="protonmail_quote" type="cite">
<div class="WordSection1">
<p class="MsoNormal"><i>I Marvin Barksdale JD, the license steward and license submitter, attests that this new “MGB 1.0” license complies with the Open Source Definition, including:</i></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></p>
<p class="MsoNormal"><i>OSD 5 – The license must not discriminate against any person or group of persons.</i></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></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.</i></p>
<p class="MsoNormal"><i> </i></p>
<p class="MsoNormal"><u>License Rationale</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 and laboratories, frequently collectively organized, that are integrated with a medical school, 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 employes 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 been open and proprietary licensing. 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.
</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Beyond bringing NIH funded researchers and health care innovators into an AMC compliant open-source licensing scheme, MGB 1.0 aims 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, it limits an express patent license to the foundational purpose
of openness: recreating and making derivatives of the shared work. The Apache 2.0 license has long been prohibited by Mass General Brigham and other AMCs, as instead of a reasonable open source aligned license to patents needed to recreate the shared work,
it opens the door to a license to all claims infringed by a contribution to the work. AMC counsel has defended AMCs in the past from patent trolls who have attempted to utilize “infringement” to gain unintended patent rights, and in light of MGB’s $15Million
dollar per year patent registration spend, it, like other AMCs, is committed to a conservative position on granting possibly exploitive patent rights for the purpose of open science distribution.
</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">MGB looks forward to putting the full weight of its internal and external resources behind its Open Science Program Office, the MGB Open Science Digital Hub, and an OSI approved open-source License. As the largest driver of NIH research
funding in the country and a member of a number of influential Health Care Data Ai Consortiums, MGB promoting an OSI approved license as its default open-source approach presents an exciting opportunity to bring more health care innovators closer to the open-source
developer community through thoughtful governance, as well as to catalyze the above ground adoption of Open Source best practices throughout AMCs.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><u>Legal Analysis</u></p>
<p class="MsoNormal">The question has been posed: “How is MGB 1.0s Patent License not the legal equivalent of the Apace 2.0 patent license?” Patent law’s broad definition of infringement and the courts broad interpretation of the Doctrine of Equivalence sits
at the center of MGBs divergence in 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."
</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">For more than 150 years (dating back to the 1853 Supreme Court case Winans v Denmead), courts have 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. Ultimately, just as the Supreme Court in Davis opined that “the doctrine of equivalents, when applied
broadly, conflicts with the definitional and public-notice functions of [patent] requirements,” the doctrine of equivalents when applied broadly as the rationale for granting a patent license via the Apache 2.0 license may conflict with OSD 5 by discriminating
against patent owners who are later opened up to patent trolling beyond literal infringement. By subjecting licensors to infringement claims of interchangeability in the art that arise after their license grant, Apache 2.0 and other osi licenses that included
express patent grants, may unfairly prejudice licensors managing patent portfolios via patent exposure.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Accordingly, an example where the Apache license can be trolled for expanded patent access would be in cases of "overlapping infringement." Here, a single work can potentially infringe on two similar patents when the work incorporates elements
that fall within the claims of both patents, meaning it essentially "uses" aspects of both inventions without permission from the same or different patent holder. Eg, A researcher at Mass General Brigham creates patented process [A] to create a protein that
includes a generative AI algorithm [B] for 3d mapping that is released open source under Apache 2.0. Sometime later another MGB research lab creates a patented process [C] to create a protein using a different proprietary generative AI technique [D] to achieve
the same goal, featuring similar data structure and harness, different mapping tech, but a broad patent claim with less limitations and no open source elements. Here a Licensee troll can license Open Source work [B], and create a derivative work from it that
is similar but not identical to patent [C], but then claim an express license to patent [C] via Apache, if the derivative work contribution they’ve created infringes on C via “providing substantially the same function in substantially the same way to obtain
the same result (mapping a protein)" to patent [C]. As AMCs frequently manage and administer their own overlapping patents in the same area with different IP strategy outlooks, Apache's approach of triggering a patent license via infringement can have unintended
results, especially considering the doctrine of equivalents as a test for infringement. Using the MGB 1.0 License, as Patent C isn’t necessary to the use, sale, or distribution of work B, C would be rightfully excluded from the patent license in favor of
A.</p>
<p class="MsoNormal"> </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. This Group proposed
an additional hypothetical under which the MGB 1.0 license provides a preferred risk mitigation outcome. In scenarios where a patent contains sperate unified claims, for example a patent including claims for making and driving a “car.” In one possible scenario
under this hypo, an open source author wants to release “how to make the car” code via the MGB 1.0 license, but a nefarious licensee (“npe”) wanted to gain a free patent to “drive the car” as well. As a patent claim to “driving the car” would not be necessary
to be able to recreate the source code around “making the car”, the npe would not gain the unintended patent access. In a circumstance where the inventor wants to MGB 1.0 license “how to drive the car”, similarly a npe would not obtain patent rights surrounding
the cars design & construction as in the scope of the MGB 1.0 license’s intent, it is not necessary to have the patent to make / sell the car in order to replicate the source code to drive it. If the open source author / inventor wanted to MGB 1.0 license
code to both “make and drive the car”, then the included code and readme files would reflect both and accordingly licensees would receive both. As MGB 1.0 utilizes an express patent based on “claims” rather than “infringement”, inventors have superior patent
flexibility to express patent licenses such as Apache 2.0. </p>
<p class="MsoNormal"><br>
<u>Summary</u></p>
<p class="MsoNormal">MGB 1.0 provides express open source code 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 compatibility and license modification approach to Apache 2.0, MGB 1.0 more reasonably confines
the express license grant to the foundational principal of open source, a grant to those patent claims that are necessary for a person with ordinary skill in the art to recreate the Work or create Derivative Works. The Apache 2.0 adds a high level of uncertainty
to patent owners who shouldn’t be discriminated against or chilled from releasing work in an open-source schema where patents unnecessary for recreating the work are granted to open source trolls who claim patent infringement through the doctrine of equivalence
via interchangeability in the art or otherwise. </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><b><span style="font-family:"Calibri Light",sans-serif;color:#009CA6;mso-ligatures:none">__________________</span></b><span style="mso-ligatures:none"></span></p>
<p class="MsoNormal"><span style="font-size:16.0pt;font-family:"Calibri Light",sans-serif;color:black;mso-ligatures:none">Marvin Barksdale, JD</span><span style="mso-ligatures:none"></span></p>
<p style="text-autospace:none" class="MsoNormal"><span style="font-family:"Calibri Light",sans-serif;color:black;mso-ligatures:none">Associate Director, Business Development and Digital Health, Innovation
</span><span style="font-family:"Calibri",sans-serif;mso-ligatures:none"></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri Light",sans-serif;color:black;mso-ligatures:none">mbarksdale@mgb.org</span><span style="mso-ligatures:none"></span></p>
<p class="MsoNormal"><b><span style="font-size:12.0pt;font-family:"Calibri Light",sans-serif;color:black;mso-ligatures:none">Mass General Brigham</span></b><span style="mso-ligatures:none"></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri Light",sans-serif;mso-ligatures:none">399 Revolution Drive, Suite 955, Somerville, MA 02145</span><span style="mso-ligatures:none"></span></p>
<p class="MsoNormal"><span style="mso-ligatures:none"> </span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;mso-ligatures:none"> </span></p>
<p class="MsoNormal"> </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" rel="noreferrer nofollow noopener">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>
</blockquote><br>
</div>