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

[Barksdale, Marvin]

Thanks all for the early review.
Agreed, there are several formatting issues that may have been caused by exporting to plain text that have corrupted the submitted version, including added and missing characters.  Although I am withdrawing this submission, in anticipation of further review I would like to like flag the areas where we are in alignment and hopefully clarify the areas where we are not:


  1.
 Regarding the questions around intent behind MGB 1.0's disclaimer of obligations : "For clarity, no patent license is granted by a Contributor for infringements caused by: (i) your or any other party's Derivative Works, or (ii) the combination of the Work with anything other than the Contributor Version."

Although we originally intended to add clarity to the initial grant through utilizing an approach approved by the OSI in other licenses such as MPL 2.0, I agree with the findings that this language became contradictory in its adoption to the MGB 1.0 use-case.  I believe striking this clarifying clause and integrating Contributor Version in the Contribution definition does not interfere with MGB 1.0's core approach.

  2.   Regarding MGB 1.0's Patent Grant : "Subject to the terms and conditions of this License, each Contributor hereby grants to You a (perpetual*), worldwide, non-exclusive, sublicensable, no-charge, royalty-free, irrevocable (except as stated in this section) patent license, under any patent claims owned or controlled by the Contributor, to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work and Derivative Works, but only to the extent such patent claims claim inventions embodied in [their Contribution(s)]."

The MGB 1.0 patent grant's intent is to grant rights under patent claims controlled by Contributor to the Work and Derivative Works to the extent such claims claim inventions embodied in their Contribution (in the form it exists immediately after the Contributor submits it.) Compared to the Apache 2.0 Patent Grant to "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."

Apache 2.0’s grant of all licensable patent claims that are necessarily infringed by the contribution or by combination of their contribution with the original work opens the door to downstream infringement via later acquired contributor-controlled claims.  The effect here is similar to elements the GPL 3.0 license, which includes a grant to the contributor's essential patent claims:  all patent claims owned or controlled by the contributor, whether already acquired or hereafter acquired, that would be infringed by some manner, permitted by this License, of making, using, or selling its contributor version, but do not include claims that would be infringed only as a consequence of further modification of the contributor version.

The intent of MGB 1.0 is for the contributor to grant the patent claims necessary to use the contributed software, not to, for example, infringing claims later acquired as a consequence of further modification (e.g. new infringement and the entire portfolio exposure referenced by Lawrence Rosen in “Open Source Licensing – Software Freedom and Intellectual Property Law"). Thus this goal is accomplished even after removing the disclaimer of combination language (see: 1. above) causing several issues.

  3.
Regarding MGB's  additional attribution requirement, the thought is the Apache requirement that "You must cause any modified files to carry prominent notices stating that You changed the files" does not carry specificity that is beneficial to AMCs who are looking to assess the impact of the Work across digital repositories via various search methodologies.  Beyond Apache not specifying the where or how the notice must be made (simply in the "file"), MGB 1.0 intends to require Licensor attribution for whichever aspect of the Work was redistributed e.g. algorithmic code via Github or the model / dataset via HuggingFace.  Via Apache 2.0 attribution is only required in Source code form or via the  Notice file, both of which fall outside of queryable data via repository api.

  4.
The clinical researchers we support have strongly disagreed with the premise that license language clarifying the applicability and relevance of data / privacy policy to downstream users is not valuable. Furthermore I do not see a clean parallel to the sunsetted Intel license.  The Intel language went as far as stating that under "current" US law the subject software would be export eligible, except for a specific list of countries.  For a number of reasons such as the proliferation of HIPAA consent forms, as well as the misconceptions about open source ai, many patients, researchers, and developers mistakenly believe data and privacy responsibilities can be contracted around or do not apply.  The Model Openness Framework, for example,  states that Class I - Open Science spans the release of all data and Model Materials, without explicit reference to these factors.  The proposed MGB 1.0 will not mention any statues by name but will reinforce a critically relevant and misunderstood data responsibility concept: open science, open data, and open source does not allow you to contract around data law and policy obligations.

Again apologies for any confusion surrounding the need to rescind this request.

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 <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. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20250924/94d414f1/attachment.htm>