[License-review] February 2020 License-Review Summary

Mon Jun 8 16:43:02 UTC 2020

Hello all,

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

   - Continued discussion on the Cryptographic Autonomy License (Beta 4)
   - Resolution of the Cryptographic Autonomy License (Beta 4) – Approved
   - Resolution on the Mulan PSL V2 - Approved

*Continued discussion on the Cryptographic Autonomy License (Beta 4)*
Statement for the need of consistency with capitalizations
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004649.html

Support for approval despite lingering concerns such as the potential for
abuse and the earlier drafting history, due to lack of grounding in the
current text.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004650.html

Question concerning the license and its ability to ensure that customer
data won’t be locked and that the sharing of improvements to the code will
be maximized
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004651.html

Confirmation on all concerns being addressed by the license
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004652.html

Suggestion that more discussion is still needed due to concerns with how
the license is in previously-mentioned situations and how it interacts with
the principles of FOSS and its effect on users, but with a slight
inclination towards approval
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004653.html

Support for approval due to conforming with the OSD as well as the
alignment with the current understanding of values in the FOSS community
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004659.html

Support for rejection or further discussion due to privacy risks
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004662.html

Clarification that the license requires that users retain control of keys
but that system keys are not User Data as defined
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004663.html

Request for the location in the license for this distinction and statement
that the distinction between user and system as well as client and server
are unclear in peer-to-peer systems
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004664.html

Directions to section 4.1 in the definition of the source code and user
autonomy provisions in 4.2.2, both where it is stated that cryptographic
keys are required to make the distinction clear
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004665.html

Concerns regarding the requirement for documentation for use, requirement
for configuration information, the possibility for coercion regarding
handing over encrypted data and encryption keys,  the term “recipient”
being too broad, and that the issues like privacy attacks caused by the
client-server style approach of the CAL. Requests for scenario examples for
further discussion.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004668.html

Clarification that there is no requirement for the generation of new
documentation and that the context of configuration information is just for
the information needed to install and use, that the CAL is written for a
peer-to-peer application though is compatible in client-server
applications, and that the term “recipient” can be used as in a
peer-to-peer network users can act as a client as well as act as a server.
Response that the request reflects a misunderstanding of the CAL
requirements.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004669.html

Request for clarification on the problems being addressed regarding user
freedom, language adjustment recommendations, statement that the privacy
attack is easier to accomplish, and a request for information on the
limitation of the disclosure of recipient user data without the disclosure
of the operator’s private data, together with an example that highlights
the issue.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004672.html

Answer that a problem addressed is the gradual re-centralization of
decentralized systems, clarification that no new documentation is required
and that the context is the provision of the source code, and that the
example provided that highlights the issue around the disclosure of data is
in the wrong layer.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004674.html

Request for clarification whether interaction with a remote version of an
application requires distribution of source code or not and modified
example highlighting the issues of data accessibility and transmission and
compliance with the license.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004675.html

Statement that creating new functionalities regarding data dumps are not
required by the CAL but that the license prevents removing them and that in
the example there would be no violations.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004699.html

Statement that concerns with the CAL in terms of the OSD are with regards
to the forced disclosure of private data or keys, the term “use” being too
broad with the suggestion to use “execute” instead, issues with the
implications of data retention in the event of accidental data loss and
data extraction if it is not easy, and that a peer-to-peer actor model
environment would be difficult to be compliant and may result in security
weakening. Sections 6 and 10 of the OSD are highlighted.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004686.html

Clarification that there is no forced disclosure without a legal right,
that the difference in wording of “use” and “execute” are not meaningful in
the context of providing information, that the difficulty level of
providing data has already been discussed, that there is no requirements
with regards to data retention, and that liability regarding data
extraction is with the service provider and no the developers.  Answer that
there is no discrimination involved if the author chooses an architecture
that is more difficult in terms of compliance.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004688.html

Clarification on “user data”, statement that “use” is better, that the
License Committee judged that the requirement to give user/recipient data
is not too burdensome, and that OSD 6 and 10 don’t require that the license
be usable for every type of software.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004692.html

Suggestion to include the nullification of copyleft/proprietary dual
licensing into the license.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004680.html

Answer that it is not a good idea to introduce changes at this stage.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004682.html

Recommendation to reject or have more discussions due primarily to the user
data provision due to unclarity regarding who is the service provider.
 https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004679.html
<https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004679.html>
Direction to section 4 which defines what providing a service is in terms
of communicating the Work to another person.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004681.html

Question with regards to a theoretical example where voice recording is
submitted to improve the quality of voice recognition and the accessibility
of all recordings by one user.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004683.html

Answer that it would not allow access to the recordings of others.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004684.html

Concerns with the PII, GDPR, CCPA, and similar laws and their implications
with the CAL.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004689.html

Answer that the CAL was written to be compatible with the GDPR and the CCPA
and uses similar language.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004690.html

Concerns with regards to the frequent occurrence that a bit of data is
about more than one person and that GDPR itself is still evolving.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004705.html

Answer that data that GDPR applies to is a different set than what the CAL
considers User Data
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004708.html

Statement that the obligations with regards to the cryptographic keys would
not be under the CAL
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004696.html

*Resolution of the Cryptographic Autonomy License (Beta 4) – Approved*
Approval of the Cryptographic Autonomy License (Beta 4) for the
Uncategorized Licenses category
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004660.html

Eight voted in favor, none opposed, one abstained, and two were not present.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004694.html

*Resolution of the Mulan PSL V2 - Approved*
Approval of the Mulan PSL V2 for the International category
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004670.html

Nine voted in favor, none opposed and abstained, and two were not present.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004695.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20200608/6b1d7fa5/attachment.html>