<div dir="ltr"><div dir="ltr"><div>Hi Richard,</div><div><br></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 13, 2019 at 10:56 AM Richard Fontana <<a href="mailto:rfontana@redhat.com">rfontana@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">On Thu, Aug 8, 2019 at 5:19 PM VanL <<a href="mailto:van.lindberg@gmail.com" target="_blank">van.lindberg@gmail.com</a>> wrote:<br>
<br>
If I understand correctly, this has the effect of replacing the<br>
language in the earlier version that would have imposed copyleft<br>
obligations on APIs by choosing not to address the issue head on<br>
(contrary to what I think you recommended that license drafters ought<br>
to do in an earlier thread).<br></blockquote><div><br></div><div>Well, I dealt with it head on and you (among others) objected, so I looked at other ways to accomplish my purpose. The language above is designed to be absolutely clear as to the scope of the license, regardless of how OvG turns out. Thus, regardless of any prognostication as to how things will turn out, no one can argue that I am pushing a policy point that is contrary to the OSI's interest. <br></div><div><br></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">
However, leaving aside the notion of API copyrightability, isn't this<br>
problematically broad? How do you reconcile it with OSD 9 ("The<br>
license must not place restrictions on other software that is<br>
distributed along with the licensed software.")?<br></blockquote><div><br></div><div>I'll defer that answer to Simon and McCoy, below. The language tracks very closely to what is a "derivative work" under US law, thus placing it squarely within the bounds of what has been already accepted.</div><div><br></div><div>Thanks,<br></div><div>Van<br></div><div> </div></div></div>