<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 15, 2019 at 3:00 PM VanL <<a href="mailto:van.lindberg@gmail.com">van.lindberg@gmail.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="auto">Hi Henrik,<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Thu, Aug 15, 2019, 6:16 AM Henrik Ingo <<a href="mailto:henrik.ingo@avoinelama.fi" target="_blank">henrik.ingo@avoinelama.fi</a>> wrote:</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 class="gmail_quote"><div><br></div><div>Forgive me, but that is just a redundant statement that is legal weasel wording. You're essentially still saying that if an API could be protected by copyright, in some jurisdiction, then the CAL would still claim those rights. In my understanding, the previous review round was fairly strongly against this.</div></div></div></blockquote></div><div dir="auto"><br></div><div dir="auto">I would have you know that I am 1/16 weasel. On my mother's side.</div><div dir="auto"><br></div></div></blockquote><div><br></div><div>:-)<br></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 dir="auto"><div dir="auto"></div><div dir="auto">More seriously, the CAL goes right up to the border of copyright, whatever that may be. I don't apologize for that. I understood the policy concern resulting from appearing to push the boundaries, so I removed that.[1] But the CAL makes the same bargain as other reciprocal licenses - and if I am correct about where the law will end up, has exactly the same scope.</div><div dir="auto"><br></div></div></blockquote><div><br></div><div>Ah. Thanks for this. It helps me be clearer:</div><div><br></div><div>I think in your previous review, there were two distinct objections:</div><div><br></div><div>1. Assuming that APIs are or should be copyrightable goes against policy goals of OSI / open source community</div><div>2. Even if APIs are - perhaps one day in the future - copyrightable in some jurisdiction, an open source license shouldn't assert those rights. At most it could be mentioned to grant such a right explicitly.</div><div><br></div><div>So I agree that you have addressed the first objection and was raising a concern about the second. Not all reviewers supported the second objection. I don't. Even then, I wouldn't support a license proposal that tries to sneak by such a significant new issue without being very explicit about it. In effect, that makes even myself opposed to asserting API copyright *at this point in time*, since I don't think it can be done explicitly (1) yet, and certainly wouldn't support a license trying to do it vaguely, like this version of CAL attempts to do.</div><div><br></div><div></div><div>So to make progress with CAL now, you would have to clearly retract any previous attempts to also have it cover APIs.<br></div><div></div><div><br></div><div>Also, we must be vary of the possibility that if we end up in a future 
where APIs can violate copyrights, then very likely there can exist 
software that is "Unrelated software" in the OSD sense, yet infringes 
copyright by law. An open source license cannot assert rights against 
such unrelated software.</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 dir="auto"><div dir="auto"></div>[1] My thinking here was motivated in part by some of my old writings criticizing the GPL FAQ for its interpretations that very much do push the boundaries of copyright, but are quoted as near-scripture and taken as authoritative. <div dir="auto"><br></div></div></blockquote><div><br></div><div>In fact, this remark is totally relevant. Like many, I agree that the FSF can be criticized for how it has expanded the reach of GPL by trying to expand the legal meaning of a derived work. While that wasn't a great idea, I do think that:</div><div><br></div><div> - It worked. Majority of open source users conform with the FSFs assertions, because they want to avoid legal risk, PR risk or "hassle".</div><div> - We/Me tolerate it, because we support and find the underlying goal reasonable, AND</div><div> - It's less of an issue because the same objective* could have been achieved by a different language which doesn't depend on the legal definition of a derived work.</div><div> - We may be more forgiving of such games when done by a non-profit for ideological reasons.<br></div><div><br></div><div>...so in essence the real problem is just an imperfection in GPL license text. (In reality of course it's a more complex issue. But also in reality this behavior from FSF is tolerated.)<br></div></div><div><br></div><div>*) By same objective I mean things like unambiguously requiring that dynamically linked libraries, or PNG files in Wordpress, are covered by the copyleft obligations, regardless of whether those are derived works of the GPLd code.</div><div><br></div><div>In your case...</div><div><br></div><div> - The risk is that being vague in the license and aggressive outside the license will also work!</div><div> - I don't support the underlying goal of making money and attacking competing implementations.</div><div> - I don't think your objective can be achieved with any text and also conform to "OSD and software freedom"</div><div> - See second point</div><div><br></div><div>henrik<br></div><br>-- <br><div dir="ltr" class="gmail_signature"><a href="mailto:henrik.ingo@avoinelama.fi" target="_blank">henrik.ingo@avoinelama.fi</a><br>+358-40-5697354        skype: henrik.ingo            irc: hingo<br><a href="http://www.openlife.cc" target="_blank">www.openlife.cc</a><br><br>My LinkedIn profile: <a href="http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7" target="_blank">http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7</a></div></div>