[License-discuss] [License-review] in opposition of 'choice of law' provisions in FOSS licenses (was: For Approval: Open Logistics License v1.2)

Richard Fontana rfontana at redhat.com
Tue Dec 13 18:08:43 UTC 2022


(moving this reply to license-discuss)

On Tue, Dec 13, 2022 at 11:41 AM Bradley M. Kuhn <bkuhn at ebb.org> wrote:
>
> Eric Schultz wrote:
> > We already have a number of approved licenses with a choice of law clauses.
>
> First, is there an approved license that chooses a *specific*, *named*
> jurisdiction? (There may be, it's just hard to find if there is, as OSI's
> website seems to have no discussion of “choice of law”, and/or why some
> licenses have it and others don't?  Or did I miss it?)  The “precedents”
> mentioned so far in this thread: CDDL (in some ways worse, in some ways
> better) has a “each new project chooses its own jurisdiction”; Mike already
> noted that EPL has dropped is “choice of law” clause; Larry already noted
> that his license anchors choice of law to “Licensor” location.

Aside from EPL 1.0 (and I assume its ancestors), probably the most
significant one historically is MPL 1.1 and its ancestors (California)
and, without checking, I'd assume most or all of its mostly forgotten
OSI-approved vanity license derivatives. However, MPL 2.0 says "Any
litigation relating to this License may be brought only in the courts
of a jurisdiction where the defendant maintains its principal place of
business and such litigation shall be governed by laws of that
jurisdiction, without reference to its conflict-of-law provisions."

There are probably also choice-of-law provisions naming specific
jurisdictions in various less significant or otherwise more or less
obsolete OSI-approved licenses. For example, the Q Public License has
the following choice of law and venue clause: "This license is
governed by the Laws of Norway. Disputes shall be settled by Oslo City
Court." The variant of the QPL that was formerly used by OCaml (long
after Qt stopped using the QPL), Fedora recently discovered, changes
this to say "This license is governed by the Laws of France." (SPDX
has an open issue to see whether this justifies the need for a new
license identifier. While OCaml switched away from the QPL derivative
several years ago, OCaml-QPL-licensed source code survives in other
projects.)

> Second, while you do point out a problem with the OSI process that is indeed
> unfair to submitters, the unfairness is baked into OSI's design of this
> process.  Specifically, (AFAICT from <https://opensource.org/approval>) there
> is *still* no way to appeal decisions of license approval once OSI makes
> them.  IOW, there is no appeals or supreme court of OSI license approval
> (despite many suggestions, including from past OSI Directors, over the years
> that one be created).  There is *just* this process, on this mailing list,
> that happens *only* when a license is submitted for approval.  After a
> license is approved, it's approved forever, and then it can be used as
> precedent forever without any opportunity for reconsideration [0].  OSI
> Directors and leadership leave, the reasoning that a given license was
> acceptable isn't published, and various terms get grandfathered in without
> any justification or treatise published.  The next submitter comes along and
> says: “I should get this clause OSI-approved because this other one is”.

These are good criticisms, but just want to note that Pam has done a
good job of trying to articulate rationale for approval decisions over
the past couple of years.

> [0] Admittedly, the license steward can submit to “delist” their own
>     license(s), but the license steward is obviously a biased party.  I also
>     note the process as a whole is somewhat biased in another direction:
>     toward licenses that have a traditional, single-organizational license
>     steward.

I've been suggesting that the OSI should have a dis-approval or
delisting process, capable of being initiated by someone other than
the license steward, for a long time, but the OSI has been pretty
resistant to this idea.

Richard




More information about the License-discuss mailing list