<div dir="ltr"><div class="gmail_quote">I have brought this discussion to license-discuss, as requested by Pam.</div><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 license permits and what it requires for compliance. However, this license uses a term specific to US law, which is “public performance.”</i></div><div class="gmail_quote"><br><div>There are a few issues here.</div><div><br></div><div>1. The license 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, license quality is important, and this may simply reflect the fact that more trained attorneys are participating in license-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 license 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 license, 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 license 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><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 license 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_-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/license-review_lists.opensource.org/2019-April/004056.html</a>.
The license also makes this extension even if the legal system would
not extend copyright (and therefore copyleft) so far. During the
license-review process some commentators objected to this extension
of the copyleft principle this far. However, the license review
committee does not believe that there was sufficient discussion
representing all points of view on the license-review list and so
does not reject the license for this reason. The license 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><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><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 license obligations can differ across
licenses. The most common, almost universal trigger, is distribution
of software. The AGPL license triggers upon allowing network
interaction with modified software. The CAL license 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_-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/license-review_lists.opensource.org/2019-May/004113.html</a>
The License Review Committee does not believe that there has been
adequate airing of this issue from a variety of viewpoints on the
license-review discussion about this aspect of the license, so has
not reached a conclusion about at what point imposing license
obligations is appropriate. <br></div></blockquote><div><br></div><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 license.</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 bgcolor="#FFFFFF">
<br>
3. <u>A license 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 license 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_-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/license-review_lists.opensource.org/2019-May/004123.html</a><br>
<a class="gmail-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/license-review_lists.opensource.org/2019-May/004124.html</a><br>
<a class="gmail-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/license-review_lists.opensource.org/2019-May/004126.html</a>
<br>
The members of the License Review Committee do not agree whether
this is appropriate for an open source license. 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><div>It's my opinion that this is out of scope for an Open Source license. 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 license. Of course, you don't need OSI's approval to use any license you wish.</div><div><br></div><div> Thanks</div><div><br></div><div> Bruce</div></div></div>