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.