<html><head></head><body><div>All, </div><div><br></div><div>In December, the License-Review mailing list went over the following:</div><div><br></div><div>- ESA Permissive PL v2.3,</div><div>- Mulan Permissive Software License v1 and v2</div><div>- LGPL-2+-KDE (Legacy)</div><div>- Cryptographic Autonomy License (Beta 4)</div><div>- CasperLabs Open Source License (COSL)</div><div>- BSD-1-Clause (Legacy)</div><div>- MIT-0</div><div><br></div><div><b>ESA Permissive PL v2.3</b></div><div><b><br></b></div><div>Concern was expressed with conflicts between the license text and its FAQ</div><div><a href="https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004450.html">https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004450.html</a></div><div><br></div><div>Mulan Permissive Software License v1 and v2</div><div>The Mulan Permissive Software License, version 1 and version 2, were introduced.</div><div><a href="https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004451.html">https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004451.html</a></div><div><br></div><div>It was noted that this may be similar to licenses like the BSD+patents. Ambiguity in which language is authoritative.</div><div><a href="https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004452.html">https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004452.html</a></div><div><br></div><div>The authors explained that there was a need for a Chinese license to engage the Chinese developer community with Chinese version authoritative in case of conflict.</div><div><a href="https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004453.html">https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004453.html</a></div><div><br></div><div>Possible for the authority of version to be different depending on the country in use.?</div><div><a href="https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004472.html">https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004472.html</a></div><div><br></div><div>Can the copyright holder decide which version is authoritative?</div><div><a href="https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004473.html">https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004473.html</a></div><div><br></div><div>Two possibilities were suggested: the Chinese version be authoritative in case of legal disputes, or users select either as the normative version.</div><div><a href="https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004572.html">https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004572.html</a></div><div><br></div><div><b>LGPL-2+-KDE</b></div><div><b><br></b></div><div>The LGPL-2+-KDE license was submitted.</div><div><a href="https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004454.html">https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004454.html</a></div><div><br></div><div>A question asked, and confirmed: license falls outside the scope of the license review process.</div><div><a href="https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004458.html">https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004458.html</a></div><div><br></div><div><b>Cryptographic Autonomy License (Beta 4)</b></div><div><b><br></b></div><div>Based upon ongoing discussions with the license review committee, the author(s) withdrew Beta 3 and substituted Beta of the Cryptographic Autonomy License.</div><div><a href="https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004455.html">https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004455.html</a></div><div><br></div><div>Concerns offered regarding the effectiveness of the license, terms preventing documentation, and Interoperability.</div><div><a href="https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004456.html">https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004456.html</a></div><div><br></div><div>The lack of a patent grant and burdens placed on users for compliance was introduced.</div><div><a href="https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004475.html">https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004475.html</a></div><div><br></div><div>The importance of clarity due to uncertainty when being evaluated at court was stressed.</div><div><a href="https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004506.html">https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004506.html</a></div><div><br></div><div>Issues regarding difficulties in determining compliance were introduced and the CAL seems to be a special-purpose license only applicable to Holochain.</div><div><a href="https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004509.html">https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004509.html</a></div><div><br></div><div>A strict reading was recommended, and examples where data about a third party not be accessible on-demand were provided. It was offered that network node governance agreements were more appropriate to manage issues related to CAL than software licenses.</div><div><a href="https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004523.html">https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004523.html</a></div><div><br></div><div>Requirements that the software user provides data back to the customer even if the original software doesn’t make it available is overreaching.</div><div><a href="https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004529.html">https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004529.html</a></div><div><br></div><div>CAL has no mandatory functionality or method of compliance and instead describes what is required and having a mandatory technical structure is unwise.</div><div><a href="https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004539.html">https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004539.html</a></div><div><br></div><div>As a SaaS license, it was argued, it would not be usable by non-developers (e.g. Wordpress end-users) with compliance risks. It was offered that CAL goes against the spirit of open source software and so will continue advocating against the license.</div><div><a href="https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004549.html">https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004549.html</a></div><div><br></div><div>A suggestion was made to reject the license due to bad intentions: it would be better to focus on the license text without the classification of participants and assuming moral standards.</div><div><a href="https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004564.html">https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004564.html</a></div><div><br></div><div>Concern was voiced with the effect on downstream users.</div><div><a href="https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004558.html">https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004558.html</a></div><div><br></div><div>Clarification was offered that user data is defined as “data which the recipient has an existing right of ownership or possession” with references to the GDPR and the CCPA.</div><div><a href="https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004583.html">https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004583.html</a></div><div><br></div><div>The scope of CAL was questioned: forces apps that run on Holochain to use an open source license? Is the use of Holochain APIs, and nothing more considered distributing Modified Work? Would social network software need to be under an open source license?</div><div><a href="https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004573.html">https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004573.html</a></div><div><br></div><div>It was suggested that the requirement to assert patents against interoperable open source software is a fundamental flaw.</div><div><a href="https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004485.html">https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004485.html</a></div><div><br></div><div>A case was made that though any party can assert a patent, open source projects don’t assert patents and that the difference with the CAL is that the network breaks if interoperable software under other open source licenses are allowed.</div><div><a href="https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004501.html">https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004501.html</a></div><div><br></div><div>One offered that the rewording strengthened the justification of the rights of users to their own data in terms of exercising user freedom, however, may be too narrow.</div><div><a href="https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004463.html">https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004463.html</a></div><div><br></div><div>CasperLabs Open Source License (COSL)</div><div><a href="https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004508.html">https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004508.html</a></div><div><br></div><div>The initial comment was that the license is not a good candidate for approval due to focus on a business model, complexity without good reason, onerous obligations to the licensor, specific to distributed ledger technology, unstable links, ceding decision power to the licensor, clashes with OSDs 6, 8, and 10, that OSD 3 is not fully fulfilled.</div><div><a href="https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004513.html">https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004513.html</a></div><div><br></div><div>It was offered that the terms in the license are more appropriate for governance agreements, not software licenses.</div><div><a href="https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004527.html">https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004527.html</a></div><div><br></div><div>A question was posed on why GPLv3, AGPL, or the CAL are insufficient for the purposes of COSL?</div><div><a href="https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004521.html">https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004521.html</a></div><div><br></div><div>It was suggested the license violates OSD 5, 6, 7, and 9.</div><div><a href="https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004530.html">https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004530.html</a></div><div><br></div><div>As many people stated issues are unpassable it was proposed further discussion was no longer needed.</div><div><a href="https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004533.html">https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004533.html</a></div><div><br></div><div>A comment was made that the license privileges one set of contributors over others and allows expropriation.</div><div><a href="https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004532.html">https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004532.html</a></div><div><br></div><div><b>BSD-1-Clause</b></div><div><br></div><div>The BSD-1-Clause license was submitted for approval.</div><div><a href="https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004510.html">https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004510.html</a></div><div><br></div><div>This was identified as an obvious case for approval.</div><div><a href="https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004518.html">https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004518.html</a></div><div><br></div><div><b>MIT-0</b></div><div><br></div><div>The approval status of MIT-0 license was requested.</div><div><a href="https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004576.html">https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004576.html</a></div><div><br></div><div>An observation was made that the notation on the SPDX list may be inadvertent, noting originally listed as “not OSI-approved.”</div><div><a href="https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004578.html">https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004578.html</a></div><div><br></div><div>Recognition was made that the license author/steward is not claiming it is OSI-approved.</div><div><a href="https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004579.html">https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004579.html</a>.</div></body></html>