<div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Regarding PEPs, the process relative to the CAL is not too far off from a PEP-like process. Each PEP has one or more authors and champions - in this case me. The PEP itself is essentially a long-form summary of the proposal, subsequent discussion and decisions, and<br></div><div><br></div><div>Ordinarily, there are three main parts of a PEP. First is a summary and rationale for the change (in this case, the new license), with a discussion of particular points of interest. In the case of the CAL, the blog post I put up to begin the discussion here is very similar to what I expect would be needed in a license proposal:</div><div><br></div><div>- Abstract ("The CAL is a new strong "network" copyleft license especially appropriate for distributed systems")

</div><div>- Rationale (<a href="https://www.processmechanics.com/2019/03/15/the-cryptographic-autonomy-license/#whyanewlicense">Why a new license?</a>) <br></div><div>- Overview of Proposal (<a href="https://www.processmechanics.com/2019/03/15/the-cryptographic-autonomy-license/#keyprinciples">Key Principles</a>, <a href="https://www.processmechanics.com/2019/03/15/the-cryptographic-autonomy-license/#breakingdownthecal">Breaking Down the CAL</a>) <br></div><div>- Substantive Discussion of Key Points (<a href="https://www.processmechanics.com/2019/03/15/the-cryptographic-autonomy-license/#whatisthework">What is the Work</a>, <a href="https://www.processmechanics.com/2019/03/15/the-cryptographic-autonomy-license/#copyleftandthepublicperformanceofsoftware">Public Performance</a>, <a href="https://www.processmechanics.com/2019/03/15/the-cryptographic-autonomy-license/#maintaininguserautonomy">Maintaining User Autonomy</a>)</div><div>- Important Implementation Details (<a href="https://www.processmechanics.com/2019/03/15/the-cryptographic-autonomy-license/#otherconceptsandprovisions">Other Concepts and Provisions</a>)<br></div><div>- Disclaimers (Section regarding Holo and Holochain) <br></div><div><br></div><div>The second part is an ongoing record of comments made and responses. Usually, accepted suggestions are incorporated into the proposal; rejected suggestions are documented with a rationale. That is what is happening with the CAL. Accepted suggestions are being incorporated into the live document. Rejected suggestions are declined with a rationale.</div><div><br></div><div>Relative to the CAL, part of that is on this list, and part of it is viewable via the Google Doc. In particular, I am replying to suggestions that are not adopted, rather than "resolving" them. This is so that the question and response stay visible for other viewers.</div><div><br></div><div>The third is a process marker. For the CAL, it is "in discussion" (on L-D), after which it would go to "in review" (on L-R), and finally accepted or rejected (by the OSI board).</div><div><br></div><div>Thanks,<br></div><div>Van</div><div><br></div><div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 19, 2019 at 9:35 AM Pamela Chestek <<a href="mailto:pamela@chesteklegal.com">pamela@chesteklegal.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On 3/18/2019 9:21 PM, John Sullivan wrote:<br>
> Bruce Perens <<a href="mailto:bruce@perens.com" target="_blank">bruce@perens.com</a>> writes:<br>
><br>
>> 2. Use PEP. This appears to be an RFC-like process, and I am not yet clear<br>
>> how it avoids the complaint about the present process, which is that<br>
>> discussion of the proposal on a mailing list seems to be un-trackable or<br>
>> uncomfortable. Python mostly used the python-dev mailing list.<br>
> As one of the people who suggested something along these lines -- it<br>
> helps with tracking because a document is developed during the<br>
> conversation, and conversations can be expected to refer to the<br>
> document. Revisions of the document are posted periodically with a<br>
> standard subject line so that people who have not been able to track the<br>
> discussion threads can jump in, see where things stand, and still<br>
> contribute meaningfully.<br>
><br>
> It doesn't help with the uncomfortable part.<br>
><br>
> -john<br>
><br>
Here's something to ponder - what if the license submitter was asked to<br>
maintain the PEP.<br>
<br>
Pam<br>
<br>
Pamela S. Chestek<br>
Chestek Legal<br>
PO Box 2492<br>
Raleigh, NC 27602<br>
919-800-8033<br>
<a href="mailto:pamela@chesteklegal.com" target="_blank">pamela@chesteklegal.com</a><br>
<a href="http://www.chesteklegal.com" rel="noreferrer" target="_blank">www.chesteklegal.com</a><br>
<br>
_______________________________________________<br>
License-discuss mailing list<br>
<a href="mailto:License-discuss@lists.opensource.org" target="_blank">License-discuss@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org" rel="noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org</a><br>
</blockquote></div>