<div dir="ltr"><div dir="ltr"><div class="gmail_quote">I have brought this discussion to <span class="gmail-il">license</span>-<span class="gmail-il">discuss</span>, as requested by Pam.</div><span class="gmail-im" style="color:rgb(80,0,80)"><div class="gmail_quote"><i><br></i></div><div class="gmail_quote"><i>The mechanism of “public performance”: The health of an open source software project relies on a predictable and consistent understanding of what the <span class="gmail-il">license</span> permits and what it requires for compliance. However, this <span class="gmail-il">license</span> uses a term specific to US law, which is “public performance.”</i></div></span><div class="gmail_quote"><br><div>There are a few issues here.</div><div><br></div><div>1. The <span class="gmail-il">license</span> is being held to a standard for universal applicability of terms of art that I am not aware has been applied to Open Source licenses before. That said, <span class="gmail-il">license</span> quality is important, and this may simply reflect the fact that more trained attorneys are participating in <span class="gmail-il">license</span>-review. But where are globally-accepted terms defined? Shall OSI at least informally adopt a particular dictionary of Legal English? Will the objection to local terms of art influence <span class="gmail-il">license</span> drafters to avoid terms of art in general, and would that detrimental?</div><div><br></div><div>2. In the Affero family of licenses, the drafters went to some lengths to synthesize a public performance right, I think in the belief that no such thing applied to software in at least one administration. At the time I thought that administration was the USA. I heard, during consideration of this <span class="gmail-il">license</span>, continuing disagreement among attorneys regarding whether a protected public performance right exists for software today in US law. Larry Rosen can give you a lecture on his use of "External Deployment" in OSL.</div><div><br></div><div>3. I don't personally find it objectionable for <span class="gmail-il">license</span> terms requiring source code distribution to trigger upon public performance. It seems reasonable in the age of SaaS, and licenses with some form of this right have been previously accepted by OSI.</div><span class="gmail-im" style="color:rgb(80,0,80)"><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 bgcolor="#FFFFFF"><i>Until now, the principle of copyleft has only been applied to literal code, not APIs. The <span class="gmail-il">license</span> submitter’s proposal is for a copyleft effect that would apply to new implementations of the API even when the underlying has been written from scratch. <a class="gmail-m_-3438543155154543484gmail-m_-8747199028017241789moz-txt-link-freetext" href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004056.html" target="_blank">http://lists.opensource.org/pipermail/<span class="gmail-il">license</span>-review_lists.opensource.org/2019-April/004056.html</a>. The <span class="gmail-il">license</span> also makes this extension even if the legal system would not extend copyright (and therefore copyleft) so far. During the <span class="gmail-il">license</span>-review process some commentators objected to this extension of the copyleft principle this far. However, the <span class="gmail-il">license</span> review committee does not believe that there was sufficient discussion representing all points of view on the <span class="gmail-il">license</span>-review list and so does not reject the <span class="gmail-il">license</span> for this reason. The <span class="gmail-il">license</span> submitter should also be aware that the OSI was a signatory on a brief submitted to the U.S. Supreme Court advocating against the copyrightability of APIs. APIs are also known to be outside the scope of copyright under European law. We are consequently uncomfortable endorsing an application of copyright law to APIs in any form without further discussion.</i></div></blockquote><div><br></div></span><div>The successful application of copyright to APIs would be a disaster for Open Source software, in that we would no longer be able to create Open versions of existing APIs or languages. Consider that the GNU C compiler is the bootstrap tool of Open Source. Now, consider what would have happened if copyright protection had prevented independent implementations of the C language.</div><div><br></div><div>So, it's a bad idea for us to in any way accept the application of API copyright today.</div><div><br></div><div>If we actually <i>get </i>API copyrights enforced against us broadly, we would obviously have to change our strategy. But until then, we shouldn't go there.</div><span class="gmail-im" style="color:rgb(80,0,80)"><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 bgcolor="#FFFFFF"><br>2.    <u>At what point the licensor can oblige licensee behavior</u>. <br>The trigger for meeting <span class="gmail-il">license</span> obligations can differ across licenses. The most common, almost universal trigger, is distribution of software. The AGPL <span class="gmail-il">license</span> triggers upon allowing network interaction with modified software. The CAL <span class="gmail-il">license</span> implements a new trigger, which is the obligation to make unmodified software available to anyone interacting with an interface for the software. In other words, someone might install a program that allows for interaction with the website (perhaps providing a webform to sign up for a newsletter) and would now be obliged to make the source code available to any person who filled out the webform. <a class="gmail-m_-3438543155154543484gmail-m_-8747199028017241789moz-txt-link-freetext" href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004113.html" target="_blank">http://lists.opensource.org/pipermail/<span class="gmail-il">license</span>-review_lists.opensource.org/2019-May/004113.html</a> The <span class="gmail-il">License</span> Review Committee does not believe that there has been adequate airing of this issue from a variety of viewpoints on the <span class="gmail-il">license</span>-review discussion about this aspect of the <span class="gmail-il">license</span>, so has not reached a conclusion about at what point imposing <span class="gmail-il">license</span> obligations is appropriate. <br></div></blockquote><div><br></div></span><div>I'm not sure I agree with the committee here, this is the public performance issue and a <i>synthetic </i>public performance right exists in an accepted <span class="gmail-il">license</span>.</div><span class="gmail-im" style="color:rgb(80,0,80)"><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 bgcolor="#FFFFFF"><br>3.    <u>A <span class="gmail-il">license</span> that requires data portability</u>. <br>Section 2.3(b) obliges the user of a software to “provide to any third party with which you have an enforceable legal agreement, a no-charge copy … of the User Data in your possession in which that third party has a Lawful Interest ….” The <span class="gmail-il">license</span> submitter confirmed in this sequence of emails that the intent of this provision is to expand the scope of software freedom: <br><a class="gmail-m_-3438543155154543484gmail-m_-8747199028017241789moz-txt-link-freetext" href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004123.html" target="_blank">http://lists.opensource.org/pipermail/<span class="gmail-il">license</span>-review_lists.opensource.org/2019-May/004123.html</a><br><a class="gmail-m_-3438543155154543484gmail-m_-8747199028017241789moz-txt-link-freetext" href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004124.html" target="_blank">http://lists.opensource.org/pipermail/<span class="gmail-il">license</span>-review_lists.opensource.org/2019-May/004124.html</a><br><a class="gmail-m_-3438543155154543484gmail-m_-8747199028017241789moz-txt-link-freetext" href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004126.html" target="_blank">http://lists.opensource.org/pipermail/<span class="gmail-il">license</span>-review_lists.opensource.org/2019-May/004126.html</a> <br>The members of the <span class="gmail-il">License</span> Review Committee do not agree whether this is appropriate for an open source <span class="gmail-il">license</span>. It therefore requires extensive additional public discussion before the OSI will be able to reach a conclusion on this point.<br></div></blockquote><div><br></div></span><div>It's my opinion that this is out of scope for an Open Source <span class="gmail-il">license</span>. My argument is on the record above and I'm glad to elaborate. I think Arthur (Van's customer) could explain what he wants to do with this and why he thinks it's important. But even if I end up approving of the sentiment, so far I think it would remain out of scope for an OSI approved Open Source <span class="gmail-il">license</span>. Of course, you don't need OSI's approval to use any <span class="gmail-il">license</span> you wish.</div><div><br></div><div>    Thanks</div><div><br></div><div>    Bruce</div></div></div></div>