<div dir="ltr"><div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr"><br></div><div dir="ltr" class="gmail_attr">On Fri, Jul 12, 2019, 14:38 John Cowan <<a href="mailto:cowan@ccil.org" rel="noreferrer noreferrer" target="_blank">cowan@ccil.org</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 dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 12, 2019 at 2:11 PM Russell McOrmond <<a href="mailto:russellmcormond@gmail.com" rel="noreferrer noreferrer noreferrer" target="_blank">russellmcormond@gmail.com</a>> wrote:<br></div><div dir="ltr" class="gmail_attr"><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">What is a "public performance" other than an interaction with software through some public interface?</div></div></blockquote><div><br></div><div>Why, that's easy: it is nothing at all. What is a "public performance" of a painting, a sculpture, or a building? (There is a separate right of "public display".)</div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">I can't tell if you are agreeing or disagreeing that it is the same or similar (right to authorise "public performance" of software, and interface/API copyright).</div><div dir="auto"><br></div><div dir="auto">Copyright is a bundle of rights, and the rights are necessarily different for different types of creative works. Visual Art (like paintings) in many countries has a resale right, while literary works very deliberately have a first sale doctrine to disallow downstream restrictions or royalties. Software is often thought of as a literary work, but it has many traits that are quite different than fiction novels/etc, and it is inappropriate to treat them as identical.</div><div dir="auto"><br></div><div dir="auto">The concept of a public performance of a music composition is the closest analogy to this software legal theory, and yet quite different due to the control software has over our lives. (Read Lessig's: Code and other laws of cyberspace). While a computer can read music compositions as instructions and automatically "perform" them without the additional help of a human, and a music composer has the right to authorise that activity, that is a very different activity than reading software instructions and "performing" them (publicly or otherwise).</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Anyone fighting for software freedom should be trying to reduce the excessive unaccountable control large software vendors have, not enhance their power over citizens through novel legal theories.</div><div dir="auto"><br></div><div dir="auto">The harm of the public performance via public interface legal theory seems to me to be as bad as information/mental process patents and technological measures. The FSF and others at one time opposed software patents, and still claims to oppose DRM (encrypted media is a restriction across an interface, conceptually similar to the problem here).</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>You still haven't answered my question about whether ssh-ing to someone else's server and running some program there counts as "on your own computer" or not. Does it matter if you pay for the use of the server or it is gratis? (I hold that the GPL conditions attach in all these cases)<br></div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I did answer, but you didn't accept my answer.</div><div dir="auto"><br></div><div dir="auto">It is usually bad form to repeat an answer to a Straw Man argument. I specifically spoke about control, not ownership of hardware.</div><div dir="auto"><br></div><div dir="auto">This means if you ssh into a computer you control (the use of the ssh protocol itself doesn't disclose the level of control you have), then you are the one who installs/combines/runs/etc the software (the software user, for the purposes of software license agreements). While I don't believe private copying should be regulated by copyright, and have actively promoted that concept within Canada, we can leave that issue for the moment as you seem to accept that all these activities should be thought of as regulated activities.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">I have sshd set up in many environments to only allow sftp/rsync. The user of that API is not the software user for the purposes of a software license agreement. In this case the license applies to me (I copied/installed it, authorised it to run, etc), not to any of those API users, and not about any of those API users.</div><div dir="auto"><br></div><div dir="auto">The license on sshd does not attempt to dictate the licensing or other terms of commands that are forked from it. I can ssh into a computer and run the most offensive proprietary software, and the licensors of sshd don't and should never have a say in that.</div><div dir="auto"><br></div><div dir="auto">I suspect this is where you were trying to lead the conversation, suggesting that typing commands on a shell is analogous to a public interface. Fortunately most people recognise the harm that a shell copyright owner dictating terms about what commands run from a shell, and thus nobody has claimed a desire to regulate that interface. But once we accept regulation of and across interfaces, there will be many harmful consequences: intended or unintended doesn't matter.</div><div dir="auto"><br></div><div dir="auto">I still don't know why people are spending so much time trying to extend the scope of exclusive rights for software exclusive rights owners. This is effectively what they are doing by trying to extend the class of people considered software users for the purposes of software license agreements, and extend the types of restrictions that can be demanded across interfaces.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>John Cowan <a href="http://vrici.lojban.org/~cowan" rel="noreferrer noreferrer noreferrer" target="_blank">http://vrici.lojban.org/~cowan</a> <a href="mailto:cowan@ccil.org" rel="noreferrer noreferrer noreferrer" target="_blank">cowan@ccil.or</a>g<br></div></div></div>
</blockquote></div></div></div>
</div>