<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Van,<div><br></div><div>Point 1: So under 4.2 you are required to return the hashed password and the salt (if any) in addition to any other information in the user profile that is required to run the system. M'kay. </div><div><br></div><div>Point 2: <font face="arial, sans-serif"> It is not straightforward for the non-programmer to determine if the software is compliant with 4.2 even within the context of Point 1. The user provided the password. Whether a salt is used or not is an implementation detail. Did the export provide a salt? Was it needed? How do I know without looking at the code?</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">The <b>software is not a safety deposit box</b> because of the requirement that you must also return <i>"</i><span style="background-color:transparent"><i style="color:rgb(0,0,0);white-space:pre-wrap">data has been generated by, for, or has been assigned to the Recipient". </i><font color="#000000"><span style="white-space:pre-wrap">Safety deposit boxes don't generate new content for users. Software often does. </span></font></span></font></div><div><span style="color:rgb(0,0,0);font-family:arial,sans-serif;white-space:pre-wrap;background-color:transparent"><br></span></div><div><span style="background-color:transparent"><font color="#000000" face="arial, sans-serif"><span style="white-space:pre-wrap">Even ignoring generated data that you'd have go though each and every UI screen and make sure all inputs provided by user are correctly mapped to an export field...and you have to do this every time you update from upstream.</span></font></span></div><div><font face="arial, sans-serif"><span style="background-color:transparent"><font color="#000000"><span style="white-space:pre-wrap"><br></span></font></span></font></div><div><font face="arial, sans-serif"><span style="background-color:transparent"><font color="#000000"><span style="white-space:pre-wrap"><b>If the original software cannot export all of the data required to meet the requirements of 4.2 then all subsequent users of the software are in breach of the license.</b> </span></font></span></font><span style="color:rgb(0,0,0)"><font face="arial, sans-serif"><b>This is a point that you continue to dance around. </b></font></span><span style="background-color:transparent"><font face="Calibri, sans-serif"><font color="#000000"><span style="white-space:pre-wrap">You are handwaving significant legal and technical burden you are placing on users of CAL licensed software because you want to extend licensing requirements beyond open </span><b style="white-space:pre-wrap">source</b><span style="white-space:pre-wrap"> into open </span><b style="white-space:pre-wrap">data </b></font></font></span><span style="background-color:transparent"><font face="Calibri, sans-serif"><font color="#000000"><span style="white-space:pre-wrap">and non-technical users who just use the software out of the box don't control that at all. There are no exceptions for non-compliance of the original code in this license so it's <b>a compliance nightmare</b></span></font></font></span><font color="#000000" face="Calibri, sans-serif"><span style="white-space:pre-wrap"><b> for every downstream user whether they change the code or not</b>.</span></font></div><div><span style="background-color:transparent"><font face="Calibri, sans-serif"><font color="#000000"><span style="white-space:pre-wrap"><br></span></font></font></span></div><div><span style="background-color:transparent"><font face="Calibri, sans-serif"><font color="#000000"><span style="white-space:pre-wrap">This license appears to work only for the most simplest of use cases (namely yours) and not in general and would be hugely harmful if attempted to be used on larger, more complex data systems because many users would invariably be in breach as most </span></font></font></span><font color="#000000" face="Calibri, sans-serif"><span style="white-space:pre-wrap">software can't actually export user data to the required level without resorting to database tools.</span></font></div><div><font color="#000000" face="Calibri, sans-serif"><span style="white-space:pre-wrap"><br></span></font></div><div><font color="#000000" face="Calibri, sans-serif"><span style="white-space:pre-wrap">And don't try to tell me folks wouldn't try to use CAL on software they shouldn't because a big selling point for CAL is "open data". I'm all for open data but having written software to manage large amounts of user data and I can tell you the challenge to provide the user data required to "fully use an independent copy of the Work" is very demanding for all but the simplest of systems even when it's something you want to do. </span></font></div><div><font color="#000000" face="Calibri, sans-serif"><span style="white-space:pre-wrap"><br></span></font></div><div><font color="#000000" face="Calibri, sans-serif"><span style="white-space:pre-wrap">At best this is a special purpose license that needs huge warnings on it as it is written today.</span></font></div><div><font color="#000000" face="Calibri, sans-serif"><span style="white-space:pre-wrap"></span></font></div><div><font color="#000000" face="Calibri, sans-serif"><span style="white-space:pre-wrap"><br></span></font></div><div><font color="#000000" face="Calibri, sans-serif"><span style="white-space:pre-wrap">Nigel</span></font></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 9, 2019 at 8:03 PM VanL <<a href="mailto:van.lindberg@gmail.com">van.lindberg@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>Nigel - <br></div><div><br></div><div>I'll answer both your emails here.</div><div><br></div><div>First, with regard to passwords: If someone doesn't store the plaintext password, it is not "available" to be provided. Note that the user data only needs to be provided if it is available to the operator for use with the Work. Further, using a password hash also doesn't prevent the use of the data in the context of the system. If a program is set up to use a password hash to validate someone's password, then the hashed password is actually what is necessary.</div><div><br></div><div>This gets to your second point: What if some software is not "4.2 compliant" as you put it? It is straightforward - someone can know what they received from the third party Recipient in order to make things work. Did you receive a password and username so that the person could log in? Then you give it back. You don't need to forensically examine the software in order to watch and make sure that you give back the things that the user gave to you.</div><div><br></div><div>As an analogy, think about the software as a safety deposit box. You are the bank. When you run the software, you get an empty box. If you choose to make the software available to a user, then the user can put something in the box. You can put something in the box for the user. When the user wants to leave, they get their own box and whatever was in their box. <br></div><div><br></div><div>Thanks,<br></div><div>Van</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div>Thanks,<br></div><div>Van<br></div><div><br></div></div><br></div>
_______________________________________________<br>
License-review mailing list<br>
<a href="mailto:License-review@lists.opensource.org" target="_blank">License-review@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" rel="noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a><br>
</blockquote></div>