May 2019 License-Discuss Summary
In May, the License-Discuss mailing list talked about:
* relationship between the License-Review mailing list and the License Comittee
* evolution of the license review process
* comprehensiveness of the approved license list
* licenses of licenses
* would three licenses be enough?
* email threading
The corresponding License-Review summary is online
at
and covers extensive debate on the Cryptographic Autonomy License,
as well as discussion on a BSD license variant.
## License-Review / Committee Relationship {#decision}
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][villa:rel:history]
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][fontana:rel:community]
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][villa:rel:engagement]
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][ingo:rel:jury] 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][morrison:rel:fatigue]
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][chestek:rel:silence]
sees some bullies on the list.
Someone may stay silent not out of agreement,
but to avoid conflict.
[Nigel Tzeng][tzeng:rel:voting] suggests anonymous voting by OSI members.
(Note: but that doesn’t help with discussions.)
[Fontana][fontana:rel:voting] thinks that would be ripe for abuse.
[Tzeng][tzeng:rel:abuse] thinks the current system can also be abused,
presumably referencing the NOSA review.
[Scott Peterson][peterson:rel:precise]
argues against maximally precise rules,
both regarding the review process and possible OSD amendments.
[McCoy Smith][smith:rel:elections]
views the board elections as a kind of indirect vote.
[Henrik Ingo][ingo:rel:direct]
warns that direct democracy can distort a vote.
The OSI board must make decisions on their own responsibility.
[villa:rel:history]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020418.html
[fontana:rel:community]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020422.html
[villa:rel:engagement]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020424.html
[ingo:rel:jury]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020427.html
[morrison:rel:fatigue]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020429.html
[chestek:rel:silence]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020430.html
[tzeng:rel:voting]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020431.html
[fontana:rel:voting]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020433.html
[peterson:rel:precise]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020435.html
[tzeng:rel:abuse]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020449.html
[smith:rel:elections]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020438.html
[ingo:rel:direct]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020451.html
## Evolving the License Review Process {#evolve}
[Pamela Chestek][chestek:evolve:ann]
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][phipps:evolve:authority]
clarifies that Chestek’s announcement
represents the decision of the OSI board.
[Bruce Perens][perens:evolve:adhom]
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][chestek:evolve:eject]
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][perens:evolve:reject] feels this rejects his viewpoint without appropriate concern.
[Russel McOrmond][mcormond:evolve:freeperens]
lauds Perens for being a persistent advocate of software freedom,
and urges him to not take push-back personally.
[Lawrence Rosen][rosen:evolve:freespeech]
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][perens:evolve:picknick] responds).
It is important that it’s clear within discussions who speaks for OSI and who doesn’t.
[Rick Moen][moen:evolve:goodfaith]
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][perens:evolve:picknick] 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][cowan:evolve:lawyers]
thinks Peren’s point about lawyers is counterfactual.
There’s a difference between rethoric and outright misrepresentation.
[Chestek][chestek:evolve:allvoices]
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][rosen:evolve:bluster]
thinks some blustering is normal for lawyers,
and that politeness is not generally necessary:
“That is boring. We are adults here.”
[James][james:evolve:chilling]
thinks moderation should only be done as last resort and as transparently as possible
because it can have chilling effects.
[John Cowan][cowan:evolve:fido]
recalls moderation activity on Fidonet:
moderation isn’t as large a problem as it might seem,
and bans were well-deserved.
[Fontana][fontana:evolve:clarity]
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][mcormond:evolve:passion]
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][moen:evolve:commonground]
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 [[1][mcormond:evolve:threats],[2][mcormond:evolve:labels]]
(Affero etc is a threat),
[Perens][perens:evolve:affero] (Affero is fine),
[Simon Phipps][phipps:evolve:serve] (the rules serve the movement),
and [Moen][moen:evolve:shared] (software freedom is a shared value).
[Martijn Verburg][verburg:evolve:robust]
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][moen:evolve:conspiracy]
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][chestek:evolve:conspiracy] 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][ingo:evolve:essay]
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][fontana:evolve:predictability]
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][ingo:evolve:delist]
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][tzeng:evolve:delist]
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][perens:evolve:delist]
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][tzeng:evolve:delist]
doesn’t think his perception that the lists are dominated by Perens and Fontana
should be treated as an ad-hominem attack.
[Perens][perens:evolve:delist]
responds that having an assertive personality paired with relevant expertise should be fine
Rosen [[1][rosen:evolve:trained],[2][rosen:evolve:sorrynotsorry]] disagrees most harshly,
[Perens][perens:evolve:adhominem] wonders how *that* response can be anything but ad-hominem.
[Henrik Ingo][ingo:evolve:merit] 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][villa:evolve:freedom]
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][LD04-pep].
[LD04-pep]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020528.html
[chestek:evolve:ann]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020483.html
[perens:evolve:adhom]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020484.html
[chestek:evolve:eject]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020485.html
[perens:evolve:reject]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020495.html
[mcormond:evolve:freeperens]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020487.html
[rosen:evolve:freespeech]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020488.html
[moen:evolve:goodfaith]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020489.html
[chestek:evolve:allvoices]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020491.html
[james:evolve:chilling]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020492.html
[cowan:evolve:fido]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020497.html
[rosen:evolve:bluster]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020494.html
[mcormond:evolve:passion]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020496.html
[moen:evolve:commonground]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020500.html
[mcormond:evolve:threats]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020503.html
[perens:evolve:affero]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020504.html
[phipps:evolve:serve]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020505.html
[moen:evolve:shared]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020507.html
[mcormond:evolve:labels]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020509.html
[verburg:evolve:robust]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020498.html
[phipps:evolve:authority]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020501.html
[moen:evolve:conspiracy]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020506.html
[chestek:evolve:conspiracy]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020508.html
[fontana:evolve:predictability]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020510.html
[ingo:evolve:delist]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020512.html
[ingo:evolve:essay]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020511.html
[perens:evolve:picknick]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020493.html
[cowan:evolve:lawyers]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020499.html
[tzeng:evolve:delist]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020513.html
[perens:evolve:delist]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020514.html
[rosen:evolve:trained]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020515.html
[ingo:evolve:merit]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020517.html
[fontana:evolve:clarity]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020486.html
[rosen:evolve:sorrynotsorry]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020523.html
[perens:evolve:adhominem]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020525.html
[villa:evolve:freedom]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020581.html
## Comprehensiveness of the Approved License List {#comprehensiveness}
[Luis Villa][villa:comp:useful]
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][fontana:comp:process]
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 [[1][hilburn:comp:define],[2][hilburn:comp:define2]]
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][weinstock:comp:osd]
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][vanl:comp:certification]
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][weinstock:comp:certification]
disagrees with Lindberg’s comparison:
OSI approval is not a completely neutral review,
but takes wider concerns into account.
[Lindberg][vanl:comp:define]
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 [[1][smith:comp:deprecation],[2][smith:comp:deprecation2]]
links to OSI’s deprecation/retirement category (
which “should not be used to license any new code.”
Lindberg [[1][vanl:comp:deprecation],[2][vanl:comp:deprecation2]]
claims that it is not clear whether such licenses still are open source.
Lindberg suggests a cut-off date.
[John Cowan][cowan:comp:judge]
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][weber:comp:aggregator]
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][fontana:comp:choosing] 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][ingo:comp:kingmaker]
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][ingo:comp:kingmaker]
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][fontana:comp:masslegacy] 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][ingo:comp:distromotivation]
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 {#cc0}
[Weinstock][weinstock:comp:certification]
had mentioned the failure to approve CC0 even though it was OSD-compliant.
[Fontana][fontana:comp:cc0] interjects here:
there are grave concerns because it explicitly does not license patents.
Nigel Tzeng [[1][tzeng:comp:cc0],[2][tzeng:comp:cc0-relevance]]
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][ingo:comp:cc0] and [Rick Moen][moen:comp:cc0] recall
that Fontana’s concerns were a quickly growing consensus.
[Fontana][fontana:comp:cc0-recollections]
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][morrison:comp:patents]
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][fontana:comp:cc0-recollections] message referenced above.)
With regard to the role of patents,
Rick Moen [[1][moen:comp:cc0],[2][moen:comp:bsd],[3][moen:comp:bsd2]]
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 [[1][cowan:comp:allpatents],[2][cowan:comp:otherpatents]]
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][moen:comp:conclusively] 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][weinstock:comp:separate]
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][vanl:comp:relationship]
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][moen:comp:anyway] 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][rosen:comp:defensive]
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][perens:comp:entity] 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][fontana:comp:gplcease] is of the opinion that
software ceases to be open source if this clause is invoked.
As an aside about the BSD, [Lawrence Rosen][rosen:comp:bsd] 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][morrison:comp:fearmongering]
thinks that is baseless fear-mongering. Has this risk actually been tested?
[McCoy Smith][smith:comp:tested] doesn’t recall caselaw,
but links to academic literature.
[villa:comp:useful]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020423.html
[fontana:comp:process]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020425.html
[hilburn:comp:define]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020434.html
[hilburn:comp:define2]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020436.html
[weinstock:comp:osd]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020442.html
[vanl:comp:certification]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020443.html
[smith:comp:deprecation]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020444.html
[smith:comp:deprecation2]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020446.html
[vanl:comp:deprecation]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020445.html
[vanl:comp:deprecation2]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020447.html
[cowan:comp:judge]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020450.html
[weinstock:comp:certification]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020452.html
[fontana:comp:cc0]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020453.html
[tzeng:comp:cc0]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020456.html
[morrison:comp:patents]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020457.html
[fontana:comp:cc0-recollections]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020458.html
[tzeng:comp:dominance]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020461.html
[perens:comp:participation]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020463.html
[ingo:comp:cc0]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020459.html
[tzeng:comp:cc0-relevance]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020460.html
[moen:comp:cc0]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020462.html
[rosen:comp:bsd]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020465.html
[moen:comp:bsd]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020466.html
[morrison:comp:fearmongering]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020467.html
[smith:comp:tested]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020471.html
[cowan:comp:allpatents]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020464.html
[moen:comp:bsd2]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020468.html
[cowan:comp:otherpatents]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020469.html
[moen:comp:conclusively]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020474.html
[vanl:comp:relationship]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020477.html
[fontana:comp:gplcease]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020480.html
[moen:comp:anyway]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020481.html
[weinstock:comp:separate]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020472.html
[rosen:comp:defensive]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020473.html
[perens:comp:entity]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020475.html
[weber:comp:aggregator]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020426.html
[fontana:comp:choosing]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020428.html
[ingo:comp:kingmaker]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020455.html
[fontana:comp:masslegacy]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020470.html
[ingo:comp:distromotivation]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020482.html
[vanl:comp:define]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020437.html
## License Licenses {#license-licenses}
[Patrick Masson][masson:ll:ann]
wants to update the OSI license list
to include metadata about the license,
such as the license of the license text.
[Thorsten Glaser][glaser:ll:mirbsd]
provides metadata for his MirBSD license,
but notes that no license for it’s text has been adapted.
[John Cowan][cowan:ll:gpl]
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][rosen:ll:osl] extracts the relevant paragraph from the OSL.
[Richard Fontana][fontana:ll:cautions]
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][smith:ll:mit] links to some [MIT archeology]).
It is also questionable whether licenses are copyrighted in general.
([Perens][perens:ll:copyrightability] concurs).
In contrast, [Pamela Chestek][chestek:ll:copyrightability]
provides precedent in favour of copyrightability for legal documents.
“To those of us who write them, they are as creative as code.”
[masson:ll:ann]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020562.html
[glaser:ll:mirbsd]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020563.html
[cowan:ll:gpl]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020564.html
[rosen:ll:osl]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020565.html
[fontana:ll:cautions]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020569.html
[MIT archeology]: https://opensource.com/article/19/4/history-mit-license
[smith:ll:mit]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020573.html
[perens:ll:copyrightability]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020576.html
[chestek:ll:copyrightability]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020579.html
## Three Licenses {#three}
How many licenses does one actually need?
[Bruce Perens][perens:evolve:delist]
Bruce Perens [[1][perens:evolve:delist],[2][perens:three:list]]
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][cowan:three:whynot] answers:
because that would look like ASF/FSF favoritism.
[Brian Behlendorf][behlendorf:three:legitimacy]
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][cowan:three:osl] 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][rosen:three:commons] 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][glaser:three:agenda] 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.
[cowan:three:osl]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020567.html
[rosen:three:commons]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020574.html
[glaser:three:agenda]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020575.html
[perens:three:list]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004211.html
[cowan:three:whynot]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004212.html
[behlendorf:three:legitimacy]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020526.html
## Topicality and Email Threading {#topicality}
[Kevin Fleming][fleming:topicality:frustration]
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][cowan:topicality:threading]
thinks that threading mail readers help,
but that some amount of topic intermingling is unavoidable in any medium.
[Rick Moen][moen:topicality:threading]
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][villa:topicality:email]
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][moen:topicality:notme] responds.
[fleming:topicality:frustration]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020568.html
[cowan:topicality:threading]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020572.html
[moen:topicality:threading]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020570.html
[villa:topicality:email]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020577.html
[moen:topicality:notme]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020578.html
## Other discussions {#other}
[Nigel Tzeng][tzeng:comp:dominance]
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][perens:comp:participation]
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! {#help}
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](mailto:masson@opensource.org).
The list editor works on a freelance basis
to provide monthly summaries of the License-Review and License-Discuss mailing lists.