<div dir="ltr"><div dir="ltr"><div>It is clear to me that software does not, by interoperating with other software, engage in a "performance", as that term is meant in the US copyright law; that was never intended; and, it does not fall within the scope of what the statute says.</div><div><br></div><div>The word "perform" has multiple meanings: to carry out, such as an action or function; to present, such as to an audience. The definition in 17 USC 101 refers to the second of those two meanings: "To 'perform' a work means to recite, render, play, dance, or act it, either directly or by means of any device or process or, in the case of a motion picture or other audiovisual work, to show its images in any sequence or to make the sounds accompanying it audible."</div><div><br></div><div>But, that's just my view.</div><div><br></div><div>One might build an argument for finding such a right on the statute.</div><div><br></div><div>Continuing to express my view: the addition of an exclusive right in "... making aspects of the Software, including any interfaces ... directly or indirectly available to the public" is most likely to be contrary to the interests of free and open source software. </div><div><br></div><div>My view, of course, is not what matters, here. The OSI should consider the implications of endorsing a license that asserts that such a right exists.</div><div><br></div><div>There may be benefit in having a new tool to extend the reach of copyleft. However, that tool comes at a cost that is shared by others -- including, others who seek to build software in a highly interoperable world. This adds a tool for those interests that prefer barriers to interoperability. Free software has a long history of growth by interoperating with proprietary software. Increasing the extent to which interoperability between computing systems becomes a licensing event is yet one more impediment to such interoperability.</div><div><br></div><div>The proposed license demonstrates the view of some that such a right exists or should exist. As one license, what might its significance be? However, OSI's endorsement of a license that asserts the existence of such right will enhance the advocacy impact of that license.</div><div><br></div><div>OSI should consider the implications of such new right. </div><div><br></div><div>-- Scott</div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 30, 2019 at 4:36 PM Scott Peterson <<a href="mailto:speterso@redhat.com">speterso@redhat.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>Here is a context in which to consider my earlier comment about introducing a new exclusive right for software.</div><div><br></div><div>The state of copyright law as it applies to software is a shared resource.</div><div><br></div><div>As with public laws generally, one copyright owner or a community of developers or some other subset of those who create or use software does not get to have its own version of copyright law. We all need to share.</div><div><br></div><div>Actions that impact the interpretation of copyright law as it applies to software ought to be considered for their impact more broadly, not only on the situation that is the immediate subject of the actions. </div><div><br></div><div>Of course, there is an opportunity for customization: each copyright owner can offer licenses under unique terms that that copyright owner creates. But, those license terms still share the underlying copyright law that creates the rights being licensed. (But note that there is a shared interest in interpretation of widely-used license texts. <<a href="https://opensource.com/law/16/11/licenses-are-shared-resources" target="_blank">https://opensource.com/law/16/11/licenses-are-shared-resources</a>> )</div><div><br></div><div>-- Scott</div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 30, 2019 at 4:06 PM Scott Peterson <<a href="mailto:speterso@redhat.com" target="_blank">speterso@redhat.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 class="gmail_quote"><div>I arrive late to this discussion. I am sorry. I should have paid attention earlier.</div><div><br></div><div>I have just realized that this license asserts that:</div><div>"... making aspects of the Software, including any interfaces used for access to or manipulation of User Data, directly or indirectly available to the public"</div><div>is an exclusive right of an owner of copyright in the text of software.</div><div><br></div><div>If the authors of software who choose to use this license could available themselves of this sort of exclusive right without impacting anyone else, then, fine, whatever. But, they can't. The rights under copyright are (for better or for worse) granted without any action needed on the part of the owner to claim such rights. If this right is a part of the exclusive rights of a copyright holder, then it would apply to existing software -- not just to those who would like a certain type of licensing arrangement.</div><div><br></div><div>Think of all of the software that is functioning all around us -- software that was built and does what it does every day without the expectation of this twist on an exclusive right of public performance. </div><div><br></div><div>In my view, we do not need a new exclusive right for software; we have enough already.</div><div><br></div><div>Of course, a license cannot create a new exclusive right. However, it can create a base on which others might build FUD. </div><div><br></div><div><div>Let's reduce, rather than increase, FUD about rights relating to software.</div><br class="gmail-m_2016427165595275847gmail-m_-6804775770509483363gmail-Apple-interchange-newline"></div><div>Whatever the other merits of the license as a whole, I hope that it is revised to eliminate the implication that interoperation of software implicates an exclusive performance right.</div><div><br></div><div>-- Scott</div><div><br></div></div></div></div>
</blockquote></div>
</blockquote></div>