<p>All,</p>
<p>I think one distinction may simplify the design question considerably:</p>
<p>the event that triggers reciprocity and the code to which reciprocity applies are separate drafting dimensions.</p>
<p>Put more simply:</p>
<ol>
<li>Trigger \u2014 what event causes the reciprocity obligation to apply?</li>
<li>Scope \u2014 once triggered, what code is subject to that obligation?</li>
</ol>
<p>A network-use provision can expand the first without necessarily expanding the second.</p>
<p>After looking through several OSI-approved licenses and some older license-discuss history, I think CPAL-1.0 provides a particularly useful example.</p>
<p>CPAL uses the MPL 1.1-style distinction between \u201cCovered Code\u201d and a \u201cLarger Work.\u201d</p>
<p>A Larger Work may combine Covered Code with code not governed by CPAL.</p>
<p>Section 3.7 expressly permits that arrangement:</p>
<p>«\u201cYou may create a Larger Work by combining Covered Code with other code not governed by the terms of this License and distribute the Larger Work as a single product.\u201d»</p>
<p>The same provision requires CPAL\u2019s requirements to continue to be satisfied for the Covered Code.</p>
<p>So the scope boundary already exists before network use enters the analysis.</p>
<p>Section 15 then introduces \u201cExternal Deployment,\u201d including making the Original Code or Modifications available as an application intended for use over a network.</p>
<p>The important structural point is what happens next.</p>
<p>Section 15 does not say that External Deployment causes the entire Larger Work to become Covered Code.</p>
<p>Instead, External Deployment of the Original Code or Modifications is treated as distribution for purposes of Sections 3.1 and 3.2.</p>
<p>For the source-reciprocity mechanism, the architecture therefore appears to be:</p>
<p>Covered Code / Modification scope<br>
+<br>
External Deployment trigger</p>
<p>rather than:</p>
<p>External Deployment<br>
\u2193<br>
new reciprocity boundary for the entire Larger Work</p>
<p>That makes CPAL useful as an example of what I would describe as a scope-preserving network trigger.</p>
<p>The network provision expands when the existing reciprocity obligation activates without, merely by doing so, expanding what code that obligation governs.</p>
<p>OSL-3.0 provides a second useful comparison, although its reciprocity architecture is different from CPAL\u2019s.</p>
<p>Section 5 treats External Deployment of the Original Work or a Derivative Work as distribution under the license.</p>
<p>What makes OSL especially useful here is the older license-discuss history.</p>
<p>During discussion of the External Deployment provision in 2005, Lawrence Rosen addressed whether proprietary systems linked to externally deployed OSL software would consequently have to be disclosed.</p>
<p>His explanation was that linking was not the relevant reciprocity boundary and that proprietary systems merely linked to the OSL software would not thereby become subject to disclosure; at most, modifications to the OSL-licensed software would have to be disclosed.</p>
<p>That seems to illustrate the same separation:</p>
<p>External Deployment answers whether the obligation is triggered.</p>
<p>The definitions of Original Work and Derivative Work answer what the obligation reaches.</p>
<p>There was also a license-discuss exchange in 2023 concerning network copyleft without some of AGPLv3\u2019s additional requirements in which OSL-3.0 Section 5 was specifically identified as an existing OSI-approved alternative.</p>
<p>So I think the threshold question here can be made narrower than whether \u201cweak network copyleft\u201d is possible in the abstract.</p>
<p>The labels \u201cweak\u201d and \u201cstrong\u201d are useful shorthand, but I would not make them carry the whole analysis.</p>
<p>The more precise question is:</p>
<p>«Does the proposed network clause only add a new event that activates the license\u2019s existing reciprocity rule, or does it also redefine the boundary of the code governed by that rule?»</p>
<p>Consider a minimal example.</p>
<ul>
<li>File A is within the license\u2019s existing reciprocal scope.</li>
<li>A is modified.</li>
<li>Files B and C are independently written and outside that scope.</li>
<li>A, B, and C operate together as one network service.</li>
<li>Remote users interact with that service.</li>
</ul>
<p>A scope-preserving network rule could produce:</p>
<p>remote interaction<br>
\u2193<br>
reciprocity trigger occurs<br>
\u2193<br>
source for A and the modifications to A must be made available</p>
<p>while preserving:</p>
<p>B and C remain outside the reciprocity boundary</p>
<p>assuming B and C were outside that boundary under the license\u2019s ordinary scope rules in the first place.</p>
<p>I think that final qualification is important.</p>
<p>The network clause should not need to decide again whether B or C is a Modification, Derivative Work, Covered Code, part of the licensed Work, or otherwise within the reciprocal scope.</p>
<p>That question should already have been answered by the license\u2019s underlying reciprocity rules.</p>
<p>The network provision should ideally answer only the new question:</p>
<p>has an event occurred that activates those existing obligations?</p>
<p>That suggests a simple drafting test.</p>
<p>First determine the set of code subject to reciprocity without the network provision.</p>
<p>Then add the network event.</p>
<p>If the set of code governed by reciprocity remains the same and only the obligation changes from inactive to active, the provision is trigger-expanding but scope-preserving.</p>
<p>If the network event also changes the set of code that falls within reciprocity, then the clause is doing two things:</p>
<ol>
<li>expanding the trigger; and</li>
<li>expanding the scope.</li>
</ol>
<p>That may be intentional, but if so I think it should be explicit.</p>
<p>This is the part of CPAL Section 15 that I find particularly useful.</p>
<p>It names \u201cOriginal Code or Modifications\u201d as the subject of External Deployment and routes the consequence back into the existing source obligations, while Section 3.7 separately preserves the Larger Work distinction.</p>
<p>In compact form:</p>
<p>trigger expansion \u2260 scope expansion</p>
<p>If the intended design is MPL-style or Covered-Code reciprocity with remote network interaction added as another trigger for the same pre-existing reciprocity obligation, I would examine CPAL-1.0 especially closely.</p>
<p>I would use OSL-3.0 as a second comparison because its license-discuss history makes the trigger/scope distinction unusually explicit.</p>
<p>EUPL-1.2 is also relevant as secondary evidence because its definition of Distribution or Communication includes making functionality accessible over a network, while the operative subject matter remains defined elsewhere in the license. Its reciprocity architecture is sufficiently different that I would not treat it as the closest model.</p>
<p>One caution about CPAL: its Section 14 attribution provisions have their own treatment of Larger Works.</p>
<p>So I would not use CPAL as shorthand for the broader proposition that every CPAL obligation necessarily stops at the Covered Code boundary.</p>
<p>The narrower proposition is sufficient:</p>
<p>CPAL\u2019s Section 15 source-reciprocity mechanism does not, merely by introducing External Deployment, erase the Covered Code / Larger Work distinction established elsewhere in the license.</p>
<p>That seems to me the most useful precedent for the drafting question here.</p>
<p>CPAL-1.0:<br>
<a href="https://opensource.org/license/cpal-1.0">https://opensource.org/license/cpal-1.0</a></p>
<p>OSL-3.0:<br>
<a href="https://opensource.org/license/osl-3.0">https://opensource.org/license/osl-3.0</a></p>
<p>EUPL-1.2:<br>
<a href="https://opensource.org/license/eupl-1.2">https://opensource.org/license/eupl-1.2</a></p>
<p>OSL / External Deployment discussion (2005):<br>
<a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2005-September/010996.html">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2005-September/010996.html</a></p>
<p>Network copyleft discussion (2023):<br>
<a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2023-May/022101.html">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2023-May/022101.html</a></p>
<p>Best regards,</p>
<p>Yuta Yokoi</p>