<div dir="ltr"><p></p>
<p>In May, the License-Review mailing list saw extensive debate on the 
Cryptographic Autonomy License. The list also discussed a BSD variant 
used by the Lawrence Berkeley National Laboratory, and the 
Master-Console license.</p>
<p>This summary can also be read online at <a class="gmail-uri" href="https://opensourcde.org/LicenseDiscuss052019">https://opensourcde.org/LicenseDiscuss052019</a></p>

<p>The corresponding License-Discuss summary is online at <a class="gmail-uri" href="https://opensource.org/LicenseDiscuss052019">https://opensource.org/LicenseDiscuss052019</a>
 and covers an announcement regarding the role of the License-Review 
list, discussion on the comprehensiveness of the approved license list, 
and other topics.</p>
<p><b id="gmail-cal">Cryptographic Autonomy License</b></p>
<p>The review of the Cryptographic Autonomy License (CAL) continues. 
Back in April, Van Lindberg submitted the CAL as a network copyleft 
license, but with broader scope than the AGPL (<a href="https://opensource.org/LicenseReview042019#cal">see the summary</a>).</p>
<p>While the CAL clearly tries to comply with the OSD, there are 
widespread concerns as to whether some fundamental aspects are 
compatible with open source and software freedom.</p>
<p><b id="gmail-cal-public-performance">Public Performance</b></p>
<p>Bruce Perens claims that use of public performance rights implies a 
field-specific restriction in the sense of OSD #6, e.g. because it would
 allow private use but not public use. (Note: the mere use of these 
rights does not create such a restriction.)</p>
<p>Scott Peterson argues that software interoperation cannot be a 
“performance” in the sense of US copyright law – even if a public 
performance right exists for software. The CAL makes software 
interoperation more difficult and should not be approved. Van Lindberg 
provides his analysis of the term. Notably, Lindberg’s definition does 
not require a human audience for the performance.</p>
<p>Chestek finds a potential problem with how public performance 
interacts with modified works, as parts of the license only consider 
public performance of interfaces. Van Lindberg appreciates this point.</p>
<p><b id="gmail-cal-userdata">User Data</b></p>
<p>Bruce Perens argues that the CAL’s user data provisions go beyond 
copyright law. Users don’t have an a priori right to receive their user 
data until the CAL created this right. But this means that the 
operator’s copyright license is conditional on fulfilling the user data 
obligations, which is an unreasonably far-reaching compulsion.</p>
<p>Pamela Chestek follows up on <a href="https://opensource.org/LicenseReview042019#cal-freedom-data">April’s discussion</a>
 on whether the CAL’s user data clause is comparable with the GPLv3’s 
anti-Tivoization clause. Van Lindberg sees a distinction between two of 
CAL’s clauses: The CAL forbids locking down the software via 
cryptographic means, a kind of Tivoization. The CAL also requires user 
data to be provided, which is necessary to ensure user freedom in a SaaS
 context. Bruce Perens agrees that this should be fixed – but by some 
law, not by a license. And anyway, the user should just keep backups of 
their data.</p>
<p>Nigel Tzeng thinks the user data obligations are unrealistic and 
excessive, for example where the operator has no easy way to make a copy
 of the data. This is problematic even with a good faith effort to 
comply, and makes the CAL “unworkable for most operators.” How detailed 
do requests have to be? Does holding a copyright license imply a 
possessory interest? But if the user data only covers the user’s inputs 
(not modified or intermediate formats), the right to a copy is also not 
very useful.</p>
<p>Van Lindberg responds that the user data clauses ensure data 
portability to inputs and outputs of the software, and where the user 
has some possessory interest in the data. What that encompasses 
precisely would depend on the jurisdiction. Having a (public) license 
for some data does not imply a possessory interest.</p>
<p>User data requests will typically only cover data that the end user 
uploaded. This can be implemented via export functionality in the 
software (note: as is already common in GDPR-compliant systems). That 
does not imply excessive effort for the operator. Where no such 
functionality is implemented this may require some effort, but that is 
comparable with having to provide the source code. When the request 
covers data that they didn’t upload, they would have to specifically 
demonstrate their possessory interest.</p>
<p>Bruce Perens doesn’t buy Lindberg’s argument that providing user data
 were easy. In a blockchain setting, providing user data might be as 
simple as providing a copy of the blockchain. But in other settings 
operators have no guidance or guarantees. Peer to peer applications seem
 especially problematic, since every end user would be an operator. 
Lindberg’s fixation on certain SaaS settings is not helpful.</p>
<p><b id="gmail-cal-gdpr">GDPR</b></p>
<p>Chestek assumes the GDPR is being referenced because there would 
otherwise be a conflict with CAL compliance. Such preferential treatment
 of the GDPR would be “facially non-compliant with OSD 6”: it relieves 
someone complying with the GDPR from complying with the CAL. Compliance 
with the CAL might also be impossible if a jurisdiction has conflicting 
privacy laws. The section should be rephrased to avoid being specific to
 any legal regime, or removed when no conflict is expected.</p>
<p>Lindberg explains that the reference to GDPR is intended to 
streamline compliance: if the operator already complies with the GDPR, 
that’s already good enough for compliance with the CAL’s user data 
requirements. This is just an interpretive guide, and doesn’t confer 
special permissions. Given the amount of confusion that clause has 
caused, Lindberg considers removing it.</p>
<p><b id="gmail-cal-fontana">Fontana: The CAL is not Free because it encumbers APIs</b></p>
<p>In April, Pamela Chestek had asked why specifically the CAL should 
not be approved, under the assumption that public performance rights are
 a thing for APIs.</p>
<p>Richard Fontana responds:</p>
<ul><li><p>it forces reimplementations of a CAL-covered API to be open source</p></li><li><p>Joke: any license can be opposed on the grounds that it violates OSD 5/6 (restricts some persons, or fields of endeavour)</p></li><li><p>but here the CAL really looks like such a violation</p></li><li><p>not necessarily a problem: even the GPL certainly restricts some persons</p></li><li><p>“From a software freedom perspective, extending a copyleft requirement to an interfae is unjust.”</p></li><li><p>CAL might violate the spirit of OSD 9 (don’t restrict other software), similar to the SSPL.</p></li><li><p>OSI review should not just check OSD conformance, but also whether the license provides software freedom</p></li><li><p>the CAL’s unreasonable burden on interface re-implementors violates software freedom.</p></li><li><p>that the license limits itself to copyright law doesn’t mean it provides software freedom</p></li><li><p>a copyleft license like the CAL doesn’t necessarily make more software available under open licenses.</p>
<ul><li>unusual license might see no adoption</li><li>seems to serve a proprietary dual-licensing business model</li><li>which would mean it would actually result in <em>less</em> open software</li></ul></li><li><p>questions what it means to publicly perform an API.</p>
<ul><li>could see such a performance for GUIs</li><li>but APIs are not typically perceived by users</li></ul></li></ul>
<p>Pamela Chestek responds that she still can’t see the CAL “as even 
slightly different from the GPL in reach”, under the assumption that API
 copyright exists. Chestek is more concerned about the applicability of 
public performance rights outside the US. Chestek is confused by 
Fontana’s position that a free software license may not apply copyleft 
to all aspects of copyright (such as API copyright).</p>
<p>Chestek does not believe Fontana’s argument that the CAL will result 
in less free software. If some copyleft licenses are harmful, where 
exactly is the tipping point? Why is AGPL acceptable but CAL not?</p>
<p>Fontana responds that a license may decide to cover API copyright, 
but no FOSS license should do so. Fontana thinks that the CAL breaks 
with the (A)GPL tradition, and is confident that the FSF would condemn 
any interpretation that the CAL were essentially the same as the GPL.</p>
<p><b id="gmail-cal-perens">Perens: Licenses should not cover API copyright</b></p>
<p>Bruce Perens summarizes his stance on free software:</p>
<ul><li>since the DFSG, it has been clear that running open source software for any purpose must be allowed</li><li>it is necessary that the rules don’t have total sympathy for proprietary developers</li><li>it is fine to require the sharing of modifications</li><li>many network copyleft licenses change the fundamental deal of open source
<ul><li>running for any purpose no longer allowed</li><li>such licenses no longer respect users</li></ul></li><li>approving network copyleft licenses is a slippery slope towards losing authority</li><li>supporting API copyright is a bad idea because it can be used against the open source community
<ul><li>perhaps later API copyright licenses will become necessary as a defense</li></ul></li></ul>
<p>On the interpretation of the OSD, Perens sees two ways forward: 
Either the OSD is interpreted literally, but is also amended/clarified 
regularly. Or, the OSD is interpreted intelligently.</p>
<p>Van Lindberg argues that “we have already entered the world in which 
licenses like the CAL are necessary”: “Put aside the network aspect. How
 many reimplementations of the GNU readline interface are there? How 
many bashisms have made it into other shells? Under Oracle v Google, 
those are derivative works.” Perens disagrees and urges not to “concede 
the fight before it is lost.”</p>
<p>Henrik Ingo agrees with Perens that the CAL oversteps some 
boundaries, in particular with its user data requirements. However, the 
age of SaaS makes strong network copyleft licenses necessary in order to
 protect end user freedom. Ingo hopes a scaled-down CAL would get 
approved.</p>
<p>To Peren’s point that approving non-free licenses could cause the OSI
 to lose authority, Ingo adds that failing to approve OSD-compliant 
licenses would be harmful as well. “Network copyleft is clearly an area 
where currently supply and demand don’t meet”. Perens obviously 
disagrees and reminds that approval can cause problems for the 
community. The community is also not reliant on OSI approving new 
licenses, just like the FSF doesn’t have to write new licenses: “While 
we are starting to see reasons for GPL 4, nobody is in a hurry.”</p>
<p>Pamela Chestek questions why involving public performance rights is 
necessary to protect APIs. “Public performance” is an US-specific term, 
and the CAL might stretch beyond the bounds of copyright. In contrast, 
the GPLv3 defines its term “propagate” in terms of copyright law. 
Chestek suggests the CAL could borrow this approach. Lindberg doesn’t 
quite disagree, but objects on multiple points. The CAL should make its 
intention to cover public performance explicit, it already defines the 
term within the license, it must also consider IP other than copyright, 
it doesn’t stretch beyond copyright, and Lindberg would like to stick to
 existing terms.</p>
<p><b id="gmail-cal-website">Freedom in Website and Blockchain Scenarios</b></p>
<p>Pamela Chestek asks whether she would be eligible to receive a 
CAL-covered websites source code when she enters a third party’s user 
data into a form on the website. Van Lindberg responds that yes, she 
would be eligible for the source just as under the AGPL. However, the 
source code requirement already triggers due to using the software. 
Here, the third person’s personal data is not that third person’s user 
data, but the user data of the one entering the data into the website.</p>
<p>Bruce Perens extends the scenario with a blockchain-based example, 
where there might be “derivative data”. Perens also thinks the CAL’s 
definition of source code includes private keys that were used to 
manipulate data in the blockchain. After all, any blockchain participant
 would be an operator processing user data. (Note: this may be a 
misunderstanding of both blockchain technology and the CAL.)</p>
<p>Van Lindberg provides two detailed replies. The CAL does not have a 
concept of derived data. Instead, obligations arise if someone is a 
Recipient in the sense of the license. The operator’s obligation to 
provide data only extends to the user’s data, and only to the extent 
that the operator can retrieve this data. Disclosure of private keys is 
not required in the context of user data, although it could be required 
in the context of the source code as part of the CAL’s anti-Tivoization 
clause. In general, Perens’s hypotheticals “don’t really make sense”, 
and would result in roughly the same outcomes as under the AGPL.</p>
<p>Bruce Perens claims that while the CAL may or may not violate the 
OSD, it definitely violates the FSF’s Freedom Zero “to run the program 
as you wish, for any purpose”. The problematic user data terms even 
apply to unmodified software. In Peren’s eyes, Lindberg has arbitrarily 
redefined the FSF’s concept of Software Freedom to cover user data. 
Lindberg insists the CAL ensures end user freedom the same way the GPL 
does, this involves preventing intermediaries/operators from taking 
rights away. The question to decide is precisely whether the operator’s 
freedom to lock down end user data is more important than the end user’s
 freedom to run the software with their own data. Lindberg and Perens 
just disagree on how to resolve that dilemma. Lindberg has also asked 
the FSF for their opinion.</p>
<p>Bruce Perens also thinks the user data terms are unnecessary in the 
decentralized context for which the license was drafted. Lindberg argues
 that the CAL helps to keep a system decentralized.</p>
<p>Bruce Perens sees an overarching problem with the license: that even 
competent attorneys seem to be struggling with its terms, particularly 
regarding user data and public performance. Courts might not share 
Lindberg’s interpretation. Developers without legal counsel don’t have 
the “slightest hope” of applying the license correctly. Lindberg 
concedes that fully understanding a legal instrument like the CAL does 
require counsel. But the CAL is no more complex than the GPL. The effect
 of the CAL can be summarized concisely in a manner that would be 
understood by an ordinary developer. Perens Perens disagrees with that 
summary, and thinks Lindberg’s stance is deeply unsympathetic to users.</p>
<p><b id="gmail-cal-other">Other Points</b></p>
<p>Re claim by Pamela Chestek: OSI decision making is unpredictable. 
Bruce Perens responds that “we like it that way”. OSI review should not 
mechanically implement pseudo-laws, but care about the community’s 
interest.</p>
<p>Bruce Perens asks whether the copyright holder would also be bound by
 the conditions of the CAL, e.g. regarding user data. Peren’s 
understanding is that they would not be bound, which would privilege 
them compared to other operators. Van Lindberg claims that the CAL 
places no party in a privileged position.</p>
<p>Van Lindberg argues that the CAL is also necessarily because the AGPL
 is so unclear and ambiguous. The CAL would be clearer, and would have 
applicable case law “at least by analogy”.</p>
<p>Kevin Fleming asks if the CAL is only fully effective if patents are 
involved. Lindberg responds that patents holders will have extra tools, 
but that the CAL is based equally on copyright, patents, and contract 
methods.</p>
<p>Pamela Chestek and Van Lindberg continue their review discussion from last month.</p>
<ul><li><p>Lindberg updated language around the LGPL/MPL-style Combined Works exception.</p></li><li><p>Chestek thinks the anti-DRM clause is “unintelligible”. Lindberg 
provides a side by side comparison of the clauses in GPLv3 and CAL.</p></li><li><p>Chestek thinks the CAL is overly complicated when trying to 
ensure that all permissions are passed to downstream recipients. Isn’t 
this as simple as “cannot impose additional restrictions”? Lindberg 
responds that this isn’t as simple. He doesn’t want to enumerate allowed
 restrictions like the GPL does. However, Lindberg updates relevant 
language in the CAL.</p></li></ul>
<p>Henrik Ingo is torn on whether the CAL should be approved. Prima 
facie, the CAL violates the OSD – but only due to its well-justified, 
tightly-scoped user data requirements that are necessary to ensure end 
user freedom in practice: “the CAL is a net positive contribution to 
software freedom.” The user data clauses do not violate Freedom Zero if 
the operator is viewed as merely running the software <em>on behalf</em> of the end user. If this violates the OSD, maybe the OSD should be amended.</p>
<p>Bruce Perens doesn’t think the OSD can be a comprehensive list of 
allowed or disallowed license features. It should not be amended until 
it can be interpreted mechanically.</p>
<p>Ingo had invoked the License Zero review as precedent. Richard 
Fontana clarifies that L0 was retracted and not rejected, but that the 
significant past “hostile receptions” should be treated with some 
significance.</p>
<p><b id="gmail-cal-summary">Lindberg’s Summary</b></p>
<p>Van Lindberg tries to summarize various objections and discussion 
points, and provides references to various arguments that have been 
made. The three main issues are:</p>
<ol type="1"><li>whether data portability can be guaranteed as part of software freedom and under the OSD</li><li>whether public performance is effective, OSD-compliant, and good policy</li><li>whether the CAL is too complicated or unclear</li></ol>
<p>The objections mainly apply to the operator of the software, not to end users. Issues 1 and 2 are fundamental policy questions.</p>
<p>Bruce Perens confirms he believes that “an operator’s ability to lock
 down the data they receive from end users is core to the OSD and to the
 concept of Free Software” (as phrased by Lindberg). John Cowan thinks 
Lindberg is approaching this from the wrong end: the right to commit 
crimes is not core to FOSS. But using FOSS licensing to enforce ethical 
actions is a Very Bad Idea.</p>
<p>Lawrence Rosen is against approval. While Rosen accepts a public 
performance right for software (his own OSL uses it), it has limited 
value and has nothing to do with normal execution of the software. 
Performance does not include the rendering, display, or execution of a 
software. Rosen thinks the CAL’s user data clauses are troubling, since 
data is not copyrightable. At most, a confidentiality clause would be 
appropriate. Lindberg points out that the CAL has nothing to do with 
copyrightability of data, and uses a multi-pronged mechanism of which 
copyright is only one part. Lindberg thinks Rosen is reading the 
definition of public performance in US law too narrowly, and provides 
caselaw to bolster his argument.</p>
<p>Luis Villa argues that the CAL is not excessively complex. The CAL 
and GPL use similarly complex language, although both are more complex 
than other licenses. If objections on the grounds of complexity were to 
carry any weight, then “OSI can… only approve long-existing licenses (or
 trivial permissives). (If that’s the board’s intent I’d love to hear 
it; we can all unsubscribe from this list and call it a day!)” McCoy 
Smith concurs: there’s a difference between ambiguity (bad) and inherent
 complexity (acceptable) of a license.</p>
<p>Pamela Chestek adds the major objection that the CAL would be the 
first open source license to encumber API reimplementations. This is the
 main issue, compared to any debates over public performance. Henrik 
Ingo argues that both are problematic, and that invoking public 
performance rights seems unnecessary except for the CAL’s goal to 
implement API-copyleft. Lindberg views these issues as independent. The 
CAL’s use of public performance is primarily an alternative to the 
AGPL’s “network interaction” mechanism. API copyleft is a reaction to 
the Oracle vs Google case.</p>
<p>Richard Fontana thinks Lindberg’s summary fails to accurately capture
 fundamental objections. The issue is not whether API copyleft could be 
premature, the whole concept runs against FOSS and industry conventions.
 If a license makes use of API copyright, then please only for maximally
 permissive licensing. Henrik Ingo thinks API copyright would be a huge 
detriment to the industry – would any readline implementation be 
copyright infringement? But if it happens, the FOSS community shouldn’t 
just cede that ground. “Still, as long as we’re not there yet, we of 
course shouldn’t be the first party to strike.”</p>
<p><b id="gmail-lbnl">LBNL BSD</b></p>
<p>Sebastian Ainslie asks for <em>legacy approval</em> of the LBNL-BSD, a
 3-clause BSD variant used at the Lawrence Berkeley National Laboratory 
(LBNL). Compared to the common BSD template, it adds a caveat that U.S. 
Dept. of Energy approval may be required, presumably required for all 
DOE labs. It also adds a paragraph that published modifications fall 
under the same license by default. This is a bit like an implied CLA, or
 like copyleft with an opt-out. Ainslie explains this is necessary in 
order to accept contributions without signed CLAs.</p>
<p><b id="gmail-legacy">Legacy approval</b></p>
<p>There is some contention on what <em>legacy approval</em> signifies.</p>
<p>Bruce Perens raises a license proliferation objection. McCoy Smith 
wonders why OSI approval is needed if the license has already been used 
for over a decade. Richard Fontana wonders whether actively used 
licenses are eligible for legacy approval. Kevin Fleming assumes that 
the use of legacy-approved licenses would be discouraged. On further 
reading, Fontana finds that legacy approval is just retroactive. It does
 not require the license to be unused, and does not imply any 
discouragement.</p>
<p>Richard Fontana thinks that legacy-approval must generally meet the 
same standard as new licenses, especially with regard to OSD 
conformance. But it would be a good idea for OSI to take a more active 
role to explicitly approve licenses that are commonly used in Linux 
distributions. Legacy approval should therefore be more lenient about 
sloppy or amateurish drafting. 15 or 30 years ago, licenses simply were 
not drafted with the same standards we expect today.</p>
<p>Fontana sees many people who do not accept OSI’s stewardship of the 
Open Source definition. They can point to a vast collection of open 
source software that does not use OSI-approved licenses. A mass effort 
to approve more obviously-FOSS licenses would then have some benefit.</p>
<p><b id="gmail-lbnl-review">Actual review</b></p>
<p>Fontana sees the added paragraph as unclear or sloppily drafted. It 
might not trigger the default license if modified versions are privately
 given to third parties, without these modifications being published. 
This is different from Apache 2 which just codifies the “inbound = 
outbound” expectation. Pamela Chestek wonders whether the paragraph is 
even relevant: “inbound = outbound” is the default expectation, with or 
without that paragraph. The paragraph mainly affirms that modifications 
can be published under a <em>different</em> license. Henrik Ingo shares 
this view (see also below). John Cowan disagrees: by default the 
modifications would have no license, as the BSD would only apply to the 
original work.</p>
<p>Tom Callaway questions why the paragraph seems to assign different 
terms to enhancements than the main BSD license. Richard Fontana too 
thinks that the contributor license is broader than the BSD. Ainslie 
argues that no such different terms are used, but this seems to confuse 
the submitted license with a suggested simplification by Callaway.</p>
<p>McCoy Smith and Henrik Ingo note that OSI usually rejects licenses 
that give preferential treatment to one party, or are specific to some 
entity. Here, this is not a problem: while the LBNL is mentioned 
explicitly as a recipient, it receives the same rights as the public.</p>
<p>Henrik Ingo is slightly concerned about the default license paragraph
 acting like an implicit contributor agreement. But this is not a 
problem in practice: code added to a BSD-licensed project is considered 
to be BSD-licensed as well. The paragraph only seems like a 
clarification in case of a standalone patch is sent without explicit 
license indicators.</p>
<p>Brendan Hickey isn’t sure whether implicit “inbound = outbound” 
should be promoted. Hickey points to projects like Linux that expects 
patches to be explicitly signed off by the contributor. Hickey also 
points to the C-FSL review, where it was discussed that licenses cannot 
do copyright assignment. So what kind of licensing terms would actually 
be necessary in order to safely accept contributions? Henrik Ingo 
responds that the license status of published modified versions is 
usually clear without having to take extra steps, and that no copyright 
assignment is involved.</p>
<p>Richard Fontana suggests a DCO (<a class="gmail-uri" href="https://developercertificate.org/">https://developercertificate.org/</a>) as a simpler way to ensure that contributions are properly licensed.</p>
<p>Ainslie says that DOE labs cannot use a vanilla BSD license, which 
made small changes to the license necessary. Pamela Chestek Pamela 
Chestek asks for documents that require these changes and McCoy Smith 
asks which specific changes are mandated. Ainslie says they have to 
attribute their funding source and add a notice that DOE approval be 
required. McCoy Smith questions whether the addition of a notice even 
creates a new license. It is unclear to Chestek which of these changes 
are part of the license that is under review.</p>
<p>McCoy Smith thinks making the license conditional on DOE approval 
could be an OSD 7 issue. But is that a license condition, or just a 
notice?</p>
<p>Pamela Chestek asks how many projects use this LBNL license. Ainslie 
says it’s used by nearly all open source software from Berkeley Lab, 
adding up to hundreds of releases.</p>
<p><b id="gmail-master-console">Master-Console</b></p>
<p>Wayne Rangel Wayne Rangel submits the “Master-Console’s Open Source 
Definitive License” for approval. It is difficult to tell, but the 
rationale for this license seems to be:</p>
<ul><li>that the original author can take down malicious modifications</li><li>that the source code shall be offered in a specific manner, presumably that the source code can be downloaded via a web browser</li></ul>
<p>Lukas Atkinson expresses their frustration that the license seems 
impossible to understand, both from a legal perspective and due to the 
unidiomatic English. Christoper Sean Morrison thinks “that should be 
grounds for rejection alone.” McCoy Smith sees the license terms as an 
OSD 5/6 violation. The license is also likely non-free, “although the 
wording is such that I can’t quite tell.” Bruce Perens points to the 
Artistic License as an example where an unclearly drafted license 
resulted in high costs to third parties.</p>
<p>Richard Fontana suggests the license is not yet ready for review. 
Pamela Chestek asks for the license to be retracted from review.</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>