<div dir="ltr"><p></p>
<p>In March, the License-Discuss mailing list discussed:</p>
<ul><li>the Cryptographic Autonomy License
<ul><li>its interactions with the GDPR</li><li>how public performance applies to software</li></ul></li><li>the License-Review process
<ul><li>views on tone and conduct on the list</li><li>the list’s role in the license review process</li><li>problems with email, and alternative tools</li><li>whether a PEP-style process might help</li></ul></li><li>whether licenses should be drafted without legal assistance</li><li>and more</li></ul>
<p>The summary can also be read online at <a class="gmail-uri" href="https://opensource.org/LicenseDiscuss032019">https://opensource.org/LicenseDiscuss032019</a></p>

<p>The corresponding License-Review summary is online at <a class="gmail-uri" href="https://opensource.org/LicenseReview032019">https://opensource.org/LicenseReview032019</a> and covers the SSPL’s retraction from review, as well as discussion of a set of GPLv3 additional terms.</p>
<p><b id="gmail-cal">Cryptographic Autonomy License</b></p>
<p>Van Lindberg requests comments on his Cryptographic Autonomy License 
(CAL), a network copyleft license motivated by blockchain-based 
software. He also wrote a <a href="https://www.processmechanics.com/2019/03/15/the-cryptographic-autonomy-license/">blog post</a> explaining the license’s background and rationale in detail.</p>
<p><b id="gmail-cal-gdpr">User Data and the GDPR</b></p>
<p>The CAL has provisions that ensure user’s access to their data, which
 goes in a similar direction as the EU’s GDPR – it even references the 
GDPR in an interpretation clause. The CAL defines a concept of Lawful 
Interest as the trigger for user access rights.</p>
<p>Henrik Ingo notes that this grants rights to third parties, which is 
fairly novel and could raise OSD issues. Van Lindberg says these are 
just third party beneficiaries that receive no rights other than access 
to the Source and to their own User Data. The data protection in the CAL
 is not a grant of rights to third parties, but a limitation on the 
grant to the licensee, similar to the GPLv3’s anti-Tivoization clause.</p>
<p>Henrik Ingo dives a bit deeper into the CAL ↔ GDPR relationship, and 
finds CAL User Data to be inconsistent the GDPR personal data concept.</p>
<p>Van Lindberg responds that the CAL and GDPR have different angles: 
GDPR is primarily concerned about privacy, the CAL primarily about User 
Autonomy. Lawful Interest is intended to not only capture rights through
 ownership or the GDPR, but also things like the right to an ebook the 
user possesses or has licensed. The CAL’s User Data concept is more 
broad than the GDPR’s Personal Data. Based on Ingo’s feedback, Lindberg 
updates the wording of the CAL to clarify its relationship with the 
GDPR.</p>
<p><b id="gmail-cal-public-performance">Public Performance</b></p>
<p>The CAL triggers some license obligations on “Public Performance”, an
 aspect of copyright not explicitly discussed by existing Open Source 
licenses. This is intended to create a network-copyleft license like the
 AGPL, while being less specific to a medium or technology.</p>
<p>Henrik Ingo is a bit put off by this unusual term, similar to the 
usage of Conveyance in the GPLv3. The CAL also doesn’t make it clear 
what “Publicly Performing an interface” means. Is there any precedent 
for applying public performance to software? What is an interface? How 
would this apply to a library API? Ingo is also concerned that public 
performance could be too broad so that it would cover way more than SaaS
 style use.</p>
<p>Van Lindberg points out that Public Performance is a well-established
 term in copyright law, but concedes that its application to software is
 less well defined. Lindberg intends “interface” to be interpreted 
broadly, from GUIs to APIs – as long as it can be protected by IP law. 
This should definitely cover more than just SaaS use. After all, the CAL
 tries to ensure user autonomy in distributed software systems.</p>
<p>Henrik Ingo thinks the lack of clarity around public performance is a
 major weakness of the CAL – maybe specific uses should be always 
allowed, similar to how the GPL gives unlimited permission to run the 
unmodified program?</p>
<p>Bruce Perens isn’t sure whether the U.S. copyright law provides a 
sufficient public performance rights for the CAL to work, in particular 
whether software is a literary work. Van Lindberg provides numerous 
references for both US and international law that software is treated as
 a literary work. (Note: see also the WIPO Copyright Treaty.) It follows
 that literary works’ performance rights must also apply to software.</p>
<p><b id="gmail-cal-other">Other Notes</b></p>
<p>Henrik Ingo: isn’t “Compatible Open Source License” just any 
OSI-approved license? Van Lindberg responds that the CAL defines Open 
Source licenses as both OSI- and FSF-approved, but that compatibility is
 determined by the terms of the other license.</p>
<p>The CAL allows a simple LGPL-like exception to be added. Henrik Ingo 
would prefer if that was a clearly separate license with its own name. 
Van Lindberg doesn’t think this would be a problem, just as there isn’t a
 problem with different GPL exceptions like Classpath.</p>
<p>The CAL significantly expands the reach of copyleft licensing, in 
particular to public performance. Henrik Ingo thinks this “copyright 
maximalist” attitude is regrettable, and echoes Bruce Peren’s opinion 
that “Extension of copyright is bad for open source”. Van Lindberg 
responds that the CAL tries very hard to fit within the established 
reach of IP law.</p>
<p>Bruce Perens thinks that restricting the license grant to copyright 
and patents may be too narrow for jurisdictions that recognize 
additional rights. Perens suggests the license should grant all 
necessary rights, and only exclude trademarks. Van Lindberg considers 
broadening the grant.</p>
<p>Bruce Perens thinks that the CAL’s anti-DRM clause is too narrow as 
it focuses on specific techniques like cryptographic keys. This could 
even be understood as a OSD #6 usage restriction. Van Lindberg agrees 
that could be too narrow by itself, but that the license also contains 
more general anti-DRM clauses. The mention of specific technologies was 
requested by his client. This isn’t so much a user-restrictiction as a 
kind of anti-Tivoization clause made necessary by the environment for 
which the license is being developed.</p>
<p><b id="gmail-process">Discussion of License-Review process</b></p>
<p>In the context of the SSPL’s withdrawal from OSI review (see the <span class="elide">License-Review</span>
 summary), Josh Berkus voices disappointment with the License-Review 
process: instead of legal discussions on the contents of the license, 
Berkus saw ad-hominem attacks.</p>
<blockquote>
<p>[This] was a dramatic failure of the license-review process, and I 
think shows that this group needs to be reconstituted. […] We need a 
real process around license approval that isn’t “outlast the licensing 
wonks with the most free time.”</p>
</blockquote>
<p>This sparks extensive discussion on whether there was a problem, how 
the SSPL review should have worked instead, how reviews work, what the 
problems with email lists are, and whether there might be alternatives 
(Discourse?).</p>
<p><b id="gmail-process-conduct">Views on tone and conduct of the list</b></p>
<p>McCoy Smith and Richard Fontana don’t share Berkus’ view. Discussions
 about MongoDB’s business model aren’t ad-hominem attacks, but closely 
related to the license’s practical effects. Overall, it remained fairly 
civil. Fontana saw “energetic and serious discussion […] from an 
unusually wide variety of commenters” and is concerned that curtailing 
“opinionated, impassioned” discussion “could have the effect of stifling
 debate and expression.”</p>
<p>Bruce Perens thinks that discussion remained civil, but that he can’t
 respond to some people without it being perceived as a “shouting 
match”.</p>
<p>Josh Berkus reports that people on the “outside” are baffled and appalled by conduct around the SSPL discussion.</p>
<blockquote>
<p>The OSI only has authority to the extent that we are widely regarded 
as an impartial arbiter of what is and is not open source. It’s 
important. And on the SSPL, we are <em>not</em> widely perceived as fair or impartial.</p>
</blockquote>
<p>Richard Fontana points out that License-Review is a public list and 
shouldn’t be conflated with the OSI. And OSI didn’t get to be an arbiter
 on the SSPL because the license was voluntarily withdrawn. However:</p>
<blockquote>
<p>Participants on license-review are expected to adhere to the code of 
conduct, but they are not expected to be neutral or non-opinionated[.]</p>
</blockquote>
<p>Rick Moen suspects that the discontent with the list’s discussion 
culture is just “passive-aggressive kickback against License Committee 
decisions they didn’t like”. Richard Fontana shares that suspicion: 
“this sounds to me like a complaint that most of the active participants
 in the license-review threads on SSPL were hostile to SSPL.”</p>
<p>Perens thinks the problem is that discussion turned repetitious. 
Lawrence Rosen responds with an 8-point manifesto with his most-repeated
 points.</p>
<p>Luis Villa complains about the volume and quality of discussion. 
Debate is “only valuable to the extent that they help [and] the current 
quality and nature of the discussion don’t do that very well”:</p>
<blockquote>
<p>at some point I checked in […] to see that the thread was <em>literally 100 emails</em>, considered how negative (and often circular) the earlier parts had been, and said “nope, life is too short”.</p>
</blockquote>
<p><b id="gmail-process-sspl">Should the SSPL review have had a different focus?</b></p>
<p>Where Josh Berkus would like to have seen discussions about copyleft 
and the OSD in general, Richard Fontana reminds that the license review 
is not the place for that. The review should only check whether the 
license “conforms to the Open Source Definition and provides software 
freedom.” But for Berkus these are not separable: the question of OSD 
compliance is directly related to the question how far copyleft can and 
should be extended.</p>
<p>To Berkus’ dismay, the recent CopyleftConf
 didn’t see much discussion specifically about the SSPL. McCoy Smith 
summarizes some points from his talk at the conference which did mention
 that license and discusses a hypothetical Extreme Copyleft Public 
License as a though experiment. Smith also points out that the AGPL 
addresses SaaS business models, so it isn’t like the OSI had an 
anti-SaaS bias. Smith doesn’t think the community would have a 
fundamental objection against extending copyleft beyond AGPLv3.</p>
<p><b id="gmail-process-list">The list’s role in the license-review process</b></p>
<p>Rick Moen proposes that if the fundamental problem is that 
License-Review discussions are mistaken for official OSI position, that 
could be solved if people speaking officially self-identify themselves 
better.</p>
<p>McCoy Smith sees the following criticisms being made here, and discusses them in more detail:</p>
<ol type="1"><li>a few loud voices have undue influence on review decisions</li><li>the voices lack variety, or do not reflect the “silent majority”</li><li>it is unclear how review decisions take the email discussions into account</li></ol>
<p>Bruce Perens notes about the latter point that the lists are merely 
advisory, and that the decisions are made by the OSI board in a vote. 
But there’s a lack of transparency in how the board reaches its 
decisions. Do the board members even read the License-Review list? And 
how did which director vote? Mike Milinkovich shares his experience as a
 previous board member: nearly all license approval votes were 
unanimous. There is also more to the board than voting on licenses, so 
not every board member should be expected to be a licensing expert.</p>
<p>Richard Fontana adds that most license submitters retract their 
license if it’s not clear that it will be approved. This month’s vote on
 the CFSL might have been the first rejection. In that sense, the 
question isn’t whether loud voices have undue influence on the OSI, but 
what effect they have on the submitter. MongoDB retracted the SSPL just a
 few days before the board vote, citing a failure to reach a community 
consensus on the license (which was more than just the license-review 
discussion).</p>
<p>Ben Hilburn thinks Fontana’s distinction between influence on OSI vs 
influence on license submitters is really important. But while some 
disagreement is normal and expected, it may also be important to protect
 the submitter and the debate from negative conduct. Hilburn cautions:</p>
<blockquote>
<p><em>especially</em> for licenses where License-Review recommends rejection, our process and debates really needs to be trusted.</p>
</blockquote>
<p><b id="gmail-process-tools">Problems with email, and alternatives</b></p>
<p>Bruce Perens mentioned discussion turned repetitious. Andrew DeMarsh 
too thinks the medium of mailing lists makes it easy to discuss the same
 topics again and again, without being able to easily reference their 
previous occurrence. This is boring and tiring for list participants. 
Maybe a better front-end to the mailing lists would help.</p>
<p>Luis Villa highlights that the current email-based review process has a number of issues or limitations:</p>
<ul><li>limited visibility into the process from the outside</li><li>too easy to generate vasts amounts of discussion</li><li>these monthly summaries are too infrequent to guide discussion</li><li>specific issues are not listed or tracked</li><li>difficult for outsiders to join constructively, not just with drive-by comments</li><li>no way to silently signal agreement</li><li>McCoy Smith adds: archives are difficult to search</li></ul>
<p>Villa suggests that the Discourse software might offer a better 
platform, but really that any other tool than email would be an 
improvement. Any tool will have <em>some</em> drawback, but Villa believes Discourse will reduce the barrier of entry to the discussions.</p>
<p>Rick Moen provides a critical summary of his experience with 
Discourse, for example mentioning the lack of threaded discussion. In 
contrast, John Sullivan notes that the FSF is happily using Discourse.</p>
<p>Richard Fontana thinks Discourse would be worth trying, although it 
may be geared to different kinds of discussions. Fontana doesn’t think 
that “new tools will solve what are fundamentally social or political 
problems.” Villa responds that tools do ease the symptoms.</p>
<p>Rick Moen and Thorsten Glaser are concerned that using Discourse 
would require discussion participants to enter a contract with a third 
party hosting company. Kevin Fleming and Michael Downey responds this 
wouldn’t be the case.</p>
<p>Bruce Perens suggests that at least, the list archive software could 
be upgraded to something better than Pipermail, which only supports 
plain text emails.</p>
<p>Responding to an offhand mention of Bugzilla or GitHub, Fontana 
argues that they would be elitist and keep non-technical people out. 
“several years ago I entertained the idea that it would be obviously 
beneficial for license drafting to adopt the preferred tools of 
developers. […] I see now that […] involved a lot of romanticization of 
developers and open source development.”</p>
<p>Ben Hilburn agrees with some of the problems around email, but 
appreciates that email lets the user choose their clients and workflows.
 Some web-based tools can be integrated with an email-based workflow, 
which may be desirable.</p>
<p><b id="gmail-process-pep">Would a PEP-style process help?</b></p>
<p>John Sullivan suggests that the process could be improved without 
having to change the tools. For example, each license application could 
be assigned a (volunteer) caretaker who maintains a dossier with the 
salient points of the discussion. In the end, any process will rely on 
individuals, and no process will be able to prevent louder voices or 
individuals with agendas.</p>
<p>Chris Jerdonek draws a comparison to Python’s PEP model (<a href="https://www.python.org/dev/peps/pep-0001/">Python Enhancement Proposal</a>)
 where discussion is summarized in a central document. Such a document 
would also be useful for further reference. Van Lindberg and Ben Hilburn
 concur.</p>
<p>Bruce Perens and Jerdonek caution that discussion in the PEP process 
is still mailing-list based with all the drawbacks of the medium. John 
Sullivan and Jerdonek explain that having the central PEP document helps
 to keep the discussion on track and makes it easier to join the 
conversation later.</p>
<p>Bruce Perens is concerned that a PEP-like process might have 
difficulty achieving consensus for political decisions like license 
approval. Perens points at the W3C, which used to make consensus 
decisions until patent policy issues caused insurmountable 
disagreements. Chris Jerdonek sees PEP more as a documentation thing, 
not as a consensus-building process. Approval decisions are made 
externally (Note: compare the role of the OSI board).</p>
<p>Van Lindberg illustrates how the PEP process relates to the review of
 his CAL license (see below). Here, Lindberg tracks various arguments in
 a PEP-like blog post.</p>
<p>Who should maintain the PEP summary? Pamela Chestek suggests the 
license submitter could be be tasked with this in order to avoid 
burdening volunteers. Luis Villa thinks it might be hard for submitters 
to determine the useful and important arguments that should be covered 
in the summary. Bruce Perens thinks a process editor (or group of 
editors) can be useful. That might be a job for legal professionals, but
 not for volunteers on the list who might have a stake in the outcome.</p>
<p>Richard Fontana is concerned about possible bias in the summary, both
 if it is maintained by volunteer editors but especially if the license 
submitter were responsible. Having a group of editors might help though.
 Perens thinks submitter-written summaries could work if the summary 
document has a clear version history, and the submitter is paired with 
an unaffiliated editor.</p>
<p>Luis Villa suggests more collaborative Wiki-ish approaches, or that 
revisions of the summary would have to be approved by an independent 
person. Villa is less concerned about bias, more that a useful summary 
is written at all.</p>
<p>Chris Jerdonek explains that submitter-written summaries can work if 
bad/biased summary will be cause for a license rejection. Version 
control etc. is important, though.</p>
<p><b id="gmail-pro-se">The pro-se license constructor</b></p>
<p>The License-Review list saw a submission of a license that didn’t 
have previous legal review. That raises the question whether it is safe 
and acceptable for non-lawyers to create and submit licenses.</p>
<p>Bruce Perens argues that it is dangerous to promote “Crayon 
Licenses”. Without legal review, the actual effects of that licenses are
 unknown. “I thus feel all such things should be rejected, although the 
reason is entirely outside of the OSD.”</p>
<p>As an example, Perens points to the Jacobsen v Katzer case about the 
Artistic License, which Larry Wall had drafted pro-se. The case could 
have set “an absolutely horrid precedent […]: that the license was 
tantamount to a dedication to the public domain.”</p>
<p>McCoy Smith warns that requiring prior legal review would be a 
barrier to entry, could cause the review discussion to be dominated by 
lawyers, and wouldn’t guarantee license quality. Perens suggests the 
barrier could be avoided if the OSI would assign a lawyer like a “public
 defender”. Henrik Ingo doesn’t see an issue with a barrier to entry: 
There are plenty of approved licenses already available. And the 
license-review process isn’t zero-cost either, the cost is just born by 
OSI. (Note: and the community!)</p>
<p>Brendan Hickey digs into the purpose of barriers and legal review. 
Hickey doesn’t think that legal review would be suitable to protect end 
users of the license. And legal probably shouldn’t be the first step: 
“No one should be hiring an attorney to draft a license that will be 
rejected out of hand.”</p>
<p>Nigel Tzeng claims that advice from lawyers would be ignored anyway, 
which seems to reference the NOSA review. John Cowan points out that a 
license may be a fine legal document but still fail to conform to the 
OSD. Tzeng and Bruce Perens rehash some of the discussion around the 
NOSA. After a while that argument flows into the more general discussion
 about the license-review process, covered above.</p>
<p>Van Lindberg discusses different aspects of license review. On one 
hand there are policy choices and community considerations, but 
determining whether a license is legally sound and complies with the OSD
 is “strongly legally inflected”. Richard Fontana takes issue with that:
 The OSD is not a legal document but “a statement of philosophy and 
policy aimed at nonlawyers.” Determining OSD compliance might require 
lawyer-style thinking, but “a nonlawyer who is steeped in free/open 
source legal policy […] might be much better qualified to interpret the 
OSD”. Lawyers might also be biased, for example when they are 
representing a client. While input on the legal soundness of a license 
is valuable and requires legal specialists, e.g. in case of the SSPL the
 policy arguments were ultimately more important.</p>
<p><b id="gmail-leftovers">Leftovers</b></p>
<p>Thorsten Glaser cross-posts a discussion from the Fedora-Legal list 
about whether the Open Motif license can be considered open source. Open
 Motif has an unusual license that restricts its use to “open source” 
operating systems. Bruce Perens considers this OSD #9 and #10 
violations. Florian Weimer points out that RHEL nevertheless ships Open 
Motif, and he doesn’t think this restriction would be problematic.</p>
<p>The GPLv3 allows additional terms that prohibit misrepresentation or 
decline trademarks. Patrick Schleizer asks: Does that mean the GPL 
grants such rights by default? John Cowan argues that failure to 
prohibit something is not permission. Similarly, Bruce Perens points out
 the lack of affirmative statements that would grant these rights. And 
the licenses don’t have to cover everything in detail: they are embedded
 in a wider legal context.</p>
<p>End users of open source licenses typically don’t explicitly accept 
the license. Patrick Schleizer asks: Doesn’t that mean any limitations 
of liability are ineffective because the end user never <em>waived</em> their rights? Or can warranties be unilaterally <em>disclaimed</em>
 by the author? Does this differ between common law and civil law 
jurisdictions? Thorsten Glaser suggests that disclaimers are a condition
 on the copyright license. Van Lindberg points to the difference between
 licenses and contracts (Note: which may be an US-centric viewpoint).</p>
<p>Chris Lamb links to the <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905674">discussion on the Debian bug tracker</a>
 about the “citationware” requirement of Ole Tange’s GNU Parallel 
utility: the utility prints out a demand to cite the software or to pay 
the author a lump sum. Jonathon contrasts academic conventions around 
citation with the wording of that requirement. Bruce Perens notes that 
in the meanwhile, the citation requirement has been reduced to a 
non-compulsory request.</p>
<p>Responding to <span class="elide">January’s discussion</span> about 
“intimacy”, Florian Weimer adds that AGPL compliance is particularly 
unproblematic for quine-like programs that can provide their own source 
code.</p>

</div>