[License-review] Request for approval of new "MGB 1.0" license

[Carlo Piana]

> Da: "Pamela Chestek" <pamela at chesteklegal.com>
> A: "license-review at lists.opensource.org" <license-review at lists.opensource.org>
> Inviato: Sabato, 20 settembre 2025 2:41:33
> Oggetto: Re: [License-review] Request for approval of new "MGB 1.0" license

> I believe this license is still problematic for several reasons.

> Section 2(B), patent grant (why is B uppercase here, but lowercase in Section
> 3?)

>> For clarity, no patent license is granted by a Contributor for infringements
>> caused by:

>> (i) your or any other party's Derivative Works, ...

> This language withholds the patent license the moment a change is made to the
> software, whether it has anything to do with the patented function or not. In
> other words, no one who makes any change downstream has a patent license. This
> is unacceptable for an open source license.

>> (ii) the combination of the Work with anything other than the Contributor
>> Version.
> I can't parse this language, because I don't think you mean "Work" as it is
> defined in the license. As you've defined it, the "Contributor Version" is the
> "Work," so how can there be a combination of these two things? I assume what
> you're trying to get at is the concept of combining your Contributor Version
> with some other software, but I don't think that's what it says. However, my
> understanding of what you're trying to say is problematic too, because, like
> above, you are withholding the patent license even though the combination may
> not create a new infringement. New infringement is the only kind of patent
> claims that can be excluded in an open source license.
I also have similar remarks. As I read this license, the patent grant only goes to the contributed version in the identical as made by the patent holder ("in the form it exists immediately after the Contributor makes its [should it be "their"?] contribution"). If anyone makes a derivative, the license expires. 

This is not only problematic, this is would create space for a potential patent ambush. The grant is insufficient to permit derivative works in case of contributions made by patent holders of the contributed invention, which is the exact opposite of what I understand was the aim of the drafters of the Apache license. 

This alone would disqualify the license, IMO. 

> Section 3(d), new attribution requirement

> The newly added 3(d) is problematic. First, it's unclear. The requirement is to
> "conspicuously mark[] any portion of the Work ..." Mark it where? In the source
> code? In the marketing materials? In the documentation? It is also atypical, in
> that it appears to require a user to add new information that is not already
> contained in the software. Your license (and the Apache license) state that
> copyright notices have to be retained, so why isn't it sufficient for you to
> include the copyright notice you desire, which then others cannot remove? Why
> are you putting an affirmative burden on a user to figure it out? What problem
> are you trying to solve with this?
This is the same remark I wanted to make, thank you for stating it clearly. 

> Section 4, Personal Information

> It's questionably written and I believe unnecessary. It has the wording of a
> limit on the license grant, "The Work may include data, graphs, and Models, and
> if so, You may use and modify such data, graphs, and Models, provided that ..."
> "Provided that" is typically interpreted as a condition on the previous
> permission. However, what follows isn't a condition, just a statement of fact,
> "You may have obligations to comply with laws concerning privacy or protected
> health information ...." But are you trying to condition the license grant on
> compliance with the privacy laws? If you are, that would be a violation of
> OSD6.
Yes, probably this was meant as a caveat ("you MAY have"), but it reads as a condition ("provided that") and this is impermissible. 

> The section is also problematic because it cites US law. Open source licenses
> are ideally for an international audience. The waiver of warranty is redundant
> to Section 8. I would weigh whether it really is necessary to tell people what
> they should already know, which is that they have to abide by the law, and
> consider taking the entire paragraph out.
Again, I echo the same concerns. 

Cheers 

Carlo 

> Pam

> Pamela S. Chestek
> Chestek Legal
> 4641 Post St.
> Unit 4316
> El Dorado Hills, CA 95762
> +1 919-800-8033
> pamela at chesteklegal
> [ http://www.chesteklegal.com/ | www.chesteklegal.com ]

> On 9/19/2025 9:03 AM, Barksdale, Marvin via License-review wrote:

>> 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 license
>> that was created to catalyze open source distribution and open science among
>> the health care innovator and research development community, particularly
>> those employed at Academic Medical Centers (AMCs) receiving federal grant
>> funding, such as Mass General Brigham Incorporated (MGB). AMCs are collectively
>> organized hospitals and laboratories that are integrated with a medical school,
>> featuring a federally regulated mission to provide patient care, train
>> healthcare professionals, and conduct innovative research. In recent years
>> these complex organizations have evolved to perform several ancillary
>> commercial functions including IP co-development, administration, and
>> out-licensing, all of which aimed to support their central mission of the
>> advancement of medicine. Aligned with this central mission is the proliferation
>> of open science activity at AMCs, in that many of their researchers and
>> developers have shifted to open collaborative approaches where research data,
>> methodologies, source code and findings are shared at no cost to spur
>> innovation. But, despite the alignment with system goals, AMCs have been slow
>> to adopt open source best practices. At Mass General Brigham, for example,
>> despite receiving over $77M in NIH funding over the past 10 years to support
>> 200+ software research projects in yielding fruitful open source communities
>> and innovations, instead there is a large silo of health care researchers,
>> clinicians, and developers who operate in the grey areas of open source, NIH,
>> Open Access Journal, and MGB compliance.
>> The goal of MGB 1.0 is to provide developers who are building innovative
>> technology within highly regulated health care environments with a permissive
>> open source license that incorporates the best practices of digital health
>> licensing, enabling compliant open source collaboration both across and
>> external to AMCs.
>> Beyond addressing the open data, open source, and open access approaches of
>> digital health researchers and software developers, MGB 1.0 also looks to
>> support the rise of open AI model development that often utilizes sensitive
>> health data for training purposes. Thus, although MGB 1.0 uses a similar
>> licensing approach as Apache 2.0, it expands its applicability to AI models and
>> other shared works and derivatives spanning “model architecture, code, data
>> descriptions, data, and the model weights.” This expanded scope is important
>> because there are few open source licenses in current use that are suitable for
>> releasing AI models and their related artifacts.
>> Through internal cross-functional approval MGB 1.0 is now the default open
>> source license for emerging MGB research and innovations involving open
>> science, and for over 500 active GitHub repositories authored and / or
>> controlled by MGB clinicians, researchers, labs, and developers. The MGB Open
>> Science Program Office manages the MGB IP Policy pertaining to open source
>> licensing and drives compliance through the promotion of open science best
>> practices.
>> Legal Analysis
>> Although MGB 1.0 uses a pro-commercialization, pro-modification, highly
>> compatible licensing scheme similar to Apache 2.0, it is critically different
>> in three ways: clarified patent terms, coverage of AI artifacts, and clarified
>> interaction with data regulation. Licensors of open source software have long
>> struggled with the ambiguities of the patent license grant in Apache 2.0. In
>> this license each Contributor grants a no-charge patent license to the Work,
>> applying to “patent claims that are necessarily infringed by their
>> Contribution(s) or by the combination of their Contribution to the Work.” As
>> evidenced by the AFL, and later, the GNU v3 licenses, all approved by OSI,
>> there has been a shift in OSI license patent grants to language that “applies
>> only to specific set of patent claims…that are embodied in the in the Original
>> Work as furnished by the Licensor. [They are] not license[s] to the Licensor’s
>> entire patent portfolio.“ [Lawrence Rosen “Open Source Licensing – Software
>> Freedom and Intellectual Property Law” p 189].
>> As Apache 2.0’s patent grant features a broad patent grant application extending
>> to those claims infringed by the combination of the original Work and a
>> Contribution, MGB 1.0 builds on Rosen’s focused approach: “claims embodied by
>> the original work,” to explicitly apply to patent claims claiming inventions
>> embodied in contribution. The license also leverages clarifying patent language
>> from Section 2.3 of the Mozilla Public License version 2.0 also approved by
>> OSI.
>> MGB 1.0 was co drafted by myself, Marvin Barksdale JD, Preston Regehr Esq. of
>> Tech Law Ventures PLLC, and Heather Meeker Esq. of Tech Law Partners LLP 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 provisions that are best practice in digital
>> health, while explicitly preserving opportunities for commercial activity by
>> licensors who are patent portfolio holders and innovators. To these ends, MGB
>> 1.0 utilizes a clearer approach than the MIT, BSD and Apache 2.0 licenses.
>> Furthermore, MGB 1.0, explicitly contemplates the inclusion of AI model
>> artifacts in the licensed work. Beyond the clarified patent grant, MGB 1.0 also
>> adds HIPAA acknowledgement language that will provide AMC’s and other open
>> source innovators sharing models trained on health data comfort that they can
>> release materials under this license and still comply with law in a heavily
>> regulated field. MGB 1.0 provides developers who are building innovative
>> software within highly regulated health care environments with a permissive
>> open source license that incorporates the best practices of digital health
>> licensing, catalyzing compliant open source collaboration.

>> 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 |
>> 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 [ mailto:License-review at lists.opensource.org |
>> License-review at lists.opensource.org ] [
>> http://lists.opensource.org/mailman/listinfo/license-review_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/20250922/9e8b3718/attachment-0001.htm>