[License-discuss] How can we as a community help empower authors outside license agreements?

[Tobie Langel]

On Wed, Mar 18, 2020 at 3:32 PM Gil Yehuda via License-discuss <
license-discuss at lists.opensource.org> wrote:

> I don't understand the point that you are trying to make in your recent
> posts (about how the OSI election works and how the "winner takes" model is
> not representative of voter sentiment). Let me explain where my confusion
> about your message is centered:
>

Yeah, I wasn't clear enough, sorry. I believe the OSI should seek to be
broadly representative of the overall open source community and the broader
population which is affected by open source. With a voting membership that
is in the hundreds, I don't think it makes any sense to have elections when
your broader community is in the millions for open source practitioners and
the billions for impacted people. Hence I believe the existing OSI board
should proactively seek additional board members that are representative of
these different constituencies to join the board (and/or the affiliate
program when such constituencies are also represented by organizations) and
operate using a consensus-driven decision-making process (rather than
voting) and a set of guidelines (like W3C's priority of constituencies, for
example).

There is absolutely nothing revolutionary about this model. It's been used
by organizations such as W3C for decades, works rather well, and accounts
for constituencies that wouldn't be cared for at all in a winner takes-all
election model, even if the whole community was voting. For example,
accessibility concerns on the Web wouldn't ever have been considered if
decisions were made strictly on who holds the majority.

Coraline has said many times that she seeks to change the OSD (specifically
> the part related to "fields of endeavor"). She also requested that OSI change
> the manner in which changes are made to the OSD (asking the OSI to create "a
> public, representative, and diverse working group to establish a mechanism
> for reviewing and potentially revising the OSD").
>
> Changing the change-process clearly helps achieve her goal of changing the
> OSD because the current process and voting outcomes don't look as
> promising. Getting different people to decide these things (via
> appointment, not vote) should yield different results. I get the
> motivation, although I'm not convinced at its merit, I'm not confused about
> the suggestion.
>
> Where I'm unclear: based on your discussion of voter-sentiment and
> percentage-adding I'm trying to understand if you suggest that the
> decisions of such a working group should not employ a majority-rule
> process, as via that process, a minority view would not succeed at making
> the decision. In other words, are you suggesting a method in which
> multiple versions of a minority position can be added together in a manner
> that overrules a majority position? I'm asking because I really want to
> understand what processes you are recommending OSI use that you believe
> would result in the outcomes you are looking for.
>

So to clarify, I think that looking at this whole thing from the
perspective of minority or majority of OSI members is irrelevant.

The group tasked with driving this effort forward (should such a group be
formed) should do a good faith effort to look at:

- open source practitioners and users of the software, including
individuals, non-profits, governments, educational, corporations, etc.,
- impact on end users and the population at large,
- effectiveness of such measures,
- risk and cost of such measures (including compliance and compat issues),
- relevance to mission and goals of the OSI as stated in its bylaws,
- overall community sentiment,
- historical precedent,
- legal constraints,
- cross-jurisdictional issues,
- etc.

and move towards a consensus-driven decision (or suggestion to the board)
based on this information.

This should not be a confrontation between rival factions but a
consensus-driven process to move to a solution that best reflects and
balances all of the different interests of the community and those impacted
by the software we build.

I hope this helps.

--tobie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20200318/a66c4a8d/attachment.html>