December 2019 License-Review Summary

License-Review mailing list topics for December 2019:

  • ESA Permissive PL v2.3,
  • Mulan Permissive Software License v1 and v2
  • LGPL-2+-KDE (Legacy)
  • Cryptographic Autonomy License (Beta 4)
  • CasperLabs Open Source License (COSL)
  • BSD-1-Clause (Legacy)
  • MIT-0

ESA Permissive PL v2.3

Concern was expressed with conflicts between the license text and its FAQ
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004450.html

Mulan Permissive Software License v1 and v2

The Mulan Permissive Software License, version 1 and version 2, were introduced.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004451.html

It was noted that this may be similar to licenses like the BSD+patents. Ambiguity in which language is authoritative.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004452.html

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.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004453.html

Possible for the authority of version to be different depending on the country in use.?
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004472.html

Can the copyright holder decide which version is authoritative?
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004473.html

Two possibilities were suggested: the Chinese version be authoritative in case of legal disputes, or users select either as the normative version.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004572.html

LGPL-2+-KDE

The LGPL-2+-KDE license was submitted.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004454.html

A question asked, and confirmed: license falls outside the scope of the license review process.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004458.html

Cryptographic Autonomy License (Beta 4)

Based upon ongoing discussions with the license review committee, the author(s) withdrew Beta 3 and substituted Beta of the Cryptographic Autonomy License.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004455.html

Concerns offered regarding the effectiveness of the license, terms preventing documentation, and Interoperability.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004456.html

The lack of a patent grant and burdens placed on users for compliance was introduced.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004475.html

The importance of clarity due to uncertainty when being evaluated at court was stressed.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004506.html

Issues regarding difficulties in determining compliance were introduced and the CAL seems to be a special-purpose license only applicable to Holochain.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004509.html

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.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004523.html

Requirements that the software user provides data back to the customer even if the original software doesn’t make it available is overreaching.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004529.html

CAL has no mandatory functionality or method of compliance and instead describes what is required and having a mandatory technical structure is unwise.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004539.html

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.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004549.html

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.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004564.html

Concern was voiced with the effect on downstream users.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004558.html

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.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004583.html

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?
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004573.html

It was suggested that the requirement to assert patents against interoperable open source software is a fundamental flaw.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004485.html

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.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004501.html

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.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004463.html

CasperLabs Open Source License (COSL)

https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004508.html

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.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004513.html

It was offered that the terms in the license are more appropriate for governance agreements, not software licenses.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004527.html

A question was posed on why GPLv3, AGPL, or the CAL are insufficient for the purposes of COSL?
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004521.html

It was suggested the license violates OSD 5, 6, 7, and 9.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004530.html

As many people stated issues are unpassable it was proposed further discussion was no longer needed.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004533.html

A comment was made that the license privileges one set of contributors over others and allows expropriation.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004532.html

BSD-1-Clause

The BSD-1-Clause license was submitted for approval.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004510.html

This was identified as an obvious case for approval.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004518.html

MIT-0

The approval status of MIT-0 license was requested.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004576.html

An observation was made that the notation on the SPDX list may be inadvertent, noting originally listed as “not OSI-approved.”
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004578.html

Recognition was made that the license author/steward is not claiming it is OSI-approved.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004579.html.

Note

If you'd like to participate on the lists, head over to https://opensource.org/lists for information on how to subscribe.