<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Just to further comment on Pam's comments on the patent grant:</p>
<p>From your rationale, it seems like you are trying to contract
around the doctrine of equivalents (DoE). I don't think the
language you have in the license really does that, and seems to
conflate the PHOSITA analysis of obviousness under patent law with
the DoE (I know that DoE does use "person skilled in the art" in
some leading cases -- Warner-Jenkins for example -- but that is
narrowed to what constitutes and equivalent, which is not what the
language of your license says).</p>
<p>Nevertheless, I'm not aware that there's any support in the case
law in the USA that you can contract around DoE. Under the
rationale of Quanta/LGE, I don't see how you can reach that result
(if you can't contract around patent exhaustion, I don't see that
you could contract around patent exhaustion of equivalents). If
you've got support for that concept, I certainly would be
interested in hearing it.</p>
<p>Even if you can contract around DoE, reserving certain patent
rights -- i.e., DoE patent rights -- against the very code you
release under an open source license likely violates OSD 7
explicitly or implicitly.</p>
<p>I also don't think this license really even solves the problem
you identify. "Patent trolls" -- at least as that terms is
generally understood -- are entities that have no business other
than compiling and asserting patents. A restriction on the patent
rights granted to them under an open source license really has no
effect if they don't have a business and aren't using open (or
closed) source code. For those entities that do use open source
code, the concept of open source (and again OSD 7, as written or
as currently interpreted by OSI) is that they don't have to get
additional rights from a software author after accepting the terms
of the open source license. An extra license to get DoE infringed
patents would be that. I note that your license -- like Apache --
has a "defensive patent termination clause" which allows for the
grant of patent rights to be terminated in the event that a
recipient asserts patents against the very code that they are
availing themselves of. So cabinning the patent grant itself would
be unnecessary in light of this clause, unless you are attempting
to have the right to not grant patent rights to users who might at
any time in the future sue the author for patent infringement for
anything, even things beyond the license code. I think in general
this scope of termination is now disfavored (although at least one
OSI license -- CPL -- has the concept).</p>
<p> <br>
</p>
<div class="moz-cite-prefix">On 2/9/2025 10:17 PM, Pamela Chestek
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:b2c019ec-edc5-a449-0066-751baceec7ab@chesteklegal.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<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>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" moz-do-not-send="true">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 moz-txt-link-freetext"
href="mailto:mbarksdale@mgb.org" moz-do-not-send="true">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 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>