[License-discuss] Fwd: discussion of L-R process [was Re: [License-review] Approval: Server Side Public License, Version 2 (SSPL v2)]

[Luis Villa]

[In the interests of brevity, have been aggressive in cutting and
rearranging both of our quoted emails.]

On Sat, Mar 16, 2019 at 11:32 AM Richard Fontana <
richard.fontana at opensource.org> wrote:

>
> It would be helpful if you could point more specifically to when and
> how the discussion turned into a "screaming match". Maybe my standards
> are too low but it seemed overall relatively civil to me.
>

A quick review suggests that I started ignoring the discussion during the
first submission. I assume that at some point I checked in after work and
parenting to see that the thread was *literally 100 emails*, considered how
negative (and often circular) the earlier parts had been, and said "nope,
life is too short". However, unlikely I can point to a specific email, and
again, life is too short to re-read all 100 of them or the 70+ in the
second thread.

... I am not sure why SSPLv1/SSPLv2 is taken to be the case that points
> particularly to such
> problems, if that's what you and Josh are getting at.


I suspect they're more straw-that-broke-camel than particularly noteworthy
on their own. I'd certainly admit that some of my complaining here is the
cumulative response to 15+ years on this list and increasingly low patience
for it, rather than anything specific to SSPL; I suspect the same is true
for Josh.


> I am more than a little concerned about the possibility ... of stifling
> debate and expression.
>

Debate and expression are only valuable to the extent that they help the
organization meet the organization's goals and movement's needs. My core
claim is that the current quality and nature of discussion don't do that
very well. (Cynics have suggested to me that the actual goal of the
organization is to never approve anything, in which case the list is
functioning well, but I don't think that's true.)

*[snip discussion of GitHub, Bugzilla, and something called Taiga?]*

I obviously agree that using simple tools is better, and barriers to entry
must be kept reasonably low, but email is deceptively simple. It provides
lots of ways to create vast morasses of email ("it is simple - just hit
send!") , and no ways to turn vast morasses of discussion into something
better and more useful. For example, someone complained that Discourse is
not archivable, but even if that were true, I'd rather have a good,
consistent, timely summary of big threads than the actual threads.

As far as barriers to entry, I suggest Discourse in part because the staff
there has done extensive design work to make onboarding easier. Of course
as a new tool some price will be paid, but the current tool also extracts a
price - just from different people.

[Discourse is] definitely worth trying, if someone can put in the time and
> resources to administer


I suggested it in part because administration is quite easy; if hosted by
discourse.org, much less effort than a mailing list or the sad excuse for
the state of the art in wikis :(

But of course using it doesn't solve a problem by itself - someone would
have to figure out how to take advantage of its features to improve the
process. That may be where the PEP suggestion is very complementary, but
I'm not familiar enough with PEPs (I last looked seriously at them
literally 15+ years ago) to be able to suggest that myself.

I've ...become generally skeptical that new tools will solve what are
> fundamentally social or political problems.
>

We don't disagree. Consider this technical proposal an attempt to alleviate
some symptoms of the deeper socio-political problems, not solve the deeper
causes.

To elaborate a bit: as McCoy correctly pointed out, this discussion has
historically conflated at least: (1) who participates; (2) how they
participate; (3) how proposers respond to #2, and (4) if the submitter
survives the obstacle course, how the board extracts meaning from the
discussion in order to make a decision. I think a process that includes a
regularly updated doc (could be the Discourse integrated wiki, could be
externally maintained as in a PEP, doesn't really matter) at least
minimally addresses (2), (3), and (4) by providing everyone with something
more actionable and decision-oriented than a meandering email thread. And
one can have the vain hope that a more legible, understandable process and
outcomes will, in the long run, also impact #1.

> I'd happily submit the Blue Oak Model permissive license as an initial
> guinea pig for such a process[2],
>
> I agree with Bruce here. What would it prove? Blue Oak is, as to its
> content, both extremely simple and extremely non-controversial.
>

Any new system needs debugging, and typically one starts debugging by
seeing how a system responds to simple inputs. Jumping directly to
something complex like CAL will inevitably confuse "reviewing CAL is hard,
regardless of tool or system" with "we're all learning our way around [new
system]". But if folks want to do this the hard way by all means! :)

Another way to attack this is with slightly more battle-tested processes;
if that's something PEP-like, great! Not sure it exactly fits the use case
but then again neither does Discourse so <shrug>.

Luis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20190318/b787bdb1/attachment-0001.html>