[License-review] When a submission for approval stops being one (was: For Approval: License Zero Reciprocal Public License)

[Kyle Mitchell]

Rick,

As you say, neither you, nor OSI, nor the "commentariat" owe
me any time whatsoever.  I hope my thanks tell my gratitude,
that time and attention I've taken to read and reply in
depth show it.  All of that would be valid as a cold-hearted
tactic, if all I cared about was approval.  I can give only
my word that, in my case, it comes from a more gracious
personal place, and a more curious intellectual place,
besides.

As for the state of flux of the license text, I sense
frustration.  Completely valid frustration.  Frankly, I
share it.  For reasons brought up on the thread Luis split
off, I've come to feel a bit like a ping-pong ball, bouncing
off one stroke of feedback to another, too dizzy to see
where I'm supposed to end up.

As for the "draft" designation, for what it's worth, I used
that term, and adopted that mindset, after reading this bit
of https://opensource.org/approval:

  5. Submit a formal request to license-review. For new
     licenses, this should happen before they are finalized
     to allow for any necessary changes

Before reading that page, it was my impression that I'd have
to submit a "final".  That it would be fixed through
discussion.  That I'd have to withdraw and resubmit if
changes proved necessary.

Your point on reusing past language is also well taken, very
recent EPL-2.0 and BSD+Patents excepted.  As I've mentioned
today and yesterday, I'm near to a clean-slate rewrite of
the proposal that cribs no more than one five-word snippet
on form of source from GPL.  I hope to post that later
today.  I think it will address many concerns, and reflect
the feedback-revision process /approval seems to have in
mind. A crucial process for L0-R, insofar as one of its
objectives was OSI approval, and the path to OSD conformance
wasn't clear from /osd or /licenses.

If the sense of the list is that I should stand on that
revision for a while, perhaps long enough to be reported up
the to board and make its way back down, I'm very open to
that.  Frankly, even if it isn't the sense of the list, I
might do it anyway.  I'm tired, too.

As for adoption, I think we're all aware of its
chicken-and-egg dynamic with OSI approval.  OSI approval
affects my willingness to recommend licenses, to clients and
others.  It has to.  And it affects my willingness to
recommend L0-R, until its fate is clear.  Frankly, I won't
be cajoling anyone, even my friends, to will a demonstrable
licensor-user base into being for license-review.  I don't
think anyone benefits by reinforcing any incentive to do so.
I wonder what other proposed licenses have done.

When dealing with licenses that fall in discouraged
license-proliferation categories, I'm sure it's nice to have
the extra braking power of the approval-adoption loop.  But
when the same puts friction on license forms with new ideas
and objectives---and I think even those who've objected to
L0-R here would grant that it's novel---that strikes me as
malfunction.  At worst, it requires giving a lot of dubious
advice as a rite of passage for each new attempt at a
license exploring new OSD territory.

Finally, perhaps I'm flattering myself, but if L0-R's
concept were redundant of some other license, or technically
boring, or intellectually bloodless, I don't think I'd've
seen the kind of response that I have, on and off the list,
from the folks that I have.  L0-R strikes me as the kind of
idea I'd've been wiling to chime in on myself, out of my own
time, had it fallen upon someone else.  When the next one
falls on someone else, I hope I'm in a position to pay
forward, and help refine it.

-- 
Kyle Mitchell, attorney // Oakland // (510) 712 - 0933