[License-discuss] May 2019 Summary

[Lukas Atkinson]

In May, the License-Discuss mailing list talked about:

   - relationship between the License-Review mailing list and the License
   Committee
   - evolution of the license review process
   - comprehensiveness of the approved license list
   - licenses of licenses
   - would three licenses be enough?
   - email threading

This summary can also be read online at
https://opensource.org/LicenseDiscuss052019

The corresponding License-Review summary is online at
https://opensource.org/LicenseReview052019 and covers extensive debate on
the Cryptographic Autonomy License, as well as discussion on a BSD license
variant.

*License-Review / Committee Relationship*

In the review of the CAL, a minor point was whether the review of the
License Zero should be characterized as a “rejection”.

Luis Villa talks about the history of the License-Review list, that the
list at times *was* an OSI committee, but that any decision making
authority lies solely on the OSI board.

Richard Fontana feels that community engagement in the list has declined,
making it more difficult for OSI to argue that review decisions reflect
community consensus.

Luis Villa isn’t sure that engagement has gone down, but thinks the level
of engagement is definitely unhealthy – 100+ email threads chase away
potential submitters.

Henrik Ingo likens list participation to jury duty. Ingo also points out
that there is no need to chime in to repeat a consensus opinion.

Christopher Sean Morrison agrees with Ingo’s point that mailing lists
dictate “efficient silence”, without a mechanism to silently signal
agreement. But engagement also suffers from “rehashed-topic fatigue”.

Pamela Chestek sees some bullies on the list. Someone may stay silent not
out of agreement, but to avoid conflict.

Nigel Tzeng suggests anonymous voting by OSI members. (Note: but that
doesn’t help with discussions.) Fontana thinks that would be ripe for
abuse. Tzeng thinks the current system can also be abused, presumably
referencing the NOSA review.

Scott Peterson argues against maximally precise rules, both regarding the
review process and possible OSD amendments.

McCoy Smith views the board elections as a kind of indirect vote. Henrik
Ingo warns that direct democracy can distort a vote. The OSI board must
make decisions on their own responsibility.

*Evolving the License Review Process*

Pamela Chestek announces the new OSI License Review Committee, consisting
of Pamela Chestek (chair), Elana Hashman, Chris Lamb, and Simon Phipps.
They recognize the need for improvement of the review process, so that all
points of view are represented in the discussion. As a first step, they
clarify:

   -

   License-Review list collects feedback from the public about proposed
   licenses. The Comittee considers these responses when making their approval
   recommendation to the OSI board. If a license is not yet ready, a moderator
   can move discussion to License-Discuss.
   -

   License-Discuss is for general questions about open source licenses, and
   for licenses in their early stages of development. It is recommended to
   develop new licenses in the open, and to regularly seek feedback from
   License-Discuss.
   -

   There will be an effort towards better moderation, to ensure appropriate
   conversation and a good pace of discussion, and to encourage wider
   participation. This includes rules to limit hostility, frequency, and
   repetitiveness of messages, includes follow-ups from moderators to
   unanswered questions, and includes enforcement of the existing Code of
   Conduct.
   -

   The website now clarifies the license review process: community
   consensus is no longer a precondition. Instead, the board takes the
   community discussion into account for its decision.

Simon Phipps clarifies that Chestek’s announcement represents the decision
of the OSI board.

Bruce Perens perceives this change as directed squarely against him. “I,
and others, have today been ejected from the license committee.” (Note:
this assumes the view that the list members *are* the committee.) Perens
does not think the mere number of messages would be a problem – they are
necessary to clarify important questions. Perens doesn’t see the point in
accommodating people who don’t (yet) participate on the list.

Chestek disagrees with the characterization that anyone would have been
ejected – instead, these changes have the goal of inviting more diverse
responses than is currently the case. Chestek points to concrete examples
how Peren’s messages come across as agressive: “this is a tone and style of
engagement that is inappropriate.” Perens feels this rejects his viewpoint
without appropriate concern.

Russel McOrmond lauds Perens for being a persistent advocate of software
freedom, and urges him to not take push-back personally.

Lawrence Rosen appreciates the clarity of the new process, but thinks there
is too much focus on strict codes of conduct. Just delete the emails you
don’t want. Rosen is also surprised to recently learn that Perens
represented the OSI in their open standards activities (Perens responds).
It is important that it’s clear within discussions who speaks for OSI and
who doesn’t. Rick Moen concurs, and urges everyone to assume good faith.
Moen also makes a distinction between different kinds of mailing list
moderation. In a certain sense, the OSI lists are unmoderated.

Perens responds to Rosen’s aside about standards engagement. Perens also
thinks any accusations of bullying are over the top, and that these changes
to the list are just tone policing. Perens cautions that “license
submitters will tell the story as it is most advantageous to them”,
especially if they are lawyers. It’s important to be able to call that out
when it happens. John Cowan thinks Peren’s point about lawyers is
counterfactual. There’s a difference between rethoric and outright
misrepresentation.

Chestek agrees with Rosen that all opinions should be heard, but these
can’t be expressed in any way you want. A “deal with it” attitude alienates
valuable voices. In contrast: “I’ve never heard of a forum where people
won’t participate because it’s too polite”. Rosen thinks some blustering is
normal for lawyers, and that politeness is not generally necessary: “That
is boring. We are adults here.”

James thinks moderation should only be done as last resort and as
transparently as possible because it can have chilling effects. John Cowan
recalls moderation activity on Fidonet: moderation isn’t as large a problem
as it might seem, and bans were well-deserved.

Fontana appreciates the improved clarity brought through Chestek’s changes.
The (purely advisory) role of the License-Review list is a major change of
how the process is described, but it reflects the actual process more
accurately.

McOrmond thinks the line between passion and rudeness is too subjective to
be useful. Strict focus on a CoC would exclude passionate people. Some
amount of shared views are necessary in a community. Rick Moen counters:
it’s perfectly possible to find some common ground and cooperate with
people whose views clash. The OSI list “is a natural place for people
supportive of OSI’s real-world objective.”

There is a bit of a side discussion about threats to and core issues of
FOSS by McOrmond (Affero etc is a threat), Perens (Affero is fine), Simon
Phipps (the rules serve the movement), and Moen (software freedom is a
shared value).

Martijn Verburg chimes in with an assessment that OSI’s list are more
“robust” than others. “An attempt to make both lists more welcome to voices
[…] can’t do any harm.”

Moen suggests a conspiracy theory: that these claims of uncivility arose
after the OSI didn’t approve certain licenses. Are sinister forces trying
to silence effective critics? Would those more diverse views not be more
sympathetic to such rejected licenses? (Note: it’s impossible to tell to
which degree this is joking.) Chestek responds: “I understand that people
on this list may be skeptical of my commitment to software freedom and/or
open source software”. But the Committee and the Board are more than a
single person. “I do hope that simply having a different opinion on the
meaning of software freedom at the fringes doesn’t mean that one has become
captive of anti-freedom forces.” The OSI is working on important problems,
such as the function of the lists, the quality of the review process, and
the exact scope of open source.

Henrik Ingo writes a detailed response to various points.

   - the review process hinges on the few who can actually dissect the
   licenses and read all the emails
   - the list seems comparatively disciplined, aside from discussions that
   rehash long-past reviews
   - the SSPL review saw an influx of new participants. Where there were
   problems, the list self-regulated
   - that a new board points to the existing CoC shouldn’t be news
   - it is more concerning “that the board believes there is an actual
   issue that needs fixing”
   - some of the “concerns” on the list are just lawyerly bickering or
   lobbying to change OSI policy
   - in many of the mentioned cases, the reasons for non-approval are
   perfectly clear and don’t have to be relitigated constantly
   - OSI review is not a court, no cases are lost – revised licenses could
   be approved
   - review is not just about checking whether the OSD applies, but also
   about how the new license serves the community
   - it is not sufficient that a license does no harm
   - license review is a lot like “code review”, in the sense that there is
   a kind of shared ownership
   - whereas the FSF’s Four Freedoms have significant backing material and
   discussion, the OSD seems so unanimous and obvious that no comparable body
   of commentary exists
   - maybe that is a problem, and more commentary would help?
   - the process seems to be working better than ever, so why fix it?

Richard Fontana thinks the review process is perceived as unpredictable
because few licenses make it to a board vote. Those that do tend to be
obvious cases and don’t need a rationale. Most problematic licenses are
retracted by the submitter due to community feedback. Fontana also thinks
the OSI has a problem dealing with mistakes, such as approved licenses that
are not open source under current understanding. A de-listing procedure
might be necessary.

Henrik Ingo thinks outright de-listing would be problematic. As a first
step the license stewards could be asked for voluntary retirement of the
licenses. Otherwise, they could be moved to a “not recommended” category
that recognizes that they were used in good faith.

Nigel Tzeng thinks de-listing licenses would be problematic because they
would likely target special-purpose licenses. Tzeng is particularly
concerned about the (lack of) acceptance of Government Open Source (GOSS)
licenses. (Note: due to overwhelming volume and limited novelty, this
summary will not cover the ensuing discussion about GOSS.) Regarding
possible delisting, Perens states that it is not OSI policy to promote some
licenses over others, beyond marking some as “legacy”. Even though in
practice, three licenses would be enough (see separate section).

Tzeng doesn’t think his perception that the lists are dominated by Perens
and Fontana should be treated as an ad-hominem attack. Perens responds that
having an assertive personality paired with relevant expertise should be
fine Rosen disagrees most harshly, Perens wonders how *that* response can
be anything but ad-hominem. Henrik Ingo expresses the meritocratic view
that Peren’s and Fontana’s influence is mostly a consequence of all the
time they spend reviewing licenses.

Luis Villa thinks Chestek’s clarifications are fantastic, but is concerned
that the meaning of “software freedom” is still unclear in an OSI context.
Villa notes that while these improvements target the *decision-making*
process, improvements might also be needed for the *record-keeping*
process. The list archives are an unsuitable medium, instead authoritative
summaries are needed. Villa provides some links on RFC-like processes. This
seems similar to the March 2019 discussion whether a PEP-style process
would help.

*Comprehensiveness of the Approved License List*

Luis Villa argues that the list of OSI-approved licenses isn’t a
comprehensive list of usable open source licenses. It should therefore be
avoided in contracts or license clauses. But if not that, what is the
purpose of the list? Would it make sense to create a smaller list of useful
licenses? Villa points to his Blue Oak project as a list of useful
permissive licenses.

Richard Fontana thinks the approval process is more important than the
resulting list. In a way, the licenses are just a medium through which
“open source” is clarified. Fontana also warns against relying on
self-appointed authorities, and notes that OSI’s License-Review is more
transparent than alternatives.

Ben Hilburn thinks this discussion is important, but finds Fontana’s
standpoint confusing. Whether a license is “open source” is defined by its
OSI approval. Otherwise, how could OSI be an arbiter of that term?

Nicholas Weinstock insists that the OSD and not the review process is the
definition of open source. It follows that the OSD is not just a bunch of
factors to consider during review. It also follows that licenses can be
open source without being OSI-approved. Too much focus on the list of
currently approved license would also result in a weird status for legacy
licenses that have since been removed from the list.

Van Lindberg likens OSI approval to a product certification. It doesn’t
matter whether something is potentially approvable, only whether it has
been approved. In the end, it must be OSI’s call to decide whether a
license satisfies the OSD. In contrast, the term “Free Software” could be
used more freely. Nicholas Weinstock disagrees with Lindberg’s comparison:
OSI approval is not a completely neutral review, but takes wider concerns
into account.

Lindberg argues that only OSI-approved parts of a Linux distro should be
called “open source”. There needs to be *some* definition of that term, and
clearly it is for the OSI to decide what it means.

McCoy Smith links to OSI’s deprecation/retirement category (
https://opensource.org/licenses/category) which “should not be used to
license any new code.” Lindberg claims that it is not clear whether such
licenses still are open source. Lindberg suggests a cut-off date.

John Cowan argues that “law is whatever the judge says”, here: open source
is whatever the OSI says. It is then perfectly fine to refer to the list of
OSI-approved licenses. It is just that this view provides no guidance for
OSI’s review process. This approach works fine as long as OSI’s decisions
do not deviate too far from community expectations.

Stephen Paul Weber occasionally sees such “any OSI-approved license” terms
in contests or in aggregators. Sometimes, any OSI- or FSF-approved license
is allowed, to avoid choosing “sides”. Fontana thinks that approach is
clever: both OSI and FSF are respected neutral authorities, unlike
e.g. Blue Oak or Fedora. As a historical point, Fontana remembers that
Fedora did not rely on the OSI license list because OSI was then seen as
too commercially influenced. Nowadays, OSI criticism seems to be the
opposite. Henrik Ingo thinks the OSI is now much more important than back
then, because Linux distros no longer have the role of kingmakers: whether
the software is packaged for Debian or Fedora is no longer crucial for an
open source project.

Ingo doesn’t think the OSI license list should even try to be
comprehensive. Most open source software is covered by a handfull of
licenses, but there is a long tail of presumably-compliant licenses. Those
can be approved when they are submitted, but there’s no need to actively
seek them out. Fontana does see some value in mass legacy approval:
licenses without OSI approval are common in Linux packages. Approval would
defuse the claim that these weren’t open source. Ingo thinks distros have
different motivations than the OSI. For example, the OSI did not approve
the libpng license – but Linux distros will continue to ship it.

*CC0 and Patents*

Weinstock had mentioned the failure to approve CC0 even though it was
OSD-compliant. Fontana interjects here: there are grave concerns because it
explicitly does not license patents. Nigel Tzeng retells the history of
2012 CC0 review, claiming that it was not as simple as Fontana purports.
The CC0 is now a widely used open source license, despite not being
OSI-approved. In contrast, Henrik Ingo and Rick Moen recall that Fontana’s
concerns were a quickly growing consensus. Fontana goes into more depth
about his motivations at the time. The CC0 review helped build an
understanding of the issues around patents in open source.

Christopher Sean Morrison thinks the problem is that the OSI has no clear
policy on the role of patents. If patents are involved, a licenses that
excludes them arguably violates OSD 7. But without patents, such a license
would be still OSD-compliant. (Note: but compare also Fontana’s message
referenced above.)

With regard to the role of patents, Rick Moen argues that having an open
source license is a necessary but not sufficient precondition for a
software actually being open source. As a hypothetical, Moen considers a
jurisdiction that somehow encumbers a BSD-licensed software.

John Cowan disagrees with the premise of Moen’s hypotheticals. The biggest
patent threat to open source software is not from authors but from third
parties. It isn’t possible to conclusively determine whether some software
is safely open-source. Rick Moen doesn’t think that stance is workable.
Open source software should be called open source, until the day that the
software is encumbered by a concrete threat.

Nicholas Weinstock agrees with Cowan’s analysis. But it would be useful to
discuss open sourceness of licenses separately from the licensed programs.
The OSD does not make such a distinction consistently.

Van Lindberg argues that open source only describes the licensor–recipient
relationship. Third parties are out of scope, and no warranties about this
are given by the license. Moen agrees, but this doesn’t change the issue
that software cannot be distributed freely if there are claims against it
by a third party.

Lawrence Rosen notes that some licenses have defensive termination clauses
that may be a sufficient defense against third party patent threats. (Note:
Apache 2 and GPLv3 have such clauses.) Bruce Perens is concerned that such
clauses could be ineffective if a company moves the patents to a separate
entity.

The GPLv2 includes a “freedom or death” clause that can prohibit
distribution in certain jurisdictions. Fontana is of the opinion that
software ceases to be open source if this clause is invoked.

As an aside about the BSD, Lawrence Rosen suggests it’s the OSI’s
responsibility to warn the public that BSD is not a useful license due to
its lack of a patent license – “Use a professional license instead!”
Morrison thinks that is baseless fear-mongering. Has this risk actually
been tested? McCoy Smith doesn’t recall caselaw, but links to academic
literature.

*License Licenses*

Patrick Masson wants to update the OSI license list to include metadata
about the license, such as the license of the license text.

Thorsten Glaser provides metadata for his MirBSD license, but notes that no
license for it’s text has been adapted.

John Cowan links to/extracts the relevant licensing information from GPL,
EPL, Apache 2, MPL 2, CDDL and points out that MIT/BSD are freely modified
in practice. Lawrence Rosen extracts the relevant paragraph from the OSL.

Richard Fontana cautions that the license submitter and the copyright
holder can be distinct, and that noting a copyright holder is not always
useful. E.g. the MIT license has no copyright owner, no license steward,
and isn’t even affiliated with the MIT. (McCoy Smith links to some MIT
archeology <https://opensource.com/article/19/4/history-mit-license>). It
is also questionable whether licenses are copyrighted in general. (Perens
concurs). In contrast, Pamela Chestek provides precedent in favour of
copyrightability for legal documents. “To those of us who write them, they
are as creative as code.”

*Three Licenses*

How many licenses does one actually need?

Bruce Perens Bruce Perens suggests that three licenses should be enough for
anyone: AGPLv3, LGPLv3, and Apache 2. They are mutually compatible, OSI and
FSF approved, have explicit patent terms, and cover a wide range of license
goals from permissive to network-copyleft. Why not guide people towards
this “strategically coherent” set?

John Cowan answers: because that would look like ASF/FSF favoritism.

Brian Behlendorf agrees that dealing with dozens of subtly different
licenses is tiring. But OSI’s legitimacy derives from its principles.
Favoring some licenses (and neglecting others) would call that legitimacy
into question. But it would be fine to educate potential licensors about
license features, and encourage them to stick to the more common set.

Rosen’s mention of the OSL elsewhere prompts John Cowan to announce his
dislike of the license: it establishes a separate incompatible copyleft
ecosystem or commons from the GPLv2 and GPLv3 ecosystems that already exist.

Rosen disagrees. Copyleft licenses are generally compatible regarding
aggregations or collective works, and incompatible regarding joint or
derivative works. But that isn’t a problem because joint derivative works
are rare in practice. The GPL/AGPL group is the odd one because the FSF
interprets them to apply to static linking and other interactions. That is
a problem with the FSF interpretation, not with copyright law.

Thorsten Glaser accuses Rosen of promoting an agenda here, and that the
GPLv2/GPLv3 ecosystems are much more important in practice than the
EPL/MPL/OSL ecosystem.

*Topicality and Email Threading*

Kevin Fleming is frustrated that discussion threads are often derailed by
tangential discussions. Such discussions should be split off into a
separate topic, so that other people don’t have to wade through off topic
discussion to find the relevant parts. Discourse allows messages to be
moved to new topics after the fact.

John Cowan thinks that threading mail readers help, but that some amount of
topic intermingling is unavoidable in any medium. Rick Moen shares the
sentiment that threading is easy. “The above is internet 101 […] dont’t
blame the tool when the user cannot be bothered”. Regarding Discourse, it
doesn’t show any threading within a topic.

Luis Villa sees these OSI mailing lists as a disproportionally
email-entrenched group. And even here, threading does not work in practice
– hardly a case of Internet 101. This is dysfunctional. Having to master
advanced email techniques seems like an unnecessary barrier to entry.
Thankfully, other software does not blame the user – Discourse tries “to
reach users where they actually read and write”. Moen responds.

*Other discussions*

Nigel Tzeng feels that the License-Review list was much more diverse in
earlier times (2012), but is now dominated by Richard Fontana and Bruce
Perens. Even though everyone is acting in good faith, this hurts engagement
on the list. Bruce Perens notes he had been absent from the list for many
years, only participating again since mid 2018. Were things really so
different back in 2012? In the archives, Perens mostly finds the same
posters as today.

*Help Wanted!*

Our current editor of the monthly License-Discuss and License-Review
reports, Lukas Atkinson, will not be available to continue in June and
July, and may have limited availability throughout the rest of the year. If
you would like to join the OSI as list editor, or know someone who might,
please contact OSI General Manager Patrick Masson <masson at opensource.org>.
The list editor works on a freelance basis to provide monthly summaries of
the License-Review and License-Discuss mailing lists.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20190604/28ad92be/attachment-0001.html>