<div dir="ltr"><div>tl;dr: our existing licenses are maybe not as global as we'd like to pretend; feels like that has implications for future license approvals (and maybe CAL) but I'm not sure what those implications are/should be.<br></div><div><br></div><div dir="ltr">On Tue, Jul 2, 2019 at 9:33 AM VanL <<a href="mailto:van.lindberg@gmail.com">van.lindberg@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><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 dir="ltr" class="gmail_attr">On Tue, Jul 2, 2019 at 8:20 AM Luis Villa <<a href="mailto:luis@lu.is" target="_blank">luis@lu.is</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 class="gmail_quote"><div>I dislike this, but the Federal Circuit would tell you that the APIs are expressive source code. <br></div></div></div></blockquote><div><br></div><div>If the API is part of the "Work" for copyright purposes, then copying the API is subject to copyleft *under any copyleft license, currently-accepted licenses included.*</div><div><br></div><div><snip><br></div><div><br></div>The argument against this was always that "the identified elements are statutorily excluded from copyright" under 17 USC 102. I don't think that is a sound legal position anymore.</div></div></blockquote><div><br></div><div>Whether it is a sound legal position depends on where you are. In US cases that also involve a patent, APIs would appear to be (currently) part of the work.<br></div><div><br></div><div>But that's also almost certainly not the case in the EU, per SAS/World Programming.<br></div><div><br></div><div>Presumably for most large licensees, the effect here is that the rule of the most-risk-creating jurisdiction is the one that applies, so we already have API copyleft whether OSI (and Larry ;) ) likes it or not.<br></div><div><div dir="ltr"><br></div><div dir="ltr">On Thu, Jun 27, 2019 at 6:03 AM Pamela Chestek <<a href="mailto:pamela.chestek@opensource.org" target="_blank">pamela.chestek@opensource.org</a>> wrote:<br></div><div class="gmail_quote"><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">License Review Committee Recommendation: </div></blockquote><div class="gmail_quote"><snip> <br><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"><ol><li>The mechanism of “public performance”: ... [T]his license uses a term specific to US
law, which is “public performance.” The use of of a term found
only in one jurisdiction’s body of law leads to the possibility
of highly disparate outcomes under other legal systems.</li></ol></div></blockquote><div>I agree that consistency is good - I've written at length on how <a href="https://lu.is/blog/2016/09/12/copyleft-and-data-database-law-as-poor-platform/">cross-jurisdiction inconsistency is extremely problematic in the data licensing context</a>, for example. And it's possible CAL crosses an articulable line that is more precise than the general "licenses should be consistent across jurisdictions" (see [1] below).<br></div><div><br></div><div>I think it is worth noting, though, that our existing licenses are not globally consistent. Beyond Van's point about changes in the underlying law impacting the terms of the license, there are problems as basic as those with 'distribute' noted by <a href="http://gplv3.fsf.org/denationalization-dd2.html" target="_blank">the GPL v3 drafting team</a>.
("Even within a single
country and language, the term distribution may be ambiguous...") And GPL v3 and MPL v2 both allow people to add additional warranty disclaimers because the drafters were pretty certain the existing disclaimers might be insufficient in certain jurisdictions or contexts. I'm sure there are others.<br></div><div><br></div><div>Anyway, I don't have any answers to this problem - it probably falls into the category of "things we have to live with". I'd just urge all of us to be cautious about cross-jurisdictional consistency as a mandatory requirement for new licenses when it's definitely not the case with existing licenses and arguably not possible even for the most basic of terms.</div><div><br></div><div>Luis<br></div><div><br></div><div>[1] I
think CAL's ambiguity around "public performance" is probably distinguishable from other license's ambiguity around "distribute": distribute is ambiguous because
widely-used and well-defined in other systems, but those definitions may be conflicting;
public performance ambiguous because not widely used and so undefined in
other systems. And this may be what the board had in mind when saying "the use of a term found only in one jurisdiction's body of law" rather than a different phrase. If that precision was intentional, kudos!<br></div></div></div></div></div></div>