<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
I am in favor of an express statement in the license and agree that
the statement should be inbound=outbound. There was a lot of doubt
about the licensing of contributions in earlier open source history,
which I believe is the driving force behind the creation of the
CAA/CLA (and why some companies still won't accept contributions
without them, although nowadays its the inequality of the grant that
more likely drives it). AFAIK Larry Rosen first articulated the
concept of an implied inbound=outbound license in his book and then
Richard Fontana came up with a catchy name and it's been accepted as
The Way Things Are since then. But implied licenses are narrowly
construed and there is also some really weird, underinclusive case
law around implied licenses in some circuits in the U.S. (notably
the 9th, which includes California)[^1] which makes me even less
certain that a court's decision would match what we all believe to
be true. So I think an inbound=outbound statement makes sense.<br>
<br>
As to Josh's comment "No text contained within the license can
enforce that my PR is under that license," I disagree. When I
created my contribution I necessarily accepted the terms of the
outbound license, or at least I am hard-pressed to think of a way
that someone made a contribution that matters but would not have
taken an action that requires acceptance of the license. Since I
accepted the project license, I therefore agreed to the terms for my
contribution and the CLA within the license is enforceable against
me as a contributor. That's essentially the same mechanism as
implied inbound=outbound -- I was aware of the license terms and
understood that my contribution would be licensed under those terms.
This just makes it an express condition, not implied. If an express
grant isn't enforceable against a contributor, then the implied
grant is even less likely to be enforceable against them.<br>
<br>
Pam<br>
<br>
[^1]: <a class="moz-txt-link-freetext" href="https://www.ce9.uscourts.gov/jury-instructions/node/283">https://www.ce9.uscourts.gov/jury-instructions/node/283</a><br>
<br>
<div class="moz-signature">Pamela S. Chestek<br>
Chestek Legal<br>
4641 Post St.<br>
Unit 4316<br>
El Dorado Hills, CA 95762<br>
+1 919-800-8033<br>
<a class="moz-txt-link-abbreviated" href="mailto:pamela@chesteklegal.com">pamela@chesteklegal.com</a><br>
<a class="moz-txt-link-abbreviated" href="http://www.chesteklegal.com">www.chesteklegal.com</a><br>
<br>
<a href="https://calendly.com/pamela-chesteklegal/30min">Set a
meeting with me</a></div>
<div class="moz-cite-prefix">On 12/8/2025 2:12 PM, McCoy Smith
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:bc68460e-7a0b-4e57-b237-1c33465f59be@lexpan.law">If the
contribution is a (C) derivative, I'm not sure I'm seeing why this
is an issue. All OS licenses (other than the -0 ones) impose
conditions on derivatives.
<br>
<br>
If the contribution is not a derivative, they're merely
articulating the conditions under which a contribution would be
accepted by the project maintainers, *not* a condition on how the
non-derivative work can otherwise be used. Again, I don't see how
that is an issue.
<br>
<br>
The bigger problem with these combined outbound license+inbound
cla documents is they often attempt to impose non-reciprocal
conditions -- i.e., outbound license has conditions --
attribution, source, etc., but inbound CLA imposes no conditions
on the project maintainers w/r/t the submitted contributions. That
makes the license discriminatory.
<br>
<br>
One could solve this problem by simply saying license in=license
out but you don't need a separate clause in a license to do that.
<br>
<br>
On 12/8/2025 1:57 PM, Josh Berkus wrote:
<br>
<blockquote type="cite">On 12/8/25 1:46 PM, David Woolley wrote:
<br>
<blockquote type="cite">
<blockquote type="cite">1. Unless enforced by some other
mechanism (CLA, repository TOS, etc.), it is not
automatically true that contributions are under the license
in the first place;
<br>
</blockquote>
<br>
CLAs aren't licences to the contributor, but rather a licence
from the contributor to the initial developer, often allowing
the initial developer to use the contributions outside of open
source licensing. As such I don't see how they can be used to
constrain someone creating modifications to the code.
<br>
</blockquote>
<br>
Other way around. The outgoing license is trying to put
conditions on how you contribute to the upstream project.
<br>
<br>
<br>
_______________________________________________
<br>
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.
<br>
<br>
License-discuss mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:License-discuss@lists.opensource.org">License-discuss@lists.opensource.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org">http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org</a>
<br>
</blockquote>
<br>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
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
<a class="moz-txt-link-abbreviated" href="mailto:License-discuss@lists.opensource.org">License-discuss@lists.opensource.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org">http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org</a>
</pre>
</blockquote>
<br>
</body>
</html>