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.
On Tue, Jul 2, 2019 at 9:33 AM VanL <van.lindb...@gmail.com> wrote: > On Tue, Jul 2, 2019 at 8:20 AM Luis Villa <l...@lu.is> wrote: > >> I dislike this, but the Federal Circuit would tell you that the APIs are >> expressive source code. >> > > 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.* > > <snip> > > 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. > 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. But that's also almost certainly not the case in the EU, per SAS/World Programming. 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. On Thu, Jun 27, 2019 at 6:03 AM Pamela Chestek < pamela.ches...@opensource.org> wrote: > License Review Committee Recommendation: > <snip> > > 1. 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. > > I agree that consistency is good - I've written at length on how > cross-jurisdiction inconsistency is extremely problematic in the data licensing context <https://lu.is/blog/2016/09/12/copyleft-and-data-database-law-as-poor-platform/>, 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). 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 the GPL v3 drafting team <http://gplv3.fsf.org/denationalization-dd2.html>. ("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. 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. Luis [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!
_______________________________________________ License-discuss mailing list License-discuss@lists.opensource.org http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
