<div dir="ltr"><div>For those who haven't read the hundreds of emails on this topic over the past year, I just want to briefly summarize my own thoughts on the issue Nigel is bringing up.In an earlier iteration of the CAL I did raise this same issue with Van. <br></div><div><br></div><div>By comparison, the AGPL goes to great lengths to define the requirement to distribute source in a way that if you run unmodified AGPL software - even as a service - you are automatically compliant. This is a valuable tradition in many FOSS licenses - in particular the copyleft ones. However, in the case of the AGPL this approach does also lead to some IMO unfortunate effects. Essentially the AGPL assumes that there's some kind of (classic) user interface where the users can interact with the UI to find a link to download source code. It's not clear how one should use AGPL for software that doesn't have a user interface (in the obvious sense). It is a bit unclear what happens if AGPL software is run behind a proxy: is the user still interacting with it? And in a microservice architecture it is not clear that AGPL could be effective for anything else than the UI components, since the users do not interact with the backend components directly. (In particular, the components that would store user data!) All of these issues are consequences from the approach in AGPL arising from the principle that running the unmodified software is automatically compliant.<br></div><div><br></div><div>So when discussing this topic earlier this year, I came to the conclusion that the current wording in the CAL is the better approach. (At least better for CAL, I don't want to say I dislike the AGPL either, just that it has its own limitations.) I wouldn't want the CAL to move in a direction where it prescribes the existence of some particular UI, API or other technology. (In fact, in the extreme THAT would be against OSD # 10!)</div><div><br></div><div>And, like Van just pointed out, running CAL software for yourself - whether unmodified or modified - you will automatically be in compliance. It is only if you undertake the activity of offering the software as a service to other users, who can input data into your system, that you become liable to fulfill these obligations. This does not seem unreasonable to me at all.</div><div><br></div><div>Also, it seems likely that a lot of CAL licensed software will include the feature to easily download a copy of your user data, even if the license doesn't require it.</div><div><br></div><div>henrik<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 10, 2019 at 4:42 PM Nigel T <<a href="mailto:nigel.2048@gmail.com">nigel.2048@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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 face="arial, sans-serif" color="#000000"><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 face="Calibri, sans-serif" color="#000000"><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 face="Calibri, sans-serif" color="#000000"><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 face="Calibri, sans-serif" color="#000000"><span style="white-space:pre-wrap"><br></span></font></div><div><font face="Calibri, sans-serif" color="#000000"><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 face="Calibri, sans-serif" color="#000000"><span style="white-space:pre-wrap"><br></span></font></div><div><font face="Calibri, sans-serif" color="#000000"><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 face="Calibri, sans-serif" color="#000000"><span style="white-space:pre-wrap"></span></font></div><div><font face="Calibri, sans-serif" color="#000000"><span style="white-space:pre-wrap"><br></span></font></div><div><font face="Calibri, sans-serif" color="#000000"><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" target="_blank">van.lindberg@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid 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>
_______________________________________________<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><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><a href="mailto:henrik.ingo@avoinelama.fi" target="_blank">henrik.ingo@avoinelama.fi</a><br>+358-40-5697354 skype: henrik.ingo irc: hingo<br><a href="http://www.openlife.cc" target="_blank">www.openlife.cc</a><br><br>My LinkedIn profile: <a href="http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7" target="_blank">http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7</a></div>