<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 2/11/2025 9:38 PM, Barksdale, Marvin
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:BY5PR04MB65501F79C6EDCDE7ED44C0B2CEFC2@BY5PR04MB6550.namprd04.prod.outlook.com">
<pre wrap="" class="moz-quote-pre">Sincere thanks for the feedback Pam and Mccoy, and for the opportunity to better clarify what we're trying to accomplish in the proposed MGB licensed.
Simply put, MGB's goals for MGB 1.0 are to:
1. Limit the express patent license to patent claims owned by the Contributor that are embodied in the Work, rather than the infringement express patent license standard of Apache 2.0 and similar licenses.
2. Address public policy interests around the unlawful distribution of HIPAA protected private information.
I apologize for potentially convoluting the core issues with the narrative elements of the request, as I believe that to at least be partially the case by Pam's assertion that the specificity desired in #1 above "cant be done." While a patent gives its owner the right to exclude others from making, using, and selling an invention, such patented invention may be comprised of several claims, consisting of separate copyrightable source code bases. Thus, while an open source license denotes that anyone should be able to view and use the code and modify it for his own purposes, that does not assure the patent owner - licensor has decided to open source the entire invention (e.g. the open source code may sit within proprietary IP as part of a separate claim). Furthermore, I don't believe "No patent owned by the licenser will be asserted against the software user" is the true assurance given by open source licenses. This assertion that licensors will not assert any patent they own or control against the licensee is a clear slippery slope with the potential to chill innovation. I believe the open source license patent assurance that "No patent claim that is embodied in the software will be asserted against the software user" will satisfy the tenets of free software as have been described. This approach, clarifying the distinction between patented inventions and copywritten open source software, has been well addressed across a number of industries as well as in past open source licenses, most notably by the express patent grant of the AFL 3.0 license by Lawrence Rosen which grants:
"a worldwide, royalty-free, non-exclusive, sublicensable license, under patent claims owned or controlled by the Licensor that are embodied in the Original Work as furnished by the Licensor, for the duration of the patents, to make, use, sell, offer for sale, have made, and import the Original Work and Derivative Works."
Utilizing the previous example of a patent for a proprietary car that includes a claim that includes open source software to steer the car, as the claims to the car itself are not embodied in the open source steering software claim, the AFL patent license would not include patent rights to use, sell, or make the car itself. The Apache 2.0 license's patent grant, in contrast, may be interpreted to enable patent rights to the car itself, as it grants contributors "a license to claims infringed by the Contribution to Work." Thus Apache 2.0 is a much wider net with potentially unintended consequences, compared to a license to "claims embodied in the Work." (APL 3.0). Pending approval from MGB's IP Group, if utilizing the APL 3.0 patent grant moves the collective osi reservations to the current MGB 1.0 grant, I can envision an outcome that preserves the flow of open IP, catalyzes scientific research, and enables patent administration activity the space.</pre>
</blockquote>
<p>I've got to say, the explanation here is quite confusing as it
seems to switch between the Academic Free 3.0 license and the
Apache 2.0 license but it's not clear which of these licenses you
are concerned with. If MGB is intended to be a variant of Apache,
you might want to focus on that. Or if you want to take Apache,
but substitute out the Academic Free patent grant as you think it
is better written or more constrained, maybe do that rather than
creating a wholly different patent grant.</p>
<p>Nevertheless, some of the things you say here just don't comport
with the text of the licenses you are analyzing. For example, "<span
style="white-space: pre-wrap">The Apache 2.0 license's patent grant, in contrast, may be interpreted to enable patent rights to the car itself, as it grants contributors "a license to claims infringed by the Contribution to Work."" Both Work and Contribution are specifically defined in the Apache 2.0 license as works of authorship which are either submitted (Contribution) or made available under the license. Work of authorship is a specific term stemming from the copyright law (17 USC 102a). A car is not going to be a work of authorship, nor is a Contribution going to be "</span><span
style="color: rgb(51, 51, 51); font-family: serif; font-size: 16px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 300; letter-spacing: normal; orphans: 2; text-align: justify; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;">intentionally
submitted to Licensor for inclusion in</span><span
style="white-space: pre-wrap">" the car. It *would* encompass any software used with the car which was licensed under Apache and which the person making a Contribution submitted it to. So the idea that Apache 2.0 has a patent overbreadth problem, at least in the example you have proposed, is really not consistent with the terms of that license.</span></p>
<p><span style="white-space: pre-wrap">It's good you're rethinking the original submission, as it had some significant flaws (both in the drafting, and in conformance with OSD) but you may want to rethink some of the premises surrounding the whole reason why you think this license is necessary.</span><span
style="white-space: pre-wrap"> If you think that you want a permissive license with a narrower patent grant than the current permissive licenses out there, you probably want to follow the text of those licenses and show what patent claims you don't want your license to grant, and why not granting those claims doesn't force users of the software to go to the authors of that software and get a separate patent license, thus violating OSD 7 (explicitly or implicitly).
</span></p>
<blockquote type="cite"
cite="mid:BY5PR04MB65501F79C6EDCDE7ED44C0B2CEFC2@BY5PR04MB6550.namprd04.prod.outlook.com">
<pre wrap="" class="moz-quote-pre">Regarding aim #2 above, MGB 1.0's current section 7 was drafted in the guise of the potential for unenforceability of an open source license to shared patient data on the grounds of illegality due to HIPAA. As a steward of sensitive patient information, MGB must continuously weigh the scientific value open science and open source distribution against the legal obligation to secure patient data. </pre>
</blockquote>
<p>The point Pam made, as did I, is that the legal obligation
already exists (HIPAA, as well as other privacy laws), so it is
not something that needs to be included in a license. And by
including it in a license, as a restriction, it violates OSD 6
(and maybe 5).</p>
<p>Other licenses have addressed this issue by not imposing a
restriction within the license, but instead merely warning users
they either have to comply with other laws in general, or specific
laws of concern: <a class="moz-txt-link-freetext" href="https://opensource.org/license/intel">https://opensource.org/license/intel</a> (as an
example). So a clause that says something like "this license may
contain medical privacy information covered by HIPAA or other
privacy laws. Although this license does not impose restrictions
on that information, it is your responsibility to comply with any
and all laws or regulations that govern that information" would
likely be OK.<br>
</p>
<blockquote type="cite"
cite="mid:BY5PR04MB65501F79C6EDCDE7ED44C0B2CEFC2@BY5PR04MB6550.namprd04.prod.outlook.com">
<pre wrap="" class="moz-quote-pre">That said, I believe there's room for re-drafting this clause, to remove the restriction in this section but still address public policy. Although, we do not want licensees to be obligated to remove PHI, some acknowledgement of PHI due to the limitations of data science is also appropriate here. Although all data stewards possess the obligation to de-identify data before it is shared, the risk of identifying an individual using the data can only be reduced to extremely small levels, never to a non-existent one. Ultimately, as long as MGB can assert that it has no obligation to provide PHI & validate data, I believe we've balanced our duties as steward of data and stewards of an open science license,
-Go Forth-
With the understanding that a full review of revised language has its own process, if these revisions appear reasonable conceptually, I would like to proceed with submitting a revised version of MGB 1.0 for review. While we are in full alignment that anyone should be able use the Software for any purpose without having to worry about getting sued by the licensor., we strongly believe that said assurance should only extend to that open source Software, not to other software, or necessarily to an entire patentable invention. If preliminarily my suggestions for revisions still remain to appear not possible, I welcome said feedback and another opportunity to propose solutions.
__________________
Marvin Barksdale, JD
-----Original Message-----
From: License-review <a class="moz-txt-link-rfc2396E" href="mailto:license-review-bounces@lists.opensource.org"><license-review-bounces@lists.opensource.org></a> On Behalf Of <a class="moz-txt-link-abbreviated" href="mailto:license-review-request@lists.opensource.org">license-review-request@lists.opensource.org</a>
Sent: Monday, February 10, 2025 12:51 PM
To: <a class="moz-txt-link-abbreviated" href="mailto:license-review@lists.opensource.org">license-review@lists.opensource.org</a>
Subject: License-review Digest, Vol 137, Issue 7
External Email - Use Caution
Send License-review mailing list submissions to
<a class="moz-txt-link-abbreviated" href="mailto:license-review@lists.opensource.org">license-review@lists.opensource.org</a>
To subscribe or unsubscribe via the World Wide Web, visit
<a class="moz-txt-link-freetext" href="http://secure-web.cisco.com/1V2dOu-nVMsk0pjiVv5kG9ZXUIX2u3oPaLAez08Ts-1vMWcvQFNXwTKGdTpbfwQZZDp7AomIhQfYBxDa8xXol6jqx6mbzJydJc7TdPdX2F_H5SRYhYvgyP_srhWfIWixRY0cSRo9kg5D-8RykfnvZiYQxRo3CHmmBUIA_z6GlAXiLvPRMbvx-fWxJsBWaJqNi8YF99ItJEr8AFvSg_gpxLwCF_nIPclSaVlq5FKxEFDkRZJmfJVLy-JNS5MjEU5aMUgoHgorQXKEGtirNc9TtSFh2Rb-UU5D1186F3oLdm46nyC2wqGEMeHSf9EyajKuO/http%3A%2F%2Flists.opensource.org%2Fmailman%2Flistinfo%2Flicense-review_lists.opensource.org">http://secure-web.cisco.com/1V2dOu-nVMsk0pjiVv5kG9ZXUIX2u3oPaLAez08Ts-1vMWcvQFNXwTKGdTpbfwQZZDp7AomIhQfYBxDa8xXol6jqx6mbzJydJc7TdPdX2F_H5SRYhYvgyP_srhWfIWixRY0cSRo9kg5D-8RykfnvZiYQxRo3CHmmBUIA_z6GlAXiLvPRMbvx-fWxJsBWaJqNi8YF99ItJEr8AFvSg_gpxLwCF_nIPclSaVlq5FKxEFDkRZJmfJVLy-JNS5MjEU5aMUgoHgorQXKEGtirNc9TtSFh2Rb-UU5D1186F3oLdm46nyC2wqGEMeHSf9EyajKuO/http%3A%2F%2Flists.opensource.org%2Fmailman%2Flistinfo%2Flicense-review_lists.opensource.org</a>
or, via email, send a message with subject or body 'help' to
<a class="moz-txt-link-abbreviated" href="mailto:license-review-request@lists.opensource.org">license-review-request@lists.opensource.org</a>
You can reach the person managing the list at
<a class="moz-txt-link-abbreviated" href="mailto:license-review-owner@lists.opensource.org">license-review-owner@lists.opensource.org</a>
When replying, please edit your Subject line so it is more specific than "Re: Contents of License-review digest..."
Today's Topics:
1. Re: Request for approval of new "MGB 1.0" license (McCoy Smith)
----------------------------------------------------------------------
Message: 1
Date: Mon, 10 Feb 2025 09:50:06 -0800
From: McCoy Smith <a class="moz-txt-link-rfc2396E" href="mailto:mccoy@lexpan.law"><mccoy@lexpan.law></a>
To: <a class="moz-txt-link-abbreviated" href="mailto:license-review@lists.opensource.org">license-review@lists.opensource.org</a>
Subject: Re: [License-review] Request for approval of new "MGB 1.0"
license
Message-ID: <a class="moz-txt-link-rfc2396E" href="mailto:3e6de48c-3d1a-4780-b2b6-4e767b88f77c@lexpan.law"><3e6de48c-3d1a-4780-b2b6-4e767b88f77c@lexpan.law></a>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Just to further comment on Pam's comments on the patent grant:
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).
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.
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.
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).
On 2/9/2025 10:17 PM, Pamela Chestek wrote:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">
Dear Marvin,
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.
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.
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?
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.
Pam
Pamela S. Chestek (in my personal capacity) Chestek Legal PLEASE NOTE
OUR NEW MAILING ADDRESS
4641 Post St.
Unit 4316
El Dorado Hills, CA 95762
+1 919-800-8033
pamela@chesteklegal
<a class="moz-txt-link-freetext" href="http://secure-web.cisco.com/1Vnr39saMdYB1uGYtVjEHGA5ehh7aaC4Ta0mgPput7">http://secure-web.cisco.com/1Vnr39saMdYB1uGYtVjEHGA5ehh7aaC4Ta0mgPput7</a>
cMsD4F_nqYHVswUkTKd-7Mha0f9yYLrSB1FbulSSBv-SceMLBQgVGYYEJSFY_RdYv6ckS5
ZlmsEfuDnugDC4jVbrpackj70p2DBfkgw5_ctA7cNiN5G6Py4dJw6BmwB3J4SMt-Le6Gmh
tVFiPF-2Efd21al55zi5SA6G9bq0JybR9B7Bzde-5MTaJQMJCVwbQm_x93iYFUTFg6LUy9
KF7F2I3nwK3ISc6iAXZL10GSeTRMvMl_u4j37eSoZurcius4a81GV9LMKIrHwxfracD9a/
http%3A%2F%2Fwww.chesteklegal.com
On 2/4/2025 3:51 PM, Barksdale, Marvin wrote:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">
/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:/
/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./
/OSD 5 ? The license must not discriminate against any person or
group of persons./
/OSD 6 ? The license must not restrict anyone from making use of the
program in a specific field of endeavor. /
/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./
//
_License Rationale_
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.
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.
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.
_Legal Analysis_
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."
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.
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.
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.
_Summary_
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.
*__________________*
Marvin Barksdale, JD
Associate Director, Business Development and Digital Health,
Innovation
<a class="moz-txt-link-abbreviated" href="mailto:mbarksdale@mgb.org">mbarksdale@mgb.org</a>
*Mass General Brigham*
399 Revolution Drive, Suite 955, Somerville, MA 02145
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 class="moz-txt-link-freetext" href="https://secure-web.cisco.com/1bBPUo45QSjz7m7jkZFZVuVQrWaNI4Fn3ozTCe1tbmTVbRUvmC6GHcn1wyJAiFCow3-8fclQ04K-BIPEz3SI8_Zqh0_DP0VEFD6EmiQ51llRUbnNTTRoczxsn8Qjc4hD1e34MbAzSGkqhQ_EAqPel-CHyFg9SNdsNbUFL1i--Hp1mSbtNqnzoYuiMBN_LKAhcUjlLCzhZkl33E_VbNCApR1bRHTSWf2ftHZmYsM-t-UH1FVJ3s_3W8ymV-EMijF8NonCTJq3xCCAr-bTBoViqputysc7lkZVA7spUcDESfhU0WPTK6SIr1ww16XBmwELQ/https%3A%2F%2Fwww.massgeneralbrigham.org%2Fcomplianceline">https://secure-web.cisco.com/1bBPUo45QSjz7m7jkZFZVuVQrWaNI4Fn3ozTCe1tbmTVbRUvmC6GHcn1wyJAiFCow3-8fclQ04K-BIPEz3SI8_Zqh0_DP0VEFD6EmiQ51llRUbnNTTRoczxsn8Qjc4hD1e34MbAzSGkqhQ_EAqPel-CHyFg9SNdsNbUFL1i--Hp1mSbtNqnzoYuiMBN_LKAhcUjlLCzhZkl33E_VbNCApR1bRHTSWf2ftHZmYsM-t-UH1FVJ3s_3W8ymV-EMijF8NonCTJq3xCCAr-bTBoViqputysc7lkZVA7spUcDESfhU0WPTK6SIr1ww16XBmwELQ/https%3A%2F%2Fwww.massgeneralbrigham.org%2Fcomplianceline</a> .
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.
_______________________________________________
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://secure-web.cisco.com/1V2dOu-nVMsk0pjiVv5kG9ZXUIX2u3oPaLAez08Ts">http://secure-web.cisco.com/1V2dOu-nVMsk0pjiVv5kG9ZXUIX2u3oPaLAez08Ts</a>
-1vMWcvQFNXwTKGdTpbfwQZZDp7AomIhQfYBxDa8xXol6jqx6mbzJydJc7TdPdX2F_H5S
RYhYvgyP_srhWfIWixRY0cSRo9kg5D-8RykfnvZiYQxRo3CHmmBUIA_z6GlAXiLvPRMbv
x-fWxJsBWaJqNi8YF99ItJEr8AFvSg_gpxLwCF_nIPclSaVlq5FKxEFDkRZJmfJVLy-JN
S5MjEU5aMUgoHgorQXKEGtirNc9TtSFh2Rb-UU5D1186F3oLdm46nyC2wqGEMeHSf9Eya
jKuO/http%3A%2F%2Flists.opensource.org%2Fmailman%2Flistinfo%2Flicense
-review_lists.opensource.org
</pre>
</blockquote>
<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://secure-web.cisco.com/1V2dOu-nVMsk0pjiVv5kG9ZXUIX2u3oPaLAez08Ts">http://secure-web.cisco.com/1V2dOu-nVMsk0pjiVv5kG9ZXUIX2u3oPaLAez08Ts</a>-
1vMWcvQFNXwTKGdTpbfwQZZDp7AomIhQfYBxDa8xXol6jqx6mbzJydJc7TdPdX2F_H5SRY
hYvgyP_srhWfIWixRY0cSRo9kg5D-8RykfnvZiYQxRo3CHmmBUIA_z6GlAXiLvPRMbvx-f
WxJsBWaJqNi8YF99ItJEr8AFvSg_gpxLwCF_nIPclSaVlq5FKxEFDkRZJmfJVLy-JNS5Mj
EU5aMUgoHgorQXKEGtirNc9TtSFh2Rb-UU5D1186F3oLdm46nyC2wqGEMeHSf9EyajKuO/
http%3A%2F%2Flists.opensource.org%2Fmailman%2Flistinfo%2Flicense-revie
w_lists.opensource.org
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">-------------- next part --------------
An HTML attachment was scrubbed...
URL: <a class="moz-txt-link-rfc2396E" href="http://secure-web.cisco.com/1fPUeR6uAX1RxU591ksj7ojUgo4lI2OcbGgIJKe-jadiF3QlJCMPLpqt93Nc5k9XAr0Ms4o3klaIKodt0I4YcGkIw6hSIPGwYuPk6kJY-JYDO9ewMNwURfHjOf7rcxcnNUtqxnrXhSw5eaQw01YcfiHaE0WEmkYbqNooGc0SECfTUjrkPRLk3I8pB3VRrVVyIZwY11R_-9K4F8aSba74vnAqc6IbEK1lSY1YP_YtpWJ7ENB3adLcuh-z63GyF1a4hhFu7rYHrNAqOY03JKsCpjY_L_353v1v5-vB0DwMZoeJq0nUtXZMGvV1zTDxRjY6K/http%3A%2F%2Flists.opensource.org%2Fpipermail%2Flicense-review_lists.opensource.org%2Fattachments%2F20250210%2F23cce25b%2Fattachment.htm"><http://secure-web.cisco.com/1fPUeR6uAX1RxU591ksj7ojUgo4lI2OcbGgIJKe-jadiF3QlJCMPLpqt93Nc5k9XAr0Ms4o3klaIKodt0I4YcGkIw6hSIPGwYuPk6kJY-JYDO9ewMNwURfHjOf7rcxcnNUtqxnrXhSw5eaQw01YcfiHaE0WEmkYbqNooGc0SECfTUjrkPRLk3I8pB3VRrVVyIZwY11R_-9K4F8aSba74vnAqc6IbEK1lSY1YP_YtpWJ7ENB3adLcuh-z63GyF1a4hhFu7rYHrNAqOY03JKsCpjY_L_353v1v5-vB0DwMZoeJq0nUtXZMGvV1zTDxRjY6K/http%3A%2F%2Flists.opensource.org%2Fpipermail%2Flicense-review_lists.opensource.org%2Fattachments%2F20250210%2F23cce25b%2Fattachment.htm></a>
------------------------------
Subject: Digest Footer
_______________________________________________
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://secure-web.cisco.com/1V2dOu-nVMsk0pjiVv5kG9ZXUIX2u3oPaLAez08Ts-1vMWcvQFNXwTKGdTpbfwQZZDp7AomIhQfYBxDa8xXol6jqx6mbzJydJc7TdPdX2F_H5SRYhYvgyP_srhWfIWixRY0cSRo9kg5D-8RykfnvZiYQxRo3CHmmBUIA_z6GlAXiLvPRMbvx-fWxJsBWaJqNi8YF99ItJEr8AFvSg_gpxLwCF_nIPclSaVlq5FKxEFDkRZJmfJVLy-JNS5MjEU5aMUgoHgorQXKEGtirNc9TtSFh2Rb-UU5D1186F3oLdm46nyC2wqGEMeHSf9EyajKuO/http%3A%2F%2Flists.opensource.org%2Fmailman%2Flistinfo%2Flicense-review_lists.opensource.org">http://secure-web.cisco.com/1V2dOu-nVMsk0pjiVv5kG9ZXUIX2u3oPaLAez08Ts-1vMWcvQFNXwTKGdTpbfwQZZDp7AomIhQfYBxDa8xXol6jqx6mbzJydJc7TdPdX2F_H5SRYhYvgyP_srhWfIWixRY0cSRo9kg5D-8RykfnvZiYQxRo3CHmmBUIA_z6GlAXiLvPRMbvx-fWxJsBWaJqNi8YF99ItJEr8AFvSg_gpxLwCF_nIPclSaVlq5FKxEFDkRZJmfJVLy-JNS5MjEU5aMUgoHgorQXKEGtirNc9TtSFh2Rb-UU5D1186F3oLdm46nyC2wqGEMeHSf9EyajKuO/http%3A%2F%2Flists.opensource.org%2Fmailman%2Flistinfo%2Flicense-review_lists.opensource.org</a>
------------------------------
End of License-review Digest, Vol 137, Issue 7
**********************************************
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 class="moz-txt-link-freetext" href="https://www.massgeneralbrigham.org/complianceline">https://www.massgeneralbrigham.org/complianceline</a> <a class="moz-txt-link-rfc2396E" href="https://www.massgeneralbrigham.org/complianceline"><https://www.massgeneralbrigham.org/complianceline></a> .
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.
_______________________________________________
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>