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

[McCoy Smith]

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:
>
> 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 at chesteklegal
> www.chesteklegal.com
>
>
> On 2/4/2025 3:51 PM, Barksdale, Marvin 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 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
>>
>> mbarksdale at mgb.org
>>
>> *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 
>> 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
>
> _______________________________________________
> 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/20250210/23cce25b/attachment-0001.htm>