[License-review] December 2019 License-Review Summary

Tue Apr 28 16:43:27 UTC 2020

All, 

In December, the License-Review mailing list went over the following:

- 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
.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20200428/c43ee971/attachment.html>