February 2020 License-Review Summary

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

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. 

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

Confirmation on all concerns being addressed by the license

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   

Support for rejection or further discussion due to privacy risks

Clarification that the license requires that users retain control of keys but that system keys are not User Data as defined 

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

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

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

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.

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. 

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.

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.

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.

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.

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.

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.

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.

Suggestion to include the nullification of copyleft/proprietary dual licensing into the license.

Answer that it is not a good idea to introduce changes at this stage.

Recommendation to reject or have more discussions due primarily to the user data provision due to unclarity regarding who is the service provider.

Direction to section 4 which defines what providing a service is in terms of communicating the Work to another person.

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.

Answer that it would not allow access to the recordings of others.

Concerns with the PII, GDPR, CCPA, and similar laws and their implications with the CAL.

Answer that the CAL was written to be compatible with the GDPR and the CCPA and uses similar language.

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.

Answer that data that GDPR applies to is a different set than what the CAL considers User Data

Statement that the obligations with regards to the cryptographic keys would not be under the CAL

Resolution of the Cryptographic Autonomy License (Beta 4) – Approved

Approval of the Cryptographic Autonomy License (Beta 4) for the Uncategorized Licenses category

Eight voted in favor, none opposed, one abstained, and two were not present.

Resolution of the Mulan PSL V2 – Approved

Approval of the Mulan PSL V2 for the International category

Nine voted in favor, none opposed and abstained, and two were not present.