[License-review] 2nd resubmission of the new MGB 1.0 license
Pamela Chestek
pamela at chesteklegal.com
Thu Mar 20 07:13:24 UTC 2025
I had previously only looked at the patent clause and data clause. I
have now read the license in full and have the following comments:
Definition, "License": "as defined by Sections 1 through 13 of this
document." There are only 12 sections in the license.
Section 2, "Grant of License," and Section 3, "Patent License": You have
modified the Apache license by removing the word "copyright" and you
have added verbs that are in the Patent Act and not in the Copyright
Act, namely, "make, use, sell, import." This therefore appears to be a
grant of a patent license in Section 2. You then grant another patent
license, of different scope, in Section 3. The grant in Section 2 is
irrevocable but the grant in Section 3 can be revoked if there is a
patent claim.
Section 5(b): "In marketing your Derivative Work, You and Your
Sublicensee as applicable, shall acknowledge Licensor by conspicuously
marking any portion of the Work included with or integrated into
Derivative Work with the conspicuous following statement and
attribution, or conspicuously included a permanent link to such
statement: [list of personal names]." First, licenses cannot include
hard-coded names because the license is then not reusable. See
https://opensource.org/licenses/review-process ("The license must be
reusable, meaning that it can be used by any licensor without changing
the terms or having the terms achieve a different result for a different
licensor.") Second, "marketing" is defined as
<https://www.ama.org/the-definition-of-marketing-what-is-marketing/>
"the activity, set of institutions, and processes for creating,
communicating, delivering, and exchanging offerings that have value for
customers, clients, partners, and society at large." Marketing is public
activity, so imposing duties only where the software is being
"marketed," but not if there is no marketing activity for the software,
is very odd.
Section 7, No Additional Rights: This section is potentially problematic
because the license is intended for use with AI models. It is not yet
clear what type of rights scheme might apply to models and some theorize
<https://copyrightblog.kluweriplaw.com/2024/01/18/are-ai-models-weights-protected-databases/>
that models may be protected by database rights. By trying to reserve
some rights, it may be that your license would be construed as not
granting all the rights necessary to run, modify and distribute the Work.
Section 8, Disclaimer of Warranties: The statement "Licensor MAKES NO
WARRANTY OR REPRESENTATION ... (ii) ... THAT ANY Work OR
DOCUMENTATION[,] WILL NOT INFRINGE ANY PATENTS OR OTHER INTELLECTUAL
PROPERTY RIGHTS OF LICENSOR OR OF ANY THIRD PARTY," undermines the
patent grant. The Licensor HAS granted a license to its patents - so is
this saying that, despite the license, the use of the software might
still infringe that licensor's patent rights?
Section 9, No Trademark or Name License: You prohibit the use of
"anything confusingly similar ... to any Internet website or Universal
Resource Locator of Licensor." This is hugely burdensome, how is someone
supposed to know every URL of every contributor to the software, and
every website of every contributor, particularly when the software may
not include the names of all contributors?
Section 10, Limitation of Liability: Typically open source licenses also
exclude direct liability, although you don't have to.
Section 11, Accepting Warranty or Additional Liability: "and only if
You agree to indemnify, defend, and hold each Contributor harmless
/*form */any liability ..." Should be "for" or "from." You have also
taken the language from the Apache license and tacked on similar
language that is redundant, "You agree to indemnify, defend, and hold
each Contributor harmless form any liability incurred by, or claims
asserted against, such Contributor ... Your indemnification obligations
under this License mean that You, at Your sole expense, shall indemnify,
defend and hold harmless all Contributors ...." This extended clause
also creates a lot of ambiguity. The Apache duty to indemnify only
arises when someone chooses to offer support, warranty, indemnity or
other liability and the duty is only for the offer of the warranty or
additional liability, not for any type of claim. However, the tacked-on
language is much broader and appears to require that a mere user of the
software indemnify the licensor, since it is invoked for "all liability,
damage ... loss or expense ... in connection with any third-party claims
...."
Section 12, Interpretation: It's somewhat odd to bother to say "You may
not assign or transfer this License" when anyone can become a direct
licensee by using the software.
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 3/13/2025 12:01 PM, Barksdale, Marvin wrote:
>
> For us, a decision based on accurately represented intent and the
> correct interpretation of the law is more important than a (possible)
> approval based misapplied facts. We’re trying to get to the best
> available license for our community and system, so if the osi decides
> to not approve what our attorneys believe is our best attempt at a
> compliant license that will be an unfortunate outcome we will have to
> accept.
>
> So if my continued assertions that the MGB 1.0 license does not allow
> a patent infringement claim against any user of the licensor's
> unmodified version of THE SOFTWARE under any theory, “talks me out of
> approval,” again I will have to accept that, as this is indeed the
> case. The infringement claims allowable under MGB 1.0 would be around
> DIFFERENT non open source SOFTWARE, that under Apache 2.0 could
> potentially be infringed on under DoE through a later contribution of
> code. Not only do other OSI approved licenses narrow the patent grant
> focus in a similar constructed way to MGB 1.0, the facts of the
> “opposing” case law do not match the facts as presented here as this
> narrowing of the subject of the grant is not an exhaustion of patent
> rights, as the licensor never had rights to the different software to
> be exhausted.
>
> I would hope license-review would review contents of the proposal, the
> license, and the replies instead of preforming their positions and
> making hasty conclusions about what can’t be done and what courts
> would never do, that could very well prejudice this process.
> Nowhere have we asserted that our intention or the legal effect
> achieved is not to grant all rights necessary, as the right to
> use/sell different software, even if this different software is part
> of the same patent in a different claim, is not a necessary open
> source right.
>
> *__________________*
>
> Marvin Barksdale, JD
>
> *From:*Pamela Chestek <pamela at chesteklegal.com>
> *Sent:* Thursday, March 13, 2025 1:56 PM
> *To:* License submissions for OSI review
> <license-review at lists.opensource.org>; Barksdale, Marvin
> <mbarksdale at mgb.org>
> *Subject:* Re: [License-review] 2nd resubmission of the new MGB 1.0
> license
>
> * External Email - Use Caution *
>
> You are talking yourself out of approval. What you are failing to
> understand is that we are trying to find a way to approve your
> license. License-review is not going to approve a license that allows
> a patent infringement claim against a user of the licensor's
> unmodified version of the software under any theory. McCoy suggested
> that perhaps the OSI could approve your license, despite your
> misunderstanding of patent law, based on a belief that your
> interpretation of the license language is not one a court would ever
> agree with and instead the court would interpret it as a grant of a
> license under all infringement theories.
>
> But when you insist that your intention is */not /*to grant all rights
> necessary, I am inclined to take you at your word, which means your
> license should not be approved.
>
> Pam (in my personal capacity)
>
> 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
> <http://secure-web.cisco.com/1rRzmGp0Z0lx0YB1ktCpw88ojwJsie9BDi5LBzA4t-WnWKyE2O00KtGgU8CwJrT32e-ybaxX7xGOSAq6VaX5osa2hBnJncNLjaWFZ8p5d6q_NL8GCY_g2OugH8zoYOQcxcGXxDfAbtm1igZ8SkV81IgA_4tmKdWKRhERy_-FeVVg_liVKf5MYjWUtTvORAC8ivRl9_lcGJVd06l3xhzj64QzJi3C3doOxN4Drp0MQyBPfN0ppJraHGA6umEYbZpeyyO_QW15EAptR_Mq-q3q8debtV2sOD30koJLiqknqWpQiLY4XdgRyLw8Dj-lCAOZE/http%3A%2F%2Fwww.chesteklegal.com>
>
> On 3/13/2025 2:25 AM, Barksdale, Marvin wrote:
>
> Responding to the previous two notes –
>
> 1. > What about making it more generic to PII laws in
> general? It's best to write licenses for posterity, and there's
> no way for us to predict what new data privacy laws may exist in
> the future.
>
> Although I understand the general desire to “write licenses for
> prosperity,” it appears the drafters of several popular osi
> licenses have similarly looked to strike a balance between
> evergreen language and utilizing critical statutory definitions
> which are relevant to industry standards in licensing. This
> practice has even extended as far as historical statutory
> definitions that are 20+ years old, deemed relevant to the
> practices and standards of the time:
>
> *OSET Public License version 2.1 (2015): “*The Covered Software is
> a “commercial item,” as that term is defined in 48**C.F.R. 2.101
> (/Oct. 1995/), consisting of “commercial computer software” and
> “commercial computer software documentation,” as such terms are
> used in 48 C.F.R. 12.212 (/Sept. 1995). /Consistent with 48 C.F.R.
> 12.212 and 48 C.F.R. 227.7202-1 through 227.7202-4 (/June 1995/),
> all U.S. Government End Users acquire Covered Software with only
> those rights set forth herein.”
>
> *NASA Open Source Agreement v1.3*: (2004)**“Modification means any
> alteration of, including addition to or deletion from, the
> substance or structure of either the Original Software or Subject
> Software, and includes derivative works, as that term is defined
> in the Copyright Statute, 17 USC 101.”
>
> *Common Development and Distribution License 1.0 (2004): * The
> Covered Software is a commercial item, as that term is defined in
> 48 C.F.R. 2.101 (Oct. 1995), consisting of commercial computer
> software (as that term is defined at 48 C.F.R.
> 252.227-7014(a)(1)) and commercial computer software
> documentation as such terms are used in 48 C.F.R. 12.212 (Sept.
> 1995).”
>
> In each of these licenses there was no way for the osi board to
> predict which new Federal Acquisition or IP laws may exist in the
> future, but a balance was made to define terms in a way that was
> relevant to the analysis at hand. Hopefully that can happen again
> with MGB 1.0
>
> 2. > I must say, although you say that [this] is your aim, the use
> of "embodied" over "infringed" doesn't do that.
>
> I’m not sure where the misunderstanding lies here but I question
> if there is true understanding of my aim if the analysis is again
> shifting to “contracting around patent exhaustion.” As I have
> stated, drafting language to alter licensees’ patent rights in
> the identified claim or licensed software is not the aim. Thus
> patent exhaustion and the facts of Quinta/LGE and Helferich do
> not align with my MGB 1.0 goals, or the goals of similar patent
> grant language of the GNU v3 license. Both the language used in
> MGB 1.0 and GNU v3 use different patent grant language than Apache
> 2.0, which individually narrows the subject invention (eg. what it
> applies to) of the patent grant, instead of altering patent rights
> to alter the use and sale of a given invention (Patent Exhaustion).
>
> Reviewing the Quinta/LGE fact pattern, in the License Agreement
> LGE authorized Intel to make and sell microprocessor products
> using the patented inventions, but also stated that no license was
> granted to any third party for combining licensed products with
> other products (for example, for combining Intel microprocessor
> products with other parts of a computer). Here LG’s first
> licensing step was to satisfactorily identify the licensed
> patented inventions, and then to use language to put controls on
> how the licensed patent rights could be used. In the both the MGB
> 1.0 and the Apache 2.0, as patents can extend beyond the face of
> the claim, the patent grants attempts to identify exactly what
> claims the grant applies to. If the licenses were to patented IP
> versus to copywritten software with an ancillary patent grant,
> this specification of application would be unnecessary. In Apache
> the drafters are clear, “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.” Similar to MGB 1.0, the Apache language is not
> attempting to alter how licensees can exercise their patent
> rights; they similarly are establishing what claims the grant of
> patent rights are applicable to. Thus, neither Apache 1.0 nor
> MGB 1.0 are violative of the patent exhaustion doctrine, and even
> though the Helferich license similarly uses the word embody, its
> license, like LGE’s, aimed to alter patent use, not narrow the
> subject of the grant itself. As the reach of patented inventions
> is beyond copyright’s “fixed in a tangible medium” standard,
> clarifying the subject of the patent grant in a software license
> is appropriate under law, while, in contrast, attempting to
> contract around how you can use the patent violates the doctrine
> of patent exhaustion.
>
> It was also offered that the Apache 2.0’s patent grant is “bounded
> by the copyright in the Work”. For reference, the Apache language
> is "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" (where "Contribution" means "any work of authorship,
> including the original version of the Work and any modifications
> or additions to that Work or Derivative Works thereof, that is
> intentionally submitted to Licensor for inclusion in the Work by
> the copyright owner or by an individual or Legal Entity authorized
> to submit on behalf of the copyright owner."). I do not agree
> with this “bounded to Copyrights in the Work” reading of Apache.
> The language states “such license applies only to THOSE PATENT
> CLAIMS licensable by such Contributor that are necessarily
> infringed by their Contribution(s) alone or by combination… with
> the Work….” Thus if the grant applies to Patent Claims that are
> infringed by Contributor copyrights (as Patent Claims can contain
> copyrightable code), the grant is not bounded to Work’s
> copyrights, as the grant applies to Patent Claims, not the
> Contribution / Work itself. In the Apache language, the function
> of “that are necessarily Infringed by their Contribution,” is to
> identify what particular Patent Claims the grant applies to. Thus
> if a separate PATENT CLAIM is necessarily infringed (via DOE for
> example) by a Contribution / combination of the Work +
> Contribution, under Apache 2.0, the grant would extend to the
> separate patent claim.
>
> Although I have maintained that DoE is at the center of MGB’s
> alternative strategy, I have Never said contracting around it is
> my goal. Apache’s choice to identify the patent claims its grant
> applies to via patent infringement has always been at issue for
> AMCs who manage a patent portfolio, as well as MGB and our 10,000
> researcher community. The goal is not to tell licensees what they
> can do with the software they are licensed, but to properly align
> the patent grant’s reach with the intended scope of open source
> distribution, the software itself.
>
> *__________________*
>
> 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://secure-web.cisco.com/1HFAITpcr8Oaz5lsoVAFAlUBVvCp0gCZyRnBZS5kxxex41GDhnU_MvMq8AF3ef-dJXWhtMsddJl3kH5rEUxWWeHON0UflRxlXmBs-QaqW5XgOMQw780kHUjfGLC0tiuTBYhNA_mcMjWuH-H9wbH2vyaZjVCnP-3a-hUubQ-Zvsu1AyEK1_6ge6NPqq9KZsW1qow31YoJgpXF8FjtoFB_ksvkzJtkk3z_WCRR7qENhelBQcwq8Uptn21LOOCwOJcFGOQSi9tzm1DXHnj3VBhXc9L9TGHwnUQSOlHz_W4MR0Qwx3Nbq9Gq8a3Ede1lHY4lj/https%3A%2F%2Fwww.massgeneralbrigham.org%2Fcomplianceline>
> .
>
> 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 <http://secure-web.cisco.com/1GxLaywKFoRrYYqxdrtCUPyi4qrmYqSCYu1trTE92hdtV3v6vJ9H-VGDiYfcQ4xDbC2MsA7qpbWgEUX1Spl7LzUP2FE8FCyZjO27gX77VPOxy1KvsffSQNgJM6Ax13g21OCvl1zRv6tPaxhJdmUdXTIixJU0A8GB75VGpiEVFsOc6pWniT_EXkyba9ERFneKLPiCesIJezVbGhiQh8rd0sHYXNLuqqClPDvu5k3Rq2LyiuZiaw5gaPiMJ680AivsdIaqAfxb7PLmXZJBkWrivfxiWHo__ILp5OHrV7RiHYRU9c-LPQ_tesDcjn7j3cpV6/http%3A%2F%2Flists.opensource.org%2Fmailman%2Flistinfo%2Flicense-review_lists.opensource.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 .
>
>
> 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/20250320/0fe9f7da/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 13266 bytes
Desc: not available
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20250320/0fe9f7da/attachment-0001.jpg>
More information about the License-review
mailing list