<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Dear Marvin,</p>
<p>I haven't review the license completely, but based on your email
it sounds like you are trying to do something that you just can't
do with an open source license. Open source licenses assure that
no patent owned by the open source licensor will be asserted
against someone using the software. The boundaries are somewhat
different in different licenses, but they do ensure that one can
use the version of the software released by the licensor without a
threat of a patent claim. That is why the patent grant in the open
source license is measured by infringement - a license is granted
for any potential infringement, no matter what the theory. It
sounds like your patent "trolls" may simply be asking for the
rights that an open source license granted them. <br>
</p>
<p>You license grants a patent license "only to the extent such
patent claims are necessary for a person with ordinary skill in
the art to recreate the Work or create Derivative Works thereof."
It doesn't grant a license to run the software and from your
explanation it sounds like that is intentional. The patent grant
in a FOSS license must be for all possible uses of the code. So
you can't grant a license to copy, modify and distribute the code
but not also run the software. <br>
</p>
<p>I also don't think section 7 is acceptable. It expressly states
that some part of the licensed work is not subject to the license
grant, which is an impermissible restriction. I understand your
motive, but there is a difference between someone's duty to comply
with the law and making it a contractual obligation. Making it a
contractual obligation is what makes it an unacceptable
restriction on the use of the software. It also seems unfair to
the licensee - how are they supposed to know what and whether
there is PII in the Work? Particularly if it's become part of a
model? I assume the motive was to try to avoid liability, but will
that actually happen if you are making software (or data, graphs
or models) available to third parties? Don't you have liability
for PII merely by giving it to third parties, and therefore should
have sanitized it before making it publicly available?</p>
<p>The open source ecosystem only works because anyone can use the
software for any purpose without having to worry about getting
sued by the licensor. Many, many others have had the same desire
to preserve patent rights, including where there are competing
divisions with different motives and goals, and encountered this
dilemma. The result is that they either don't use an open source
license or they get comfortable with the position that the benefit
of using an open source license outweighs the loss of the
exclusivity of patent. But there isn't a solution whereby some
patent rights can be preserved.</p>
<p></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><br>
<br>
<br>
</div>
<div class="moz-cite-prefix">On 2/4/2025 3:51 PM, Barksdale, Marvin
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:BY5PR04MB6550387D8034F1055FD5697DCEF42@BY5PR04MB6550.namprd04.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style>@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face
{font-family:"Calibri Light";
panose-1:2 15 3 2 2 2 4 3 2 4;}@font-face
{font-family:Aptos;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Aptos",sans-serif;
mso-ligatures:standardcontextual;}span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Aptos",sans-serif;
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-size:11.0pt;}div.WordSection1
{page:WordSection1;}</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<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:<o:p></o:p></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.<o:p></o:p></i></p>
<p class="MsoNormal"><i>OSD 5 – The license must not
discriminate against any person or group of persons.<o:p></o:p></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.
<o:p></o:p></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.<o:p></o:p></i></p>
<p class="MsoNormal"><i><o:p> </o:p></i></p>
<p class="MsoNormal"><u>License Rationale<o:p></o:p></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.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></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.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><u>Legal Analysis<o:p></o:p></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."
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></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. <o:p></o:p></p>
<p class="MsoNormal"><br>
<u>Summary</u><o:p></o:p></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. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></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"><o:p></o:p></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"><o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><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"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri
Light",sans-serif;color:black;mso-ligatures:none"><a class="moz-txt-link-abbreviated" href="mailto:mbarksdale@mgb.org">mbarksdale@mgb.org</a></span><span
style="mso-ligatures:none"><o:p></o:p></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"><o:p></o:p></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"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-ligatures:none"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-family:"Calibri",sans-serif;mso-ligatures:none"><o:p> </o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></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" 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>