[License-discuss] The pro se license constructor
van.lindberg at gmail.com
Tue Mar 19 16:29:08 UTC 2019
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?
- Overview of Proposal (Key Principles
Breaking Down the CAL
- Substantive Discussion of Key Points (What is the Work
Maintaining User Autonomy
- Important Implementation Details (Other Concepts and Provisions
- 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).
On Tue, Mar 19, 2019 at 9:35 AM Pamela Chestek <pamela at chesteklegal.com>
> 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
> >> 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.
> Pamela S. Chestek
> Chestek Legal
> PO Box 2492
> Raleigh, NC 27602
> pamela at chesteklegal.com
> License-discuss mailing list
> License-discuss at lists.opensource.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the License-discuss