[License-review] 2nd resubmission of the new “MGB 1.0” license

[Simon Phipps]

Hi Marvin,

I for one would ve very grateful if you would concisely highlight what you
have changed here please.

Thanks

Simon
(in a personal capacity)

On Mon, Mar 3, 2025 at 6:28 PM Barksdale, Marvin <mbarksdale at mgb.org> wrote:

> *I Marvin Barksdale JD, the license steward and license submitter, attests
> that this 2nd resubmission of the 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, laboratories, and medical schools frequently
> collectively organized as systems, with a federally regulated mission to
> provide patient care, train healthcare professionals, and conduct
> innovative research.  As self-contained businesses, these complex
> organizations have evolved to perform several ancillary commercial
> functions including patent administration, licensing, co-development, all
> of which to support their central mission of the advancement of medicine.
> Aligned with this central mission is the proliferation of open science
> innovation at AMCs.   While AMCs have evolved their proprietary IP
> strategies, many of their research and clinical employees have shifted to
> open science collaborative approaches where research data, methodologies,
> source code and findings are licensed to be shared at no cost to catalyze
> innovation. Despite both approaches purporting to be operating in the
> benefit of AMC system goals, there has been a historical lack of alignment
> between open and proprietary licensing activity.    At Mass General
> Brigham, for example, despite receiving over $77M in NIH funding over the
> past 10 years for 200+ software research projects that should have yielded
> open-science results and commercial innovation, there is a large
> clandestine community of researchers, clinicians, developers, and other
> health care employees, who operate in the grey areas of open source, NIH,
> Open Access Journal, and AMC compliance.  The goal of MGB 1.0 is to bring
> open-source licensing into AMC licensing compliance, which mandates
> employees out-license AMC assets under express risk mitigation terms
> spanning several federal mandates and best practices including: HIPAA laws
> not to share “Protected Health Information” and other personal info,
> federal 501 c-3 anti-endorsement laws, and licensing software on an “As-Is”
> basis without implied warranties, representations, and damages. These terms
> are not explicitly outlined in similarly permissive licenses such as MIT
> and BSD, but all can align with fundamental principles of openness.
>
>
>
> Beyond bringing NIH funded researchers and health care innovators into an
> AMC compliant open-source licensing scheme, MGB 1.0 seeks to balance the
> modern AMCs mission driven commercialization activities with its scientific
> mission to break down barriers to knowledge access and collaboration within
> healthcare.  Although MGB 1.0 uses a similar pro-commercialization,
> pro-modification, highly compatible licensing scheme as Apache 2.0, MGB 1.0
> aims to limit to its express patent license to the software itself eg.
> claims embodied by the work, as well as to address the guidelines of the
> work’s inclusion of patient personal information.
>
>
>
> *Legal Analysis*
>
>
>
> Patent law’s broad definition of infringement and the courts broad
> interpretation of the Doctrine of Equivalence (DoE) sits at the center of
> MGB 1.0 patent grant approach.  35 USC 271 states that  “for a licensee to
> successfully assert that their contribution or derivative work is
> infringing on a patent, the licensee must show that they are making, using,
> selling, etc. some thing or process that is covered by the patent.”  Thus,
> via 35 USC 271,  showing infringement requires performing a comparison
> between “a patented invention’s claim” and “whatever it is that the
> defendant makes, uses, offers to sell, or sells.” According to the court in
> Bai v. L L Wings, Inc., "determining whether a patent claim has been
> infringed involves two steps: (1) claim construction to determine the scope
> of the claims, followed by (2) determination whether the properly construed
> claim encompasses the accused structure. The first step, claim
> construction, is a matter of law. . . . The second step, determination of
> infringement, whether literal or under the doctrine of equivalents , is a
> question of fact."
>
>
>
> Thus, while OSD 9 demands that the licensee must be free to use the
> licensed software free of any potential claim for infringement under any
> infringement theory,” Apache 2.0’s patent grant to infringing claims
> extends beyond the use of the licensed software, to granting patents to
> claims that may contain other “equivalent” non-licensed software.  This
> concept is consistent with, Winans v Denmead, where the courts found patent
> infringement reaching beyond literal infringement of patent claims either
> by way of a  “insubstantial differences” test or a ‘‘function-way-result”
> test,  both of which requiring a difficult factual assessment for the jury
> (or judge in a bench trial). Presenting even more uncertainty for potential
> infringers, courts have more recently found an additional way to prove
> equivalency by showing that the accused equivalent and the claimed patent
> feature were known “in the art” to be used interchangeably. Hilton Davis v
> Warner-Jenkinson.  MGB 1.0 maintains the licensee’s ability to use the
> licensed software free of infringement under even a DoE infringement
> theory, but ensures the patent grant is narrowed to the software only;
> without putting burden on contributors to decipher difficult questions of
> fact to figure out the extent of the patent grant beyond literal
> infringement of the software.
>
> MGB 1.0’s approach in narrowing the scope of the grant to the software
> itself eg the use of “embodied” over “infringed”, is similar to the patent
> grant mechanism utilized by the osi approved AFL and the GNU v3 license,
> which narrows the claims granted only to “essential patent claims,”  not
> including “claims that would be infringed only as a consequence of further
> modification of the contributor version.”   Similarly these licenses intend
> to narrow their patent grants to claims that are essential to open source
> distribution of the licensed copyrighted IP, and not to claims that aren’t
> embodied by the copyrighted IP or that would be infringed only as a
> consequence of further modification of the contributor version.
>
>
>
> Accordingly, an example where the Apache 2.0 license can be utilized to
> obtain a patent license beyond what is embodied a claim, would be via MGB
> filing a patent with multiple claims; where open source code is embodied in
> one claim [A] , and closed source software is embodied in another [B].
> Under Apache 2.0, this patent filing scheme creates an opportunity for
> contributors to intentionally infringe on claim [B] (which includes
> separate non open source code),  by contributing code that infringes on [B]
> through DoE. Although this is accepted DoE infringement via us patent case
> law, infringing on other claims that include separate non open source code
> is beyond what is necessary for a licensee to freely use the open source
> licensed software itself.  This intent to “contract around" infringement
> overreach (eg beyond the software itself), to narrowly confine open source
> license patent grants to the licensed software itself, is observable across
> several osi licenses including the aforementioned AFL and BNU v3.
>
>
>
> 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.
>
>
> *Summary*
>
>
>
> MGB 1.0 provides express licensing risk provisions required by AMC Tech
> Transfer and General Counsel Offices while protecting AMC commercial
> activity as a patent portfolio holder and as an ongoing code contributor
> via AMC resources.   To these ends MGB 1.0 utilizes a more direct risk
> mitigation approach than the MIT or BSD licenses. Furthermore, although MGB
> 1.0 uses a similar approach to Apache 2.0, MGB 1.0 narrowly confines the
> express license grant to the software itself or patent claims owned or
> controlled by the Contributor that are embodied in the shared work. Beyond
> the patent grant, MGB 1.0 also adds HIPAA risk mitigation language that is
> imperative as osi has defined open source ai as including the shared data
> by which it was trained. This language is imperative for AMC’s and their
> open source ai innovators potentially sharing patient data with licensees
> unfamiliar with HIPAA obligations.
>
>
>
> *__________________*
>
> Marvin Barksdale
>
>
>
> 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
> https://www.massgeneralbrigham.org/complianceline .
>
> 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
> License-review at lists.opensource.org
>
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>


-- 
*Simon Phipps*
*Office:* +1 (415) 683-7660 *or* +44 (238) 098 7027
*Signal/Telegram/Mobile*:  +44 774 776 2816
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20250303/52609411/attachment-0001.htm>