Re: Contributor Clauses in Licenses
Pamela Chestek <[email protected]> Mon, 8 Dec 2025 15:43:20 -0800
| Newsgroups | gmane.comp.licenses.open-source.general |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============4807941450227705765== Content-Type: multipart/alternative; boundary="------------dcycce5CGl5cAyMOdBgYLgPJ" Content-Language: en-US Content-Transfer-Encoding: 7bit This is a multi-part message in MIME format. --------------dcycce5CGl5cAyMOdBgYLgPJ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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. 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. Pam [^1]: https://www.ce9.uscourts.gov/jury-instructions/node/283 Pamela S. Chestek Chestek Legal 4641 Post St. Unit 4316 El Dorado Hills, CA 95762 +1 919-800-8033 [email protected] www.chesteklegal.com Set a meeting with me <https://calendly.com/pamela-chesteklegal/30min> On 12/8/2025 2:12 PM, McCoy Smith wrote: > 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. > > 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. > > 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. > > 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. > > On 12/8/2025 1:57 PM, Josh Berkus wrote: >> On 12/8/25 1:46 PM, David Woolley wrote: >>>> 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; >>> >>> 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. >> >> Other way around. The outgoing license is trying to put conditions >> on how you contribute to the upstream project. >> >> >> _______________________________________________ >> 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.opensource.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.opensource.org --------------dcycce5CGl5cAyMOdBgYLgPJ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit <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:[email protected]">[email protected]</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:[email protected]">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:[email protected]">[email protected]</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:[email protected]">[email protected]</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> --------------dcycce5CGl5cAyMOdBgYLgPJ-- --===============4807941450227705765== 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= --===============4807941450227705765==--