<div dir="ltr"><div dir="ltr">Hi Pam - and cc'ing Richard to this reply -<br></div><div><br></div><div>Thanks to both of you for the feedback.<br></div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 14, 2019 at 7:45 AM Pamela Chestek <<a href="mailto:pamela@chesteklegal.com">pamela@chesteklegal.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 bgcolor="#FFFFFF">
    I would also comment that I think you have underplayed the
    significance of the scope of copyleft question by characterizing it
    as a "legal mechanism" question. You have not mentioned below that
    this license requires that any newly-written software that
    implements the same APIs must also be under and open source license.
<a class="gmail-m_-5243457095422162233moz-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>
    That is a new concept; no copyleft license requirement has been
    applied to code written from scratch. I don't read the thread,
    particularly Richard and Henrik's emails, as suggesting that public
    performance is per se the problem, but rather the concept altogether
    is, no matter how it is implemented.<br></div></blockquote><div><br></div><div>This is a good point, although I think it is logically separate from the public performance question. The public performance question is largely around the network effect of the copyleft and is basically an alternative-but-similar mechanism to AGPL's "network interaction" language.</div><div><br></div><div>The API question is separate and keys on OvG, not on public performance. It has to do with the proper interpretation of "What is a derivative work" under copyright law, which is applicable both in the network and non-network context. There are two subpoints here:</div><div><br></div><div>- The applicability and scope of API copyright in light of OvG:</div><div>    Argument: OvG is limited on its terms, and is avoidable.</div><div>    Response: We are already seeing preferential filing of copyright cases with patents to reach the Federal Circuit, and I have seen application of the OvG concept in new licenses. This precedent is unavoidable unless the Fed. Cir's decision is completely gutted by the SCt (which is possible, but I think unlikely). This may not be the ideal world, but it is the one we live in. <br></div><div><br></div><div>- Is the application of copyright to APIs good policy:</div><div>    Argument: This is bad policy, or at best premature; we should not be a first mover.</div><div>    Response: While API copyright can be misused, it is structured here to increase software freedom (yes-this point is debatable). More broadly, if copyright is recognized in APIs, that is an issue for courts to interpret. It is better to deal with it explicitly-either claiming it and using it, like the CAL, or disclaiming it, as Richard advocates-rather than just letting it hang out as an unknown.</div><div><br></div><div>I would also generally bring up the patent issue again; patent law is a completely separate chain of legal reasoning that also supports all the elements above.<br></div><div><br></div><div>Thanks,<br></div><div>Van<br></div><div><br></div><br></div></div>