<div dir="ltr"><p></p>
<p>In May, the License-Discuss mailing list talked about:</p>
<ul><li>relationship between the License-Review mailing list and the License Committee</li><li>evolution of the license review process</li><li>comprehensiveness of the approved license list</li><li>licenses of licenses</li><li>would three licenses be enough?</li><li>email threading</li></ul>
<p>This summary can also be read online at <a class="gmail-uri" href="https://opensource.org/LicenseDiscuss052019">https://opensource.org/LicenseDiscuss052019</a></p>

<p>The corresponding License-Review summary is online at <a class="gmail-uri" href="https://opensource.org/LicenseReview052019">https://opensource.org/LicenseReview052019</a> and covers extensive debate on the Cryptographic Autonomy License, as well as discussion on a BSD license variant.</p>
<p><b id="gmail-decision">License-Review / Committee Relationship</b></p>
<p>In the review of the CAL, a minor point was whether the review of the License Zero should be characterized as a “rejection”.</p>
<p>Luis Villa talks about the history of the License-Review list, that the list at times <em>was</em> an OSI committee, but that any decision making authority lies solely on the OSI board.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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”.</p>
<p>Pamela Chestek sees some bullies on the list. Someone may stay silent not out of agreement, but to avoid conflict.</p>
<p>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.</p>
<p>Scott Peterson argues against maximally precise rules, both regarding the review process and possible OSD amendments.</p>
<p>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.</p>
<p><b id="evolve">Evolving the License Review Process</b></p>
<p>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:</p>
<ul><li><p>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.</p></li><li><p>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.</p></li><li><p>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.</p></li><li><p>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.</p></li></ul>
<p>Simon Phipps clarifies that Chestek’s announcement represents the decision of the OSI board.</p>
<p>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 <em>are</em> 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.</p>
<p>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.</p>
<p>Russel McOrmond lauds Perens for being a persistent advocate of 
software freedom, and urges him to not take push-back personally.</p>
<p>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.</p>
<p>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.</p>
<p>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.”</p>
<p>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.</p>
<p>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.</p>
<p>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.”</p>
<p>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).</p>
<p>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.”</p>
<p>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.</p>
<p>Henrik Ingo writes a detailed response to various points.</p>
<ul><li>the review process hinges on the few who can actually dissect the licenses and read all the emails</li><li>the list seems comparatively disciplined, aside from discussions that rehash long-past reviews</li><li>the SSPL review saw an influx of new participants. Where there were problems, the list self-regulated</li><li>that a new board points to the existing CoC shouldn’t be news</li><li>it is more concerning “that the board believes there is an actual issue that needs fixing”</li><li>some of the “concerns” on the list are just lawyerly bickering or lobbying to change OSI policy</li><li>in many of the mentioned cases, the reasons for non-approval are perfectly clear and don’t have to be relitigated constantly</li><li>OSI review is not a court, no cases are lost – revised licenses could be approved</li><li>review is not just about checking whether the OSD applies, but also about how the new license serves the community</li><li>it is not sufficient that a license does no harm</li><li>license review is a lot like “code review”, in the sense that there is a kind of shared ownership</li><li>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</li><li>maybe that is a problem, and more commentary would help?</li><li>the process seems to be working better than ever, so why fix it?</li></ul>
<p>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.</p>
<p>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.</p>
<p>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).</p>
<p>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 <em>that</em> 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.</p>
<p>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 <em>decision-making</em> process, improvements might also be needed for the <em>record-keeping</em>
 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.</p>
<p><b id="gmail-comprehensiveness">Comprehensiveness of the Approved License List</b></p>
<p>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.</p>
<p>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.</p>
<p>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?</p>
<p>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.</p>
<p>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.</p>
<p>Lindberg argues that only OSI-approved parts of a Linux distro should be called “open source”. There needs to be <em>some</em> definition of that term, and clearly it is for the OSI to decide what it means.</p>
<p>McCoy Smith links to OSI’s deprecation/retirement category (<a class="gmail-uri" href="https://opensource.org/licenses/category">https://opensource.org/licenses/category</a>)
 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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p><b id="gmail-cc0">CC0 and Patents</b></p>
<p>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.</p>
<p>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.)</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p><b id="gmail-license-licenses">License Licenses</b></p>
<p>Patrick Masson wants to update the OSI license list to include 
metadata about the license, such as the license of the license text.</p>
<p>Thorsten Glaser provides metadata for his MirBSD license, but notes that no license for it’s text has been adapted.</p>
<p>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.</p>
<p>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 <a href="https://opensource.com/article/19/4/history-mit-license">MIT archeology</a>).
 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.”</p>
<p><b id="gmail-three">Three Licenses</b></p>
<p>How many licenses does one actually need?</p>
<p>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?</p>
<p>John Cowan answers: because that would look like ASF/FSF favoritism.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p><b id="gmail-topicality">Topicality and Email Threading</b></p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p><b id="gmail-other">Other discussions</b></p>
<p>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.</p>
<p><b id="gmail-help">Help Wanted!</b></p>
<p>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 <a href="mailto:masson@opensource.org">OSI General Manager Patrick Masson</a>.
 The list editor works on a freelance basis to provide monthly summaries
 of the License-Review and License-Discuss mailing lists.</p>

</div>