<div dir="ltr"><div dir="ltr">On Wed, Mar 20, 2019 at 12:33 PM Richard Fontana <<a href="mailto:richard.fontana@opensource.org">richard.fontana@opensource.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I have a different concern that goes to the political nature of<br>
license proposals. If the submitter is responsible for maintaining the<br>
PEP document, how can bias be avoided or minimized in the content of<br>
the document? Even if one relies on a non-submitter volunteer somehow,<br>
in many cases third-party observers are far from neutral.<br></blockquote><div><br></div><div>This appears as a reply to me, so I'll respond.</div><div><br></div><div>It was someone else that suggested the submitter could be responsible for maintaining the document. Nevertheless, I think this model can work for the following reason (and does for Python).</div><div><br></div><div>If the submitter is not doing a good job of maintaining the PEP (e.g. not capturing people's arguments correctly, not writing it well, etc), then there is a simple answer. OSI can reject it for those reasons. Thus, the submitter has an incentive to be professional and unbiased.</div><div><br></div><div>Even if the submitter is writing the text, there is one caveat to this though. There should still probably be an administrative gatekeeper of some sort so that the documents are located in one place, and not retroactively changed. And a revision history with diffs would also help a lot.</div><div><br></div><div>Python handles this by putting all PEP's in a Git repository that can only be pushed by a Python core developer (someone with commit privileges). This helps with a few things. People can monitor the changes so they don't have to reread the whole thing each time it is revised. Also, once a decision is made on it, there wouldn't be a risk of the author revising the history, since the official repo is gated to people with access.</div><div><br></div><div>(Note: there should probably be a different acronym if OSI were to adopt this model. LRR -- License Review Request?)<br></div><div><br></div><div>--Chris</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
(I happen to trust *VanL* to do a good job of hypothetically<br>
maintaining a PEP document for CAL, but that's because I've seen over<br>
the years that VanL is unusually receptive to acknowledging and<br>
considering alternate points of view. :)<br>
<br>
Richard<br>
<br>
On Tue, Mar 19, 2019 at 7:09 PM Chris Jerdonek <<a href="mailto:chris.jerdonek@gmail.com" target="_blank">chris.jerdonek@gmail.com</a>> wrote:<br>
><br>
> On Tue, Mar 19, 2019 at 3:55 PM Bruce Perens <<a href="mailto:bruce@perens.com" target="_blank">bruce@perens.com</a>> wrote:<br>
>><br>
>> We should keep this in mind as we consider processes like PEP. They are designed to create consensus, and their subject has mainly been technical issues where consensus is easier to form. Just how will they handle a failure to achieve consensus?<br>
><br>
><br>
> Python's PEP process definitely isn't designed to create consensus and doesn't claim to reach consensus. For example, Python's relatively recent PEP 572 ("Assignment expressions") from a year ago was highly contentious--<br>
> <a href="https://www.python.org/dev/peps/pep-0572/" rel="noreferrer" target="_blank">https://www.python.org/dev/peps/pep-0572/</a><br>
> Some informal polls at the time indicated that an extremely high percentage of core developers (something like on the order of 90%, IIRC) were opposed to the PEP, and yet it was adopted. This is because Python was using the BDFL model at the time. (Now Python is using a 5-member steering council process to make decisions.) So the way of deciding on a proposal is separate from the format of the PEP document itself. OSI can use whatever method it wants (voting?).<br>
><br>
> The PEP format is largely a documentation issue. It doesn't say anything to the effect that all objections need to be accommodated. Rather, they just need to be documented for posterity, with an explanation of why the objection was rejected.<br>
><br>
> --Chris<br>
><br>
><br>
>><br>
>><br>
>>     Thanks<br>
>><br>
>>     Bruce<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>
><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>
<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></div>