License-Review mailing list topics for February 2020:
- 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 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
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
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