<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 23, 2019 at 10:45 AM VanL <<a href="mailto:van.lindberg@gmail.com">van.lindberg@gmail.com</a>> wrote:</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 class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 22, 2019 at 7:59 PM Bruce Perens via License-review <<a href="mailto:license-review@lists.opensource.org" target="_blank">license-review@lists.opensource.org</a>> wrote:</div><div>You are correct that there is a business purpose that we believe will be furthered by this license. But you are fundamentally incorrect in your assertion: the license itself is written to be completely independent of the business purpose. It can be used in many different ways by many different users.<br></div></div></div></blockquote><div><br></div><div>I suppose it is <i>possible </i>for different users to use it for other purposes, and your statement would apply to any license, no matter how contrived it is to fulfill a particular purpose. But there isn't really any getting around the fact that this was designed for a specific purpose of your customer. </div><div><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 class="gmail_quote"><div>Again this is incorrect. The license only and exclusively 1) grants permissions to the Work, and 2) places conditions on the use of the Work</div></div></div></blockquote><div><br></div><div>No, we have terms regarding User Data, which is only related to the work in that the work has some role in processing it - not necessarily a large or significant role, the work nearly has to be involved in some way. A transmission through the software which did not alter the data nor derive information from it would be sufficient, under the terms. So, I think we should consider User Data to be <b>an entirely separate piece of property which is encumbered simply because you make use of this software.</b></div><div><br></div><div>This <i>should </i>raise concern, since no Open Source license allowed to date <b>encumbers data which is simply processed through it,</b> and I would submit that a violation of OSD #6 and #9 is inherent in such encumbrance.</div><div><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 class="gmail_quote"><div>“Lawful Interest” means either 1) an ownership interest or 2) a non-ownership property or possessory interest, including but not limited to lawful possession of a particular copy of a work.</div></div></div></blockquote><div><br></div><div>This doesn't really tell us much at all. As far as <i>ownership </i>interests go, we need a theory regarding ownership of data. This other than trade secret, which would obviously not apply to the person seeking access to the data. We might try a copyright applying to organization of data, which doesn't seem to apply to anyone but the software author who created that organization.</div><div><br></div><div>Possessory interest is also not applicable to the person <i>seeking</i> the data, unless the license seeks to grant a <i>very broad </i>right regarding processed data which is derived <i>in any way</i> from data for which someone has a possessory interest. Given that a cryptographic chain is the target here, where all data are derived from predecessor data, you might be saying that all people have a right to all data processed with the program, and that it is the user's obligation to make that data public.</div><div><br></div><div>This leaves us with GDPR, which does not actually settle the question of data ownership, only of such things as right to access, correct, or to be forgotten.</div><div><br></div><div>Thus, I don't think we can actually define for the user what the legal interest is. There are opinions, and little case law. We have only the most shaky idea of what our obligation is, and little protection other than reliance on an attorney's opinion. The passive user must hire an attorney to have a hope of actually complying with the license, and even then just what compliance is would still be in doubt.</div><div><br></div><div>One wonders why you don't simply fabricate a contract applying to participants in your market, rather than contriving to protect the market data through the software license. The software license could obviously be defeated through a reverse-engineering process, yielding an interoperable software without license conditions which protected the market.</div><div><br></div><div>Obviously, a contract regarding the market itself would remove the need for a new Open Source license at all. It thus seems like you aren't really attempting to protect your customer's market, but to prevent the use of the software to operate a similar market not owned by your customer without placing all of the users of <i>that</i> market under potentially odious requirements to disclose data. Thus bringing in a potential OSD#6 issue.</div><div><br></div><div>    Thanks</div><div><br></div><div>    Bruce</div></div></div>