<div dir="auto">Lawyers? You haven't even thought about juries.<div dir="auto"><br></div><div dir="auto">I don't think this is unreasonable. As we have recently seen in cases like Oracle v. Google, there can be really harmful decisions by juries that are poorly informed on the topic. Lawyers and judges, no matter how professional they are - about the law - can be out of their depth when considering technology issues.</div><div dir="auto"><br></div><div dir="auto">We should endeavor to tell them clearly and without omission what we actually want to happen. Not wave our hands about it, calling valid criticism unreasonable because we make invalid assumptions about the future performance of courts and juries.</div><div dir="auto"><br></div><div dir="auto">There's obviously an exception case here that needs to be handled in the license. One-directional encryption does not provide for releasing user data back to the user. Either the license has two prohibit it, or make an exception for it.<br><div dir="auto"><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 9, 2019, 10:34 AM Henrik Ingo <<a href="mailto:henrik.ingo@avoinelama.fi">henrik.ingo@avoinelama.fi</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Ok, I see your point now. While you're being unreasonable, it's a valid nitpick in a legal analysis to say that hashing could be a form of DRM in some intentionally dumb lawyer's imagination.</div><div><br></div><div>henrik<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 9, 2019 at 6:27 PM Nigel T <<a href="mailto:nigel.2048@gmail.com" target="_blank" rel="noreferrer">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="auto">Where does it say that there is no obligation? <div><br></div><div>Show me in the license text where it implies or states that the plain text password that was provided by the user to the system is not considered user data?</div><div><br></div><div>That it’s not stored in plain text on the system is covered under 4.2 where I can’t keep data from the user via encryption.</div><div><div><br></div><div><div id="m_-1032712180642542817gmail-m_6867398441529075185AppleMailSignature" dir="ltr">Sent from my iPhone</div><div dir="ltr"><br>On Dec 6, 2019, at 7:29 PM, Henrik Ingo <<a href="mailto:henrik.ingo@avoinelama.fi" target="_blank" rel="noreferrer">henrik.ingo@avoinelama.fi</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><div dir="auto">Nigel,<div dir="auto"><br></div><div dir="auto">Let's not get carried away here. If a plain text password isn't stored by the system, then there is obviously no obligation to produce a copy. This would be the case also for any other data not stored by the system.</div><div dir="auto"><br></div><div dir="auto">Henrik</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 6 Dec 2019, 23:39 Nigel T, <<a href="mailto:nigel.2048@gmail.com" target="_blank" rel="noreferrer">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">Again, where in the license text does it delineate what is required to be meet 4.2? I can return an encrypted password to the user but the plain text was provided by the user at some point. I have either not returned all the data given to me by the user or have obfuscated it using a cryptographic means.<div><br></div><div>Bob has preexisting rights to US census data records because it is public information. Alice has spent time and money cataloging that information so it could be found in a name search. The service provides linkage from people in his tree to the historical US census data. What needs to be provided?</div><div><br></div><div>Answers that states with "as a general rule" or "your example is underspecified" means Alice has to spend lots of effort to make sure that the software complies with 4.2 even if she has made zero changes to that software. </div><div><br></div><div>In the context of your company that means any would be competitor is at a huge disadvantage in using any of your offerings because at any point it could be determined that they are in non-compliance with 4.2 and only have 60 days to fix it or cease operations. It doesn't matter at all to you if you are compliant. You don't need a license. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 6, 2019 at 10:49 AM VanL <<a href="mailto:van.lindberg@gmail.com" rel="noreferrer noreferrer" 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">Hi Nigel,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 6, 2019 at 8:52 AM Nigel T <<a href="mailto:nigel.2048@gmail.com" rel="noreferrer noreferrer" target="_blank">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">3.2.a seems to imply to me that there is no patent grant when the work is used as part of a combination or modification. </div></div></blockquote><div><br></div><div>This is known as a combination carveout. Patent claims are covered for what is provided to you. If you modify the software in some way so that it infringes a patent *solely because of your modification or combination*, then your actions are not specifically licensed.</div><div><br></div><div>The rationale is clear: The licensor is only responsible for what they provide to other people, not those peoples' subsequent actions. Otherwise someone could include a single line from someone's software ("#include <stdio.h>") and claim that all the patents owned by that person were licensed.<br></div><div><br></div><div> </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">IANAL but this strikes me as a license I wouldn't touch with someone else's 10 foot pole.</div></div></blockquote><div><br></div><div>I would imagine that the CAL would not be for everyone.<br></div><div> </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><br></div><div>The new version also does not appear to address the issue that if CAL licensed software does not meet the requirements of 4.2 then the burden of meeting 4.2 falls on the user even if they had made no changes to the software. </div></div></div></blockquote><div><br></div><div>The CAL does not mandate a particular software architecture. Presumably, as with any other copyleft license, anyone wanting to use CAL-licensed software will consider whether they are willing to comply with the terms.<br></div><div> </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>A strict reading could imply that 4.2 would require that the user of the software provide clients with their plain text password. Does it? If not, why not? </div></div></div></blockquote><br>As a *general* rule, this is incorrect. Nothing in the CAL requires a party to engage in poor software design so as to keep a plaintext password available, nor does anything in the CAL require or suggest that a licensee should decrypt the user's password.
More broadly, I would hope that the user's plain text password would not be "available to [the licensee]", but no one can anticipate all the ways in which people will create software.<br><div> </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>The user of the software is the service provider and it strikes me as this license is a potential minefield for any user other than the original authors. What does "fully use an independent copy" or "substantially identical use of the work" mean in the contexts of the license? </div></div></div></blockquote><div><br></div><div>The easiest way to think about this is by analogy to the GPL3's anti-Tivoization and "complete corresponding source" provisions, If a particular piece of data is needed for the software to function in the same way in a self-hosted situation, then it must be provided.</div><div><br></div><div>To guide your thoughts here, think about the "desert island test." There is a desert island, with two people, Alice and Bob, and helpfully, two identical computer systems. Alice provides your genealogical service to Bob, her only customer, on the first computer. After a while, Bob becomes dissatisfied, and wants to be able to run the software himself.</div><div><br></div><div>Alice must provide to Bob the software itself, together with anything needed to use all the functions in the software. Alice must also provide Bob a copy of Bob's information, so that when Bob loads the information into his new copy of the software on his own computer, it has the information he expects, and the functionality associated with organizing or analyzing his information is also available.</div><div><br></div><div>There is one big caveat, though: Alice only needs to turn over information that Bob has some preexisting right to. If Alice also held her own information in the software, Alice doesn't need to turn over her own information to Bob.<br></div><div> </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><br></div><div>Take this in the context of something like a genealogy service. The user data includes my account information (data I provided), profile (data I provided), my family tree (data I provided)...</div></div></div></blockquote><div><br></div><div>Yes, Alice would provide Bob all this information.<br></div><div> </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>... my DNA information (data generated for me) and potential DNA matches (data generated for me) and links to historical data and public records (data generated for me). </div></div></div></blockquote><div><br></div><div>This example is underspecified, so this part cannot be answered given the information provided. If this information is solely based on the processing of Bob's information, then Alice would need to provide it. If this is based upon other information owned by Alice, then there is no requirement to provide information owned by Alice.<br></div></div><div class="gmail_quote"><br></div><div class="gmail_quote">Thanks,<br></div><div class="gmail_quote">Van</div><div class="gmail_quote"><br></div></div>
_______________________________________________<br>
License-review mailing list<br>
<a href="mailto:License-review@lists.opensource.org" rel="noreferrer noreferrer" target="_blank">License-review@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" rel="noreferrer noreferrer 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" rel="noreferrer noreferrer" target="_blank">License-review@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" rel="noreferrer noreferrer noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a><br>
</blockquote></div>
</div></blockquote><blockquote type="cite"><div dir="ltr"><span>_______________________________________________</span><br><span>License-review mailing list</span><br><span><a href="mailto:License-review@lists.opensource.org" target="_blank" rel="noreferrer">License-review@lists.opensource.org</a></span><br><span><a href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" target="_blank" rel="noreferrer">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a></span><br></div></blockquote></div></div></div></blockquote></div><br clear="all"><br>-- <br><div dir="ltr"><a href="mailto:henrik.ingo@avoinelama.fi" target="_blank" rel="noreferrer">henrik.ingo@avoinelama.fi</a><br>+358-40-5697354 skype: henrik.ingo irc: hingo<br><a href="http://www.openlife.cc" target="_blank" rel="noreferrer">www.openlife.cc</a><br><br>My LinkedIn profile: <a href="http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7" target="_blank" rel="noreferrer">http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7</a></div>
_______________________________________________<br>
License-review mailing list<br>
<a href="mailto:License-review@lists.opensource.org" target="_blank" rel="noreferrer">License-review@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" rel="noreferrer noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a><br>
</blockquote></div>