<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>