[License-review] 2nd resubmission of the new “MGB 1.0” license
Pamela Chestek
pamela at chesteklegal.com
Mon Mar 3 21:45:44 UTC 2025
Thanks! But I think Simon was talking about the email. It is certainly a
wall of text.
Pam
Pamela S. Chestek
Chestek Legal
PLEASE NOTE OUR NEW MAILING ADDRESS
4641 Post St.
Unit 4316
El Dorado Hills, CA 95762
+1 919-800-8033
pamela at chesteklegal.com
www.chesteklegal.com
On 3/3/2025 12:10 PM, McCoy Smith wrote:
>
> i did a libre office compare of the feb 2025 version vs the march 2025
> version (which is the current, I believe) see attached.
>
> On 3/3/2025 10:31 AM, Simon Phipps wrote:
>> 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 2^nd 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 <http://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
>>
>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20250303/a5b4496e/attachment-0001.htm>
More information about the License-review
mailing list