Re: Total Reciprocity Public License (TRPL v1.0)
Shuji Sado <[email protected]> Sat, 13 Dec 2025 15:05:15 +0900
| Newsgroups | gmane.comp.licenses.open-source.general |
|---|---|
| Message-ID | <CAAvo7O7dsNPwLToDrp6xVHCYNw7JtxvZ7kF5g9oE=w9L2KBSmA@mail.gmail.com> |
--===============5301262394552206936== Content-Type: multipart/alternative; boundary="00000000000019e5100645cf2a11" Content-Transfer-Encoding: 7bit --00000000000019e5100645cf2a11 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jay, Josh, and all, https://discuss.opensource.org/t/distillation-and-oss-licensing/1333 I just noticed that Josh-san=E2=80=99s Discourse thread on distillation and copyleft-style model licensing is closely related to TRPL=E2=80=99s Section= 4.1 =E2=80=9CFunctional Output=E2=80=9D, especially where it treats =E2=80=9CML= trainer generating Model Weights=E2=80=9D as a derivative work and tries to impose reciprocity= on that output. My main point is about enforceability and scope. 1) If the =E2=80=9Cfunctional output=E2=80=9D (including weights) is not a = derivative work under copyright law in a given jurisdiction, then Section 4.1 cannot be enforced as a copyright condition in the usual Open Source license sense. At that point, the only realistic mechanism is contract (a promise by the downloader). 2) But contract obligations bind only parties who actually received the artifact and the license text (and can be shown to have assented). This is a weak fit for distillation via API access or output scraping, where the distiller may never have agreed to anything in the first place. 3) Also, relying heavily on contract increases jurisdictional uncertainty. In Japan, licenses are generally understood as a form of contract, but they are still analyzed primarily through copyright as the common baseline. Moving the center of gravity to pure contract makes cross-border predictability much worse. So I think reciprocity on =E2=80=9Cthings that look technically derivative = but are legally uncertain=E2=80=9D may be possible in a narrow, symbolic sense, but= it is unlikely to achieve the practical deterrence people hope for (and it risks drifting toward the kind of =E2=80=9Ctool controls the output=E2=80=9D prob= lem that Josh raised under OSD9). If the goal is an Open Source license, it may be safer to narrow 4.1 to situations where identifiable portions of the Program are actually incorporated into the output (for example runtime libraries), rather than deeming all functional output to be a derivative work by definition. Shuji 2025/12/10 0:09 Jay Patel <[email protected]>: > > Modified original Licence text into this draft from Feedbacks: > > https://github.com/trplfoundation/trpl-license/blob/main/Draft > > On Wed, Dec 3, 2025, 10:17=E2=80=AFPM Jay Patel <[email protected]> = wrote: > >> Thank You Gil for feedback.You identified a critical logical loop (the >> 'Postman problem') that would have made compliance impossible. >> >> Maybe adding this address your poins: >> 1. Adding a 'System Library/Standard Tool' exception: To ensure generic >> tools (OS, Browsers, API clients) are not infected, targeting only speci= fic >> functional wrappers. >> >> 2. Tightening 'Intimate Communication': Removing 'not limited to' and >> defining specific dependency types to reduce legal ambiguity. >> >> 3. Clarifying Deployment: Explicitly exempting personal/study use, >> focusing 'Deployment' on organizational/commercial utility. >> >> My goal is 'Stronger than AGPL,' not 'Impossible to Run.' Your feedback >> helps bridge that gap. >> >> Regards, >> Jay >> >> On Wed, Dec 3, 2025, 9:52=E2=80=AFPM Gil Yehuda <[email protected]> wro= te: >> >>> Jay, >>> If you intend to ask for critique, there=E2=80=99s quite a bit =E2=80= =94 from nitpicking >>> details to fundamental flaws. I=E2=80=99ll list some of the apparent on= es below as >>> I read the license text. >>> If you intend to suggest this as a new open source license that would >>> meet the OSD, I don=E2=80=99t think this will do. >>> >>> As I read the license: >>> >>> - Preamble: Licenses are documents that grant rights under >>> conditions. This text suggests that the license can guarantee freedo= m, >>> indeed =E2=80=9Cradical=E2=80=9D freedom (I=E2=80=99m not sure of th= e difference) in software >>> architecture (not just code?). Licenses should articulate the rights= they >>> grant and the conditions under which those rights are granted. Pream= bles >>> are great to convey intent which helps when trying to interpret ambi= guity; >>> but they also reveal cases where the intent is to express a wish for= how >>> things ought to be in the world. That=E2=80=99s better expressed in = a manifesto, >>> not a legal document. >>> - =E2=80=9CIntimate Communication=E2=80=9D is one of my favorite ter= ms found in >>> software licenses since it makes people think we=E2=80=99re also dab= bling in >>> marriage counseling. My constructive comment here is that when licen= ses say >>> =E2=80=9CThis includes, but is not limited to=E2=80=9D that automati= cally creates a speed >>> bump where a reader (and their lawyer) have to imagine if this inclu= des >>> something surprisingly not intended. It creates a very broad scope = =E2=80=94 and >>> that=E2=80=99s going to warn me to stay away from using code under t= his license >>> because I might intent to comply only to learn that the scope was ev= en >>> broader than assumed. >>> - =E2=80=9CContent Output=E2=80=9D is defined with two terms =E2=80= =9Chuman consumption or >>> data storage=E2=80=9D =E2=80=94 I understand the first to exclude no= n-human uses and the >>> second to exclude the use of data that is not stored. I note this be= cause >>> of the next phrase... >>> - =E2=80=9CDeployment=E2=80=9D is defined with a curious inclusion o= f the term >>> =E2=80=9Cinternally or externally=E2=80=9D which I assume means in t= he context of a >>> corporation (not of =E2=80=9Chuman consumption=E2=80=9D in the above= clause =E2=80=94 right?!) If >>> so, then =E2=80=9Cinternally=E2=80=9D suggests that if I deploy my a= pplication onto my work >>> computer for use by my work colleagues, then the copyright license >>> considers this to be =E2=80=9Cdeployment=E2=80=99 subject to copyrig= ht protection. I do not >>> believe that would hold up in the current interpretation of copyrigh= t laws. >>> - =E2=80=9CConsequently=E2=80=9D (line 40) is where this becomes qui= te challenging. >>> If I create a system with code licensed under TRPL 1.0 that shares d= ata >>> with any proprietary software to achieve a unified functional goal = =E2=80=94 this >>> license declares that the proprietary software becomes part of a "Co= mbined >>> Work=E2=80=9D that I must release its source code under the terms of= this license. >>> But what if that proprietary software is not mine to release? I migh= t not >>> even have the source code? Let=E2=80=99s say I license the proprieta= ry edition of >>> Postman and use it to make an API call to software under TRPL 1.0 = =E2=80=94 >>> internally (to my corporation, not in my body). I now have to acquir= e and >>> release Postman=E2=80=99s proprietary source code under the TRPL 1.0= license? How >>> would I go about doing that? Since there=E2=80=99s no definition of = =E2=80=9Crelease=E2=80=9D here, >>> can I assume that if I deploy internally, then I can release interna= lly >>> too? You see that would not help promote your intent. This section o= f the >>> license seems to convey how you wish software would work =E2=80=94 b= ut it does not >>> clarify how I, a potential user of software licensed under this lice= nse, >>> needs to do to make the world work that way. >>> >>> >>> I=E2=80=99m concerned there is little practical use of this license sin= ce any >>> software licensed this way, no matter how appealing that software may b= e, >>> is automatically going to pose a threat to the rest of my software. Giv= en >>> that software is subject to copyright, and that as a user of software, = I >>> seek to honor other people=E2=80=99s copyrights, this license would mak= e it nearly >>> impossible to do so. I=E2=80=99d always have to limit my use of this so= ftware to >>> ensure I don=E2=80=99t inadvertently infringe other people=E2=80=99s ri= ghts. >>> >>> Rather than a license, maybe we can collectively imagine what the past >>> 40-50 years of technology would have been like had there been no copyri= ght >>> on source code. I imagine it would be different =E2=80=94 better in som= e ways, >>> worse in others. This license appears to invoke that imagination. But s= ince >>> source code is subject to copyright laws, I think the licenses should d= o >>> their best to work within that context, granting rights that the granto= r >>> wishes to grant, and imposing conditions that the users of the software >>> wish to, and can, comply with. This text falls short on the second part= , at >>> least for me. >>> >>> Gil >>> >>> >>> >>> On Dec 3, 2025, at 12:59=E2=80=AFAM, Jay Patel <[email protected]>= wrote: >>> >>> I am reaching out to community to collect feedback on the proposed >>> license. >>> >>> Here is text of License: >>> >>> https://github.com/trplfoundation/trpl-license/blob/main/LICENSE >>> >>> Thanks, >>> >>> Jay >>> >>> _______________________________________________ >>> 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 >>> [email protected] >>> >>> http://lists.opensource.org/mailman/listinfo/license-discuss_lists.open= source.org >>> >>> >>> _______________________________________________ >>> 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 >>> [email protected] >>> >>> http://lists.opensource.org/mailman/listinfo/license-discuss_lists.open= source.org >>> >> _______________________________________________ > The opinions expressed in this email are those of the sender and not > necessarily those of the Open Source Initiative. Official statements by t= he > Open Source Initiative will be sent from an opensource.org email address. > > License-discuss mailing list > [email protected] > > http://lists.opensource.org/mailman/listinfo/license-discuss_lists.openso= urce.org > --=20 Shuji Sado Chairman, Open Source Group Japan https://opensource.jp/ English blog: https://shujisado.org/ Japanese blog: https://shujisado.com/ --00000000000019e5100645cf2a11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br>Hi Jay, Josh, and all,<br><br><a href= =3D"https://discuss.opensource.org/t/distillation-and-oss-licensing/1333">h= ttps://discuss.opensource.org/t/distillation-and-oss-licensing/1333</a><br>= I just noticed that Josh-san=E2=80=99s Discourse thread on distillation and= copyleft-style model licensing is closely related to TRPL=E2=80=99s Sectio= n 4.1 =E2=80=9CFunctional Output=E2=80=9D, especially where it treats =E2= =80=9CML trainer generating Model Weights=E2=80=9D as a derivative work and= tries to impose reciprocity on that output.<br><br>My main point is about = enforceability and scope.<br><br>1) If the =E2=80=9Cfunctional output=E2=80= =9D (including weights) is not a derivative work under copyright law in a g= iven jurisdiction, then Section 4.1 cannot be enforced as a copyright condi= tion in the usual Open Source license sense. At that point, the only realis= tic mechanism is contract (a promise by the downloader).<br>2) But contract= obligations bind only parties who actually received the artifact and the l= icense text (and can be shown to have assented). This is a weak fit for dis= tillation via API access or output scraping, where the distiller may never = have agreed to anything in the first place.<br>3) Also, relying heavily on = contract increases jurisdictional uncertainty. In Japan, licenses are gener= ally understood as a form of contract, but they are still analyzed primaril= y through copyright as the common baseline. Moving the center of gravity to= pure contract makes cross-border predictability much worse.<br><br>So I th= ink reciprocity on =E2=80=9Cthings that look technically derivative but are= legally uncertain=E2=80=9D may be possible in a narrow, symbolic sense, bu= t it is unlikely to achieve the practical deterrence people hope for (and i= t risks drifting toward the kind of =E2=80=9Ctool controls the output=E2=80= =9D problem that Josh raised under OSD9).<br><br>If the goal is an Open Sou= rce license, it may be safer to narrow 4.1 to situations where identifiable= portions of the Program are actually incorporated into the output (for exa= mple runtime libraries), rather than deeming all functional output to be a = derivative work by definition.<br><br>Shuji<br><br></div><br><div class=3D"= gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">20= 25/12/10 0:09 Jay Patel <<a href=3D"mailto:[email protected]">jaypa= [email protected]</a>>:<br></div><blockquote class=3D"gmail_quote" style= =3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding= -left:1ex"><div dir=3D"auto"><div><br></div><div>Modified original Licence = text into this draft from Feedbacks:</div><div dir=3D"auto"><br></div><div = dir=3D"auto"><a href=3D"https://github.com/trplfoundation/trpl-license/blob= /main/Draft" target=3D"_blank">https://github.com/trplfoundation/trpl-licen= se/blob/main/Draft</a></div></div><br><div class=3D"gmail_quote"><div dir= =3D"ltr" class=3D"gmail_attr">On Wed, Dec 3, 2025, 10:17=E2=80=AFPM Jay Pat= el <<a href=3D"mailto:[email protected]" target=3D"_blank">jaypatel= [email protected]</a>> wrote:<br></div><blockquote class=3D"gmail_quote" st= yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd= ing-left:1ex"><div dir=3D"auto"><div><div>Thank You Gil for feedback.You id= entified a critical logical loop (the 'Postman problem') that would= have made compliance impossible.</div><div dir=3D"auto"><br></div><div dir= =3D"auto">Maybe adding this address your poins:</div><div dir=3D"auto">1. A= dding a 'System Library/Standard Tool' exception: To ensure generic= tools (OS, Browsers, API clients) are not infected, targeting only specifi= c functional wrappers.</div><div dir=3D"auto"><br></div><div dir=3D"auto">2= . Tightening 'Intimate Communication': Removing 'not limited to= ' and defining specific dependency types to reduce legal ambiguity.</di= v><div dir=3D"auto"><br></div><div dir=3D"auto">3. Clarifying Deployment: E= xplicitly exempting personal/study use, focusing 'Deployment' on or= ganizational/commercial utility.</div><div dir=3D"auto"><br></div><div dir= =3D"auto">My goal is 'Stronger than AGPL,' not 'Impossible to R= un.' Your feedback helps bridge that gap.</div><div dir=3D"auto"><br></= div>Regards,</div><div dir=3D"auto">Jay<br><br><div class=3D"gmail_quote" d= ir=3D"auto"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Dec 3, 2025, 9:52= =E2=80=AFPM Gil Yehuda <<a href=3D"mailto:[email protected]" rel=3D"nor= eferrer" target=3D"_blank">[email protected]</a>> wrote:<br></div><bloc= kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:= 1px solid rgb(204,204,204);padding-left:1ex"><div><div>Jay,=C2=A0<div>If yo= u intend to ask for critique, there=E2=80=99s quite a bit =E2=80=94 from ni= tpicking details to fundamental flaws. I=E2=80=99ll list some of the appare= nt ones below as I read the license text.</div><div>If you intend to sugges= t this as a new open source license that would meet the OSD, I don=E2=80=99= t think this will do.</div><div><br></div><div>As I read the license:</div>= <div><ul><li>Preamble: Licenses are documents that grant rights under condi= tions. This text suggests that the license can guarantee freedom, indeed = =E2=80=9Cradical=E2=80=9D freedom (I=E2=80=99m not sure of the difference) = in software architecture (not just code?). Licenses should articulate the r= ights they grant and the conditions under which those rights are granted. P= reambles are great to convey intent which helps when trying to interpret am= biguity; but they also reveal cases where the intent is to express a wish f= or how things ought to be in the world. That=E2=80=99s better expressed in = a manifesto, not a legal document.</li><li>=E2=80=9CIntimate Communication= =E2=80=9D is one of my favorite terms found in software licenses since it m= akes people think we=E2=80=99re also dabbling in marriage counseling. My co= nstructive comment here is that when licenses say =E2=80=9CThis includes, b= ut is not limited to=E2=80=9D that automatically creates a speed bump where= a reader (and their lawyer) have to imagine if this includes something sur= prisingly not intended. It creates a very broad scope =E2=80=94 and that=E2= =80=99s going to warn me to stay away from using code under this license be= cause I might intent to comply only to learn that the scope was even broade= r than assumed.</li><li>=E2=80=9CContent Output=E2=80=9D is defined with tw= o terms =E2=80=9Chuman consumption or data storage=E2=80=9D =E2=80=94 I und= erstand the first to exclude non-human uses and the second to exclude the u= se of data that is not stored. I note this because of the next phrase...</l= i><li>=E2=80=9CDeployment=E2=80=9D is defined with a curious inclusion of t= he term =E2=80=9Cinternally or externally=E2=80=9D which I assume means in = the context of a corporation (not of =E2=80=9Chuman consumption=E2=80=9D in= the above clause =E2=80=94 right?!) If so, then =E2=80=9Cinternally=E2=80= =9D suggests that if I deploy my application onto my work computer for use = by my work colleagues, then the copyright license considers this to be =E2= =80=9Cdeployment=E2=80=99 subject to copyright protection. I do not believe= that would hold up in the current interpretation of copyright laws.=C2=A0<= /li><li>=E2=80=9CConsequently=E2=80=9D (line 40) is where this becomes quit= e challenging. If I create a system with code licensed under TRPL 1.0 that = shares data with any proprietary software=C2=A0to achieve a unified functio= nal goal =E2=80=94 this license declares that the proprietary software beco= mes part of=C2=A0a "Combined Work=E2=80=9D that I must release its sou= rce code under the terms of this license. But what if that proprietary soft= ware is not mine to release? I might not even have the source code? Let=E2= =80=99s say I license the proprietary edition of Postman and use it to make= an API call to software under TRPL 1.0 =E2=80=94 internally (to my corpora= tion, not in my body). I now have to acquire and release Postman=E2=80=99s = proprietary source code under the TRPL 1.0 license? How would I go about do= ing that? Since there=E2=80=99s no definition of =E2=80=9Crelease=E2=80=9D = here, can I assume that if I deploy internally, then I can release internal= ly too? You see that would not help promote your intent. This section of th= e license seems to convey how you wish software would work =E2=80=94 but it= does not clarify how I, a potential user of software licensed under this l= icense, needs to do to make the world work that way.=C2=A0</li></ul><div><b= r></div><div>I=E2=80=99m concerned there is little practical use of this li= cense since any software licensed this way, no matter how appealing that so= ftware may be, is automatically going to pose a threat to the rest of my so= ftware. Given that software is subject to copyright, and that as a user of = software, I seek to honor other people=E2=80=99s copyrights, this license w= ould make it nearly impossible to do so. I=E2=80=99d always have to limit m= y use of this software to ensure I don=E2=80=99t inadvertently infringe oth= er people=E2=80=99s rights.</div></div><div><br></div><div>Rather than a li= cense, maybe we can collectively imagine what the past 40-50 years of techn= ology would have been like had there been no copyright on source code. I im= agine it would be different =E2=80=94 better in some ways, worse in others.= This license appears to invoke that imagination. But since source code is = subject to copyright laws, I think the licenses should do their best to wor= k within that context, granting rights that the grantor wishes to grant, an= d imposing conditions that the users of the software wish to, and can, comp= ly with. This text falls short on the second part, at least for me.=C2=A0</= div><div><br></div><div>Gil</div><div><br></div><div><br id=3D"m_-163379506= 9473747226m_4525705651384579800m_7648066646094320510lineBreakAtBeginningOfM= essage"><div><br><blockquote type=3D"cite"><div>On Dec 3, 2025, at 12:59=E2= =80=AFAM, Jay Patel <<a href=3D"mailto:[email protected]" rel=3D"no= referrer noreferrer" target=3D"_blank">[email protected]</a>> wrote= :</div><br><div><div dir=3D"auto">I am reaching out to community to collect= feedback on the proposed license.<div dir=3D"auto"><br></div><div dir=3D"a= uto">Here is text of License:</div><div dir=3D"auto"><br></div><div dir=3D"= auto"><a href=3D"https://github.com/trplfoundation/trpl-license/blob/main/L= ICENSE" rel=3D"noreferrer noreferrer" target=3D"_blank">https://github.com/= trplfoundation/trpl-license/blob/main/LICENSE</a></div><div dir=3D"auto"><b= r></div><div dir=3D"auto">Thanks,</div><div dir=3D"auto"><br></div><div dir= =3D"auto">Jay</div><div dir=3D"auto"><br></div></div> _______________________________________________<br>The opinions expressed i= n this email are those of the sender and not necessarily those of the Open = Source Initiative. Official statements by the Open Source Initiative will b= e sent from an <a href=3D"http://opensource.org" rel=3D"noreferrer noreferr= er" target=3D"_blank">opensource.org</a> email address.<br><br>License-disc= uss mailing list<br><a href=3D"mailto:[email protected]"= rel=3D"noreferrer noreferrer" target=3D"_blank">[email protected]= source.org</a><br><a href=3D"http://lists.opensource.org/mailman/listinfo/l= icense-discuss_lists.opensource.org" rel=3D"noreferrer noreferrer" target= =3D"_blank">http://lists.opensource.org/mailman/listinfo/license-discuss_li= sts.opensource.org</a><br></div></blockquote></div><br></div></div></div>__= _____________________________________________<br> The opinions expressed in this email are those of the sender and not necess= arily those of the Open Source Initiative. Official statements by the Open = Source Initiative will be sent from an <a href=3D"http://opensource.org" re= l=3D"noreferrer noreferrer noreferrer" target=3D"_blank">opensource.org</a>= email address.<br> <br> License-discuss mailing list<br> <a href=3D"mailto:[email protected]" rel=3D"noreferrer n= oreferrer" target=3D"_blank">[email protected]</a><br> <a href=3D"http://lists.opensource.org/mailman/listinfo/license-discuss_lis= ts.opensource.org" rel=3D"noreferrer noreferrer noreferrer" target=3D"_blan= k">http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opens= ource.org</a><br> </blockquote></div></div></div> </blockquote></div> _______________________________________________<br> The opinions expressed in this email are those of the sender and not necess= arily those of the Open Source Initiative. Official statements by the Open = Source Initiative will be sent from an <a href=3D"http://opensource.org" re= l=3D"noreferrer" target=3D"_blank">opensource.org</a> email address.<br> <br> License-discuss mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_blank">L= [email protected]</a><br> <a href=3D"http://lists.opensource.org/mailman/listinfo/license-discuss_lis= ts.opensource.org" rel=3D"noreferrer" target=3D"_blank">http://lists.openso= urce.org/mailman/listinfo/license-discuss_lists.opensource.org</a><br> </blockquote></div><div><br clear=3D"all"></div><div><br></div><span class= =3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_s= ignature"><div dir=3D"ltr"><div>Shuji Sado</div><div>Chairman, Open Source = Group Japan<br><a href=3D"https://opensource.jp/" target=3D"_blank">https:/= /opensource.jp/</a><br>English blog: <a href=3D"https://shujisado.org/" tar= get=3D"_blank">https://shujisado.org/</a></div><div>Japanese blog:=C2=A0<a = href=3D"https://shujisado.com/" target=3D"_blank">https://shujisado.com/</a= ></div><div><br></div></div></div></div> --00000000000019e5100645cf2a11-- --===============5301262394552206936== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KVGhlIG9waW5p b25zIGV4cHJlc3NlZCBpbiB0aGlzIGVtYWlsIGFyZSB0aG9zZSBvZiB0aGUgc2VuZGVyIGFuZCBu b3QgbmVjZXNzYXJpbHkgdGhvc2Ugb2YgdGhlIE9wZW4gU291cmNlIEluaXRpYXRpdmUuIE9mZmlj aWFsIHN0YXRlbWVudHMgYnkgdGhlIE9wZW4gU291cmNlIEluaXRpYXRpdmUgd2lsbCBiZSBzZW50 IGZyb20gYW4gb3BlbnNvdXJjZS5vcmcgZW1haWwgYWRkcmVzcy4KCkxpY2Vuc2UtZGlzY3VzcyBt YWlsaW5nIGxpc3QKTGljZW5zZS1kaXNjdXNzQGxpc3RzLm9wZW5zb3VyY2Uub3JnCmh0dHA6Ly9s aXN0cy5vcGVuc291cmNlLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpY2Vuc2UtZGlzY3Vzc19saXN0 cy5vcGVuc291cmNlLm9yZwo= --===============5301262394552206936==--