[License-discuss] License-discuss Digest, Vol 142, Issue 3
Barksdale, Marvin
mbarksdale at mgb.org
Mon Nov 25 09:20:12 UTC 2024
Thanks for all your thoughts here. Certainly several edits to make, but there is a bit of historical background and legal doctrine that support the need for an Open Source License that differs from the Apache 2.0's express patent license that I'm happy to continue to expound on.
The Office of the General Counsel of Mass General Brigham (and other Academic Medical Centers) have enacted prohibition on the utilization of the Apache License for well over 10 years due to potential patent license overreach. MGB, for example, as the largest procurer of NIH research funding, secured $77 Million Dollars of Open Source Software development grants (e.g. the NIH mandate for funding research results to be shared in a free an open format, via an osi approved license by default) over the past decade; and unfortunately none of these projects had permission to utilize the Apache 2.0 license. The Apache license by granting an express patent license not only to the patents necessary to use the intended open source Work, but to the patent claims that are infringed, in fact, has empowered patent trolls to make claims to related patents not contemplated by the original licensor. These trolls rely on a number of different legal doctrines (to claim access to patent rights) where the courts have expanded infringement beyond what a lay person would define as necessary to use. This expansion creates Apache 2.0 use cases where trolls can expand the license beyond the patents necessary to use the open source code, to infringement on patents based-on broadly constructed claims, the Doctrine of Equivalents, the Doctrine of Reasonable Interchangeability, and other rationale by which courts have expanded the customary limits of patent infringement beyond what's "necessary to use". Thus, instead of prohibiting Open Source research in areas that may overlap existing MGB patents due to (for example) the Doctrine Of Equivalents (which allows courts to find patents liable for infringement even if the product or process doesn't match the patent claim), MGB simply chose to prohibit use of the Apache license which made infringement the standard. Stated plainly the infringement standard and subsequent prohibition of Apache has caused patent trolling and the prohibition of Apache licensing methodology at MGB that I feel is unnecessary and that can be addressed by a new license, for the good of innovation. Although as a lay person, one may not care about whether the patent license triggers on "infringes on" or "necessary to use," this is a critical distinction to a patent troll and a rightful patent portfolio owner, that does not affect the Open Software Freedoms of related Open Source projects.
Utilizing a bit of Pamela's commentary, although a nonexclusive license is essentially an agreement not to sue for infringement, patent infringement itself requires factual and legal analysis, which can expand infringement beyond what is necessary to use a given code. Thus because licensees have the ability via their burden to prove infringement (which can stretch beyond what is necessary for use) the scopes of the MGB and Apache 2.0 license are indeed different. Eg. although all necessary uses of a source code should only infringe on a specified patent, a source code can infringe on several patents - even where there's not literal infringement .
In practice, for a licensee to successfully assert that their contribution or derivative work is infringing 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 (3) (a patented invention) and (2) (whatever it is that the defendant makes, uses, offers to sell, or sells). According to 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."
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 genAI algorithm [B] for 3d mapping that is released open source under Apache 2.0. Some time later another MGB Lab creates a patented process [C] to create a protein using a different genAI technique [d] to achieve the same goal, featuring similar data structure and harness but different mapping tech, but a broad patent claim with less limitations and no open source element. Here a Licensee troll can OS license work (B), and create a derivative work from it that is similar but not identical to patent (c) as to then claim Apache express license to patent [c], if the work they've made with open source "provides substantially the same function in substantially the same way to obtain the same result" to patent [c]. Because Academic Medical Center's frequently own overlapping patents in the same area with different IP strategy outlooks, Apache's approach of triggering a patent license off infringement can have unintended results, especially considering the doctrine of equivalents a test for infringement. Using the MGB License, as Patent C isn't necessary to the use, sale, distribution of work B, C would be rightfully excluded from the patent license, in favor of A.
Re: the general notes on the other clauses:
1., Please note the broad "use" and "prepare Derivative Works" grants of the MGB license which not only are more permissive than Apache and inline with the approved BSD-3 license, but I agree with Pamela's note adding the patent terms of art to the grant.
2. The React license referenced contained an "Additional Grant" with broader than the termination criteria than several modern licenses (the Apache License 2.0, EPL, MPL 2.0, and GPLv3); the MGB license contains no such Additional Grant and an identical termination clause to Apache. In fact, the Apache termination language has the identical purpose as the MGB language in question: chilling patent trolling. I do not see how a legitimate downstream licenser will be chilled by language requiring their use of an implied patent license be necessary to the use of the open source code.
3. The advertising clause in 5(b) - "In marketing Your Derivative Work, You, and Your sublicensee as applicable, shall acknowledge Licensor by conspicuously marking any promotional materials and any portion of the Software included with or integrated into Derivative Work You sublicense with the conspicuous following statement and attribution....." aligns with Section 10. No Trademark or Name License, in that "the License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file." This also specifically aligns with an AMCs 501c3 prohibition on endorsement, while still allowing proper attribution, and preventing undue endorsement. The BSD4 clause is alternatively a blanket restriction: " Neither the name of the copyright holder nor the names the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission."
4. Upon review I agree with your unease and analysis re: the No Implied Rights clause given the implied patent grant. Counsel and I have reconsidered this clause and updated it below.
5. Protected health information (PHI) is a defined term for any information in the medical record or designated record set that can be used to identify an individual and that was created, used, or disclosed in the course of providing a health care service such as diagnosis, research, or treatment, but for sure will add this reference. Re: The Desert Island Test , I will also remove that custodial requirement.
6. Can we dig deeper into the note that " 'You have no license to any protected health information (PHI), or other personal information collected by or included by Licensor, whether or not de-identified or aggregated' ..So parts of the software are not covered by the license and therefore non-free." PHI and personal info are never included in licensed software by an Academic Medical Center, whether paid or not paid. There are even restrictions on "selling" personal information even if we desired to. PHI and PI data can only be licensed via and IRB approved Data Use Agreement under strict research circumstances which are out of scope here. This is standard language, but technically when phi is de-identified it is no longer phi, the language is a catch-all as de-identification is an imperfect science. This protects the interest of licensor, while still enabling open source. Often models will be built via research under and irb, and as discussed during last weeks OSI seminar by Stafano, OSI is moving to a requirement that foundational data that can be shared, must be shared. As AMCs are prohibited from releasing PHI and PI as part of licenses, not releasing the data in the de-identified form may be counter to a presumed obligation release the foundational data that the model trained on.
7. By definition as the names in the notices would fall outside of the federal definition of PHI: ... created, used, or disclosed in the course of providing a health care service such as diagnosis, research, or treatment, but will add.
8. Will certainly remove the burden shifting language around PHI, but I don't agree with notion that removing PHI and PI from the software is a violation of open source principles. Software should be effectively shared, reproducible, and transparent but not to the detriment of personal privacy expectations. I'm not sure why both can be achieved.
9. "What does Section 4(d) do - how it is different from 4(c), other than to state it in the inverse?" (c) specifically pertains to Derivative works while (d) overlaps it expands to uses, sales, etc.
10. What is Section 5(d) meant to say and do? I interpolated this from the "Harvard Guidelines for Attribution of Credit and Disposition of Research Products" I see all these people as potential copyright owners as authorship is the copyright standard and this the Harvard standard for authorship. I am suggesting that those who don't contribute code, but conducted a scientific experiment, can be listed as authors of the work; as that is the Copyright Office 2023 commentary on generative ai IP: " [A] recent development is the use of sophisticated artificial intelligence ("AI") technologies capable of producing expressive material. These technologies "train" on vast quantities of preexisting human-authored works and use inferences from that training to generate new content. Some systems operate in response to a user's textual instruction, called a prompt.... A human may select or arrange Ai generated material in a sufficiently creative way that the resulting work as a whole constitutes an original work of authorship" Each of the elements of a research project listed is capable of contributing to code to illicit a certain degree of authorship in my opinion. Eager to hear more of your thoughts given this background; although this is not mission critical.
Again thanks all for the comments. This has been quite helpful and enlightening.
__________________
Marvin Barksdale
-----Original Message-----
From: License-discuss <license-discuss-bounces at lists.opensource.org> On Behalf Of license-discuss-request at lists.opensource.org
Sent: Sunday, November 24, 2024 2:09 PM
To: license-discuss at lists.opensource.org
Subject: License-discuss Digest, Vol 142, Issue 3
External Email - Use Caution
Send License-discuss mailing list submissions to
license-discuss at lists.opensource.org
To subscribe or unsubscribe via the World Wide Web, visit
http://secure-web.cisco.com/1Nb3EmLj-TUobVb7eKsYNMzxWpP64o1UXRdCMtORK9XHLo-pr12cVXIFTjdPcx7qnMD8zZL-n22ztQPZgLt7e-WSprmtAOxkRJZQgq7P3LxRPwTh27DlZVFTTL96fTCsnG7qV117cnA65aZJNExnl5-rxipVh0RW2l-ecoRFpfqmue2EVyiKqEf6mFn5Nc1h9o9mvn1RaT3tdFsK_O02ecNarcDtx9N4OTzEZjE0Zt7ouSIodsV6uiudAg20DPf6_h7f1QMrvwji2yeGTP_jQzJDySEAhXxrF6Hejq1VPeWLpYBR84C3mXMZY01afPb4ztxtyhIjT17B_L944PGNf8w/http%3A%2F%2Flists.opensource.org%2Fmailman%2Flistinfo%2Flicense-discuss_lists.opensource.org
or, via email, send a message with subject or body 'help' to
license-discuss-request at lists.opensource.org
You can reach the person managing the list at
license-discuss-owner at lists.opensource.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of License-discuss digest..."
Today's Topics:
1. Re: Protection of Academic Medical Center Patent Portfolio
via MGBopensource Proposed License (Pamela Chestek)
----------------------------------------------------------------------
Message: 1
Date: Sun, 24 Nov 2024 11:08:33 -0800
From: Pamela Chestek <pamela at chesteklegal.com>
To: license-discuss at lists.opensource.org
Subject: Re: [License-discuss] Protection of Academic Medical Center
Patent Portfolio via MGBopensource Proposed License
Message-ID: <a06c7faf-e60e-0517-f245-619f7ec8dcf3 at chesteklegal.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Comment below.
Pamela S. Chestek
(in my personal capacity)
Chestek Legal
4641 Post St.
Unit 4316
El Dorado Hills, CA 95762
+1 919-800-8033
pamela at chesteklegal
http://secure-web.cisco.com/1qlCpZRJhx_9NpDiVej1arQu121-ueRq4DbWVKhGOtLYKLKRbtY6HJKIPsI2SyAIXMvaRgLjBdTV8OJTEIcAf3YaGfz2kdeeNA0BdZjOYt5A-m0ZCmkhnhqgOuC50UuxXI7fjmrLnpIeZFBdJZvAfGaDzcW_U7kfLRFfERwsx-OoR101oKLtVxY_85a33IgJgmpyn8eRxvT0RBgi6Y2u50d_MeMgnwrRAJDp5VlvWZWhitk_Z9snoQBPVqWnbZHFnGomZ6Q2cD5MX0fEvHWSU8iLG8ovs1AM4anWoh4gff2O3zyxy5i0NjgrFCMeJpJSU/http%3A%2F%2Fwww.chesteklegal.com
On 11/21/2024 3:45 AM, Lukas Atkinson wrote:
>
> I fail to understand how this MGB license is supposed to be more
> patent-friendly than Apache-2.0. I'm not a legal professional, but
> licenses would ideally be both legally sound /and/ comprehensible by
> lay people.
>
> The relevant clauses of Apache-2.0 are:
>
> each Contributor hereby grants to You a ? 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.
>
>
> The corresponding parts of this MGB license:
>
> each Contributor hereby grants to You a ? license to use,
> reproduce, prepare Derivative Works of, publicly display, publicly
> perform, sublicense, and to distribute the Work, and Derivative
> Works ?
> This License does not include any express or implied license to
> any [patent] that is not necessary to exploit the rights granted
> in Section 2.
>
>
> You explain as the rationale:
>
> The thought is, if its necessary to exploit the patent rights to
> use the licensed works, Licensees possess the rights, ?but this is
> a more appropriate standard than ?if it infringes on a patent, you
> have rights to that patent.?
>
>
> But these two approaches largely seem to end up with the exact same
> rights being licensed.
>
> * Apache: for those patents that are necessary for this Contribution,
> Contributor grants a patent license to use.
> * MGB: Contributor grants a right to use, including any implied patent
> licenses necessary for that use.
>
> It seems that the word "infringed" in the Apache license is causing
> some unease, but both approaches seem to license the same rights:
> those patents that would be infringed by use of the contribution, were
> it not for this license.*What would be an example scenario where there
> is a difference*, where the Apache-2.0 would grant a patent license
> beyond what is necessary to use the Work?
I second this comment. "A nonexclusive patent license is simply a promise not to sue for infringement." /U.S. Philips Corp. v. Int'l Trade Comm'n/, 424 F.3d 1179, 1189. Procedurally, if one is accused of infringement, the accused has an affirmative defense than their infringement is excused by permission given by the rights holder.
/Carborundum Co. v. Molten Metal Equip. Innovations, Inc./, 72 F.3d 872,
878 ("As the alleged infringer, MMEI had the burden of establishing the existence of an implied license as an affirmative defense.") So a nonexclusive license is only a description of what the licensor will allow others to do that would otherwise infringe the patent, with the burden on the licensee to prove the existence and scope of the license.
The Apache license grants a license to patent claims that are "necessarily infringed" and the MGB license grants a license to whatever is "necessary to exploit" the patent claim. Apache defines the grant by referring to the result (necessarily infringed) and the MGB license describes it in forward-looking terms (necessary to exploit). But I don't see any legal difference between the two, since, no matter how it's phrased, the scope is the same - the extent of the infringement the licensor will tolerate. So I also would like to see an example where the scope of the grant between Apache and MGB is different.
>
> Another difference is the absence of an explicit license to "sell" or
> "import" the Work. If this is an Open Source license then those would
> be allowed, so for the avoidance of doubt it could be worth keeping
> those two verbs.
Indeed, by taking the word "Copyright" out of Section 2 but not otherwise amending it to add the patent terms of art you may have failed to grant a license to sell and import.
<snip>
> * I feel uneasy about the combination of the somewhat implicit patent
> license in sections 2+3 in connection with section 8 "no implied
> rights". Someone might interpret this as explicitly withholding any
> patent license, in which case the license would fail to provide
> Software Freedom.
I agree these are directly contradictory.
>
> * I understand the intention of section 7 "personal information", but
> find it confusing. Some data is said to be part of the Work, but then
> gets a separate usage license. It uses the term "protected health
> information" without defining it. The definition of "personal
> information" would seem to include some attribution notices per
> section 5, then requiring their removal. Section 7 also includes a
> requirement to "inform Licensor", which might go against the
> traditional "desert island test" for Software Freedom.
I think Section 7 makes the license non-free. In particular:
> The Work may include data, graphs, and models, and if so You may use
> and modify the data, graphs, andmodels.
>
That's fine, albeit perhaps unnecessary to state.
>
> However, You have no license to any protected health information
> (PHI), or other personal information collected by or included by
> Licensor, whether or not de-identified or aggregated.
>
So parts of the software are not covered by the license and therefore non-free.
>
> Licensor has no obligation under this License to provide any such
> personal information, or to validate any data generated by the use of
> the Work.
>
For what it's worth this is fine, but it's unnecessary. What else in the license would suggest that there /is/ a duty to provide it? I suppose you could have non-functional software if it's been removed? But I don't think there is any duty to provide /working /software under an open source license.
>
> For purposes of this License ?personal information? means any
> information relating to an identified or identifiable natural person,
> including PHI.
>
This statement probably belongs in the definitions, since you have followed the convention of having a section of definitions. And it's quite unrefined as a definition, reading more as an afterthought. As Lukas pointed out, this includes the authors names in notices.
>
> Licensor has attempted to delete all copies of such personal
> information in the data, and will undertake to ensure that the Work
> does not contain any data with personal information. If despite
> Licensor?s efforts in this regard, You identify any personal
> information in the data, You agree not to use such personal
> information and to promptly delete all copies of such personal
> information in Your possession, use or control, and to inform Licensor
> promptly of the foregoing so that it can remove such personal data
> from future transmissions of the Work.
>
I understand the impulse here, but I don't agree with it. First off, you're shifting the burden for compliance from you to the user, but you are in the better position to know whether or not there is personal information. Further, the benefit of open source licenses is that they are frictionless. Now, you are telling the downstream user that they cannot use the software with the knowledge that all the rights necessary to use the software have been granted, instead telling them that there might or might not be something in the software that they are not free to use, which they have to go find. I believe that the possibility that there are portions of the software that are not available under the license is also a violation of open source principles generally.
Moreover, obligations imposed by law and those imposed by the license are separate and distinct and we frown on efforts to import obligations imposed by law into the license. All users are obliged to comply with the law that applies to them, whether or not a license says so, so there is no need to duplicate the duty in the license. It also imposes obligations arising in one jurisdiction on others who might not otherwise have them in their jurisdiction, a violation of OSD6 (discrimination based on geographic locale).
In addition:
What does Section 4(d) do - how it is different from 4(c), other than to state it in the inverse?
What is Section 5(d) meant to say and do? Are you suggesting that those who don't contribute code, but conducted a scientific experiment, can be listed as authors of the work? The attribution list is generally understood to be those who have made copyrightable contributions to the source code file. This is useful information to have if one needs to contact all the authors for a license change, although it is being replaced by version control information. But by adding people who are not copyright authors you are adding noise to the intended use of the Notice file. Throwing non-authors into the mix might also invite those who don't actually have any rights to bring claims premised on the theory that they do because their name is listed.
>
> _______________________________________________
> The opinions expressed in this email are those of the sender and not necessarily those of the Open Source Initiative. Official statements by the Open Source Initiative will be sent from an opensource.org email address.
>
> License-discuss mailing list
> License-discuss at lists.opensource.org
> http://secure-web.cisco.com/1Nb3EmLj-TUobVb7eKsYNMzxWpP64o1UXRdCMtORK9
> XHLo-pr12cVXIFTjdPcx7qnMD8zZL-n22ztQPZgLt7e-WSprmtAOxkRJZQgq7P3LxRPwTh
> 27DlZVFTTL96fTCsnG7qV117cnA65aZJNExnl5-rxipVh0RW2l-ecoRFpfqmue2EVyiKqE
> f6mFn5Nc1h9o9mvn1RaT3tdFsK_O02ecNarcDtx9N4OTzEZjE0Zt7ouSIodsV6uiudAg20
> DPf6_h7f1QMrvwji2yeGTP_jQzJDySEAhXxrF6Hejq1VPeWLpYBR84C3mXMZY01afPb4zt
> xtyhIjT17B_L944PGNf8w/http%3A%2F%2Flists.opensource.org%2Fmailman%2Fli
> stinfo%2Flicense-discuss_lists.opensource.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://secure-web.cisco.com/1m3a_ucDEpPzy08yVfMFO8IFkue3fvRfqrkaybWeJEpzsVnedMDAx7Wry1IgC1RtdccEWwz-O8BtwMxaoyIW7208Gg9eAZsAJ9dNluOkUf9n0f18PBVpRi7zp0mYc6jEemHOk_XRJBfgoI59Qu2aIGYDIz3o8x6Ik_GBBcT9W1PjlHKZFM5VftvQUpnWqX16103cPr8sOuekynHNCSIajANvb-WKtgkk4XL_wowfVsFuyqUBZXs7AvGU3bODZc2OAsOyx8XORlkH4PfbZx8p-ilOUWKiZnamDLOb73IW_gdDI66RzLSvyy9SRl5tCo5q_nu8brsBIu38malS2Y8IHBw/http%3A%2F%2Flists.opensource.org%2Fpipermail%2Flicense-discuss_lists.opensource.org%2Fattachments%2F20241124%2F94cf0ae0%2Fattachment.htm>
------------------------------
Subject: Digest Footer
_______________________________________________
License-discuss mailing list
License-discuss at lists.opensource.org
http://secure-web.cisco.com/1Nb3EmLj-TUobVb7eKsYNMzxWpP64o1UXRdCMtORK9XHLo-pr12cVXIFTjdPcx7qnMD8zZL-n22ztQPZgLt7e-WSprmtAOxkRJZQgq7P3LxRPwTh27DlZVFTTL96fTCsnG7qV117cnA65aZJNExnl5-rxipVh0RW2l-ecoRFpfqmue2EVyiKqEf6mFn5Nc1h9o9mvn1RaT3tdFsK_O02ecNarcDtx9N4OTzEZjE0Zt7ouSIodsV6uiudAg20DPf6_h7f1QMrvwji2yeGTP_jQzJDySEAhXxrF6Hejq1VPeWLpYBR84C3mXMZY01afPb4ztxtyhIjT17B_L944PGNf8w/http%3A%2F%2Flists.opensource.org%2Fmailman%2Flistinfo%2Flicense-discuss_lists.opensource.org
------------------------------
End of License-discuss Digest, Vol 142, Issue 3
***********************************************
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.
More information about the License-discuss
mailing list