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

Mon Feb 24 08:59:16 UTC 2025

Hi, 

I don't believe Section 7 could withstand the scrutiny of OSD or OSAID and I am pretty sure this language does not belong in a license, but rather in the acceptance criteria for submission to a project. Same is for Section 6. They both should be scraped from the license. If you seek compliance for you project through a license, I suggest you to look in the direction of a CLA, instead of meddling with licensing and contractual terms as if they were interchangeable. 

I am fairly dubious as to 5.(b) as well, inasmuch as it extends the requirements to "promotional material". The rest seems ok. 

I am also very dubious as to Section 12, which imposes an indemnity based on the commercial exploitation of the material. It is quite obviously an expansion to Section 9 of the Apache 2.0 license. However, unlike the Apache, this license not only creates a new indemnity obligation -- with deep and twisty language -- but it puts Licensor in a different position than contributors, and this is discriminatory. The entire added part starts with 

> You agree to be responsible to Licensor and liable for the acts and omissions of
> Your sublicensees that constitute a breach of this License as if such acts or
> omissions were Your acts or omissions, and You shall be responsible for and
> indemnify Contributors for You and Your sublicensee’s compliance with this
> License.
Moreover, as it is evident from the above quote, the text implies that one licensee is liable for action of a sub-licensee's compliance with the license. Seriously? Even imposing a certain heightened burden of proof ("clear and convincing evidence") which I am pretty sure would be null and void under my own jurisdiction. 
Regardless the compliance with the definition, as a lawyer this is absolutely not a license I would advise my clients to even take into consideration. 

Cheers 

Carlo, in his own capacity. 

PS: please use "Open Source", not "open-source". 

> Da: "Barksdale, Marvin" <mbarksdale at mgb.org>
> A: "license-review at lists.opensource.org" <license-review at lists.opensource.org>
> Inviato: Venerdì, 21 febbraio 2025 18:42:04
> Oggetto: [License-review] Request for approval of the resubmitted new "MGB 1.0"
> license

> MGB License 1.0 – OSI Formal Proposal for RESUBMITTED New License Review

> I Marvin Barksdale JD, the license steward and license submitter, attests that
> this new resubmitted 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 resubmitted 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) and
> integrated hospital systems receiving federal grant funding, such as Mass
> General Brigham Incorporated (MGB).

> The goal of MGB 1.0 is to bring open-source licensing into AMC licensing
> compliance, which mandates that employees out-license AMC assets under express
> risk mitigation terms spanning several federal laws and hospital system best
> practices including: HIPAA laws regarding “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 IP 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 utilizes a more narrow
> patent grant to those claims “embodied” by the work, rather than Apache 2.0’s
> grant to those claims infringed by the work. The Apache 2.0 license has long
> been prohibited by Mass General Brigham and other AMCs it opens the door to a
> license to all claims infringed by a contribution to the work, even beyond
> those elements embodied literally by the claim. 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.

> Legal Analysis

> US Patent law’s broad standard of infringement and the courts’ interpretation of
> the Doctrine of Equivalence sits at the center of MGBs divergence in patent
> grant approach from Apache 2.0. 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 (1) (a patented
> invention’s claim) and (2) (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 (“DoE”), 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 through DoE either by way of an ‘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 around infringement, 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’s position is that open
> source distribution should not rely on licensors, licensees, or contributors to
> decipher matters of law to understand if they have the patent rights promised
> through them through the open source definition.

> Accordingly, an example where the Apache 2.0 license can be utilized for a
> patent license beyond what is in embodied a claim would be via MGB filing a
> patent with multiple claims; where open source code is embodied in one claim,
> and closed source software is embodied in another. Under Apache 2.0, this
> patent filing scheme creates an opportunity for Contributors to intentionally
> infringe on the proprietary claim by contributing code that infringes on the
> claim where proprietary code is embodied through DoE.

> The Apache patent clause is:"[E]ach Contributor [patent owner] hereby grants to
> You [the licensee] a perpetual, worldwide, non-exclusive, no-charge,
> royalty-free, irrevocable (except as stated in this section) patent license to
> make, have made, use, offer to sell, sell, import, and otherwise transfer the
> Work where such license applies only to those patent claims licensable by such
> Contributor that are necessarily infringed by their Contribution(s) alone or by
> combination of their Contribution(s) with the Work to which such
> Contribution(s) was submitted."

> In the Apache 2.0 licensing scheme, because the patent grant to the work is
> extended to apply “to patent claims infringed by the combination of a
> contribution with the work,” if the combination infringes on both claims
> through one of the tests of equivalence, the contributor may gain rights to the
> entire patent, including the proprietary claim. As these tests of equivalence
> are “difficult evaluations of law”, MGB 1.0 removes this infringement analysis
> from its patent grant in favor of a grant to “patent claims embodied by the
> work” similar to the patent grant utilized in the Academic Free License 3.0.

> 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 by Mass General
> Brigham’s Office of General Counsel’s IP Group.

> 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 to the MIT or BSD licenses, and although it uses a similar
> compatibility and license modification approach to Apache 2.0, MGB 1.0 more
> narrowly confines the express license grant. Despite this narrowed approach
> where MGB 1.0 does not grant contributors the rights to those patent claims
> that are not embodied by the software, MGB 1.0 bestows those patent rights
> necessary to fully utilize the open source work, without having to approach the
> authors to receive a separate patent license in accordance with 0SD 7.

> __________________

> Marvin Barksdale, JD

> Associate Director, Business Development and Digital Health, Innovation

> Mass General Brigham

> 399 Revolution Drive, Suite 955, Somerville, MA 02145

> Cell 347.217.8247

> Innovation.partners.org

> 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
> 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/20250224/a4094c13/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 31149 bytes
Desc: image001.png
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20250224/a4094c13/attachment-0001.png>