[License-discuss] The political / technical dichotomy

[Chris Jerdonek]

On Wed, Mar 20, 2019 at 12:33 PM Richard Fontana <
richard.fontana at opensource.org> wrote:

> I have a different concern that goes to the political nature of
> license proposals. If the submitter is responsible for maintaining the
> PEP document, how can bias be avoided or minimized in the content of
> the document? Even if one relies on a non-submitter volunteer somehow,
> in many cases third-party observers are far from neutral.
>

This appears as a reply to me, so I'll respond.

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).

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.

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.

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.

(Note: there should probably be a different acronym if OSI were to adopt
this model. LRR -- License Review Request?)

--Chris



>
> (I happen to trust *VanL* to do a good job of hypothetically
> maintaining a PEP document for CAL, but that's because I've seen over
> the years that VanL is unusually receptive to acknowledging and
> considering alternate points of view. :)
>
> Richard
>
> On Tue, Mar 19, 2019 at 7:09 PM Chris Jerdonek <chris.jerdonek at gmail.com>
> wrote:
> >
> > On Tue, Mar 19, 2019 at 3:55 PM Bruce Perens <bruce at perens.com> wrote:
> >>
> >> 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?
> >
> >
> > 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--
> > https://www.python.org/dev/peps/pep-0572/
> > 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?).
> >
> > 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.
> >
> > --Chris
> >
> >
> >>
> >>
> >>     Thanks
> >>
> >>     Bruce
> >> _______________________________________________
> >> License-discuss mailing list
> >> License-discuss at lists.opensource.org
> >>
> http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
> >
> > _______________________________________________
> > License-discuss mailing list
> > License-discuss at lists.opensource.org
> >
> http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
>
> _______________________________________________
> License-discuss mailing list
> License-discuss at lists.opensource.org
>
> http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20190320/770fa3cf/attachment-0001.html>