[License-discuss] The pro se license constructor

[VanL]

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

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:

- Abstract ("The CAL is a new strong "network" copyleft license especially
appropriate for distributed systems")
- Rationale (Why a new license?
<https://www.processmechanics.com/2019/03/15/the-cryptographic-autonomy-license/#whyanewlicense>)

- Overview of Proposal (Key Principles
<https://www.processmechanics.com/2019/03/15/the-cryptographic-autonomy-license/#keyprinciples>,
Breaking Down the CAL
<https://www.processmechanics.com/2019/03/15/the-cryptographic-autonomy-license/#breakingdownthecal>)

- Substantive Discussion of Key Points (What is the Work
<https://www.processmechanics.com/2019/03/15/the-cryptographic-autonomy-license/#whatisthework>,
Public Performance
<https://www.processmechanics.com/2019/03/15/the-cryptographic-autonomy-license/#copyleftandthepublicperformanceofsoftware>,
Maintaining User Autonomy
<https://www.processmechanics.com/2019/03/15/the-cryptographic-autonomy-license/#maintaininguserautonomy>
)
- Important Implementation Details (Other Concepts and Provisions
<https://www.processmechanics.com/2019/03/15/the-cryptographic-autonomy-license/#otherconceptsandprovisions>
)
- Disclaimers (Section regarding Holo and Holochain)

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.

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.

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

Thanks,
Van



On Tue, Mar 19, 2019 at 9:35 AM Pamela Chestek <pamela at chesteklegal.com>
wrote:

>
> On 3/18/2019 9:21 PM, John Sullivan wrote:
> > Bruce Perens <bruce at perens.com> writes:
> >
> >> 2. Use PEP. This appears to be an RFC-like process, and I am not yet
> clear
> >> how it avoids the complaint about the present process, which is that
> >> discussion of the proposal on a mailing list seems to be un-trackable or
> >> uncomfortable. Python mostly used the python-dev mailing list.
> > As one of the people who suggested something along these lines -- it
> > helps with tracking because a document is developed during the
> > conversation, and conversations can be expected to refer to the
> > document. Revisions of the document are posted periodically with a
> > standard subject line so that people who have not been able to track the
> > discussion threads can jump in, see where things stand, and still
> > contribute meaningfully.
> >
> > It doesn't help with the uncomfortable part.
> >
> > -john
> >
> Here's something to ponder - what if the license submitter was asked to
> maintain the PEP.
>
> Pam
>
> Pamela S. Chestek
> Chestek Legal
> PO Box 2492
> Raleigh, NC 27602
> 919-800-8033
> pamela at chesteklegal.com
> www.chesteklegal.com
>
> _______________________________________________
> 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/20190319/37665e2f/attachment.html>