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

[Mike Milinkovich]

On 2022-12-12 5:40 p.m., Pamela Chestek wrote:
> On 12/12/2022 2:01 PM, Mike Milinkovich wrote:
>> Pam,
>>
>> Just to pipe in as a practitioner, not a lawyer. One of the major 
>> differences between EPL-1.0 and EPL-2.0 was the removal of the 
>> license's choice of law provision. We spent something like 15 years 
>> arguing that the certainty provided by the choice of law provision 
>> was valuable. I don't remember winning that argument once in all that 
>> time. In my experience, both adopters and contributors viewed the 
>> choice of law as a negative.
>>
>> I would also add that if you sort open source licenses by usage you 
>> will find that something like 95%++ of all free and open source 
>> software is currently made available under licenses which do not have 
>> a choice of law provision. So as a purely practical matter I consider 
>> this debate settled in favor of do not have a choice of law provision.
>>
> I don't disagree that it seems disfavored, but I was curious why, 
> especially after someone challenged me and I didn't have a good 
> answer. And the reason seems to still be ... just because? 

Pam,

I am coming at the question purely as a guy who for many years was 
essentially the steward of a license that had a choice of law provision 
and found it an unpleasant experience.

In my view, the purely pragmatic answers to "why are choice of law 
provisions in open source licenses disfavored" are:

 1. Many lawyers don't like them. In my experience there were lots of
    lawyers who found the EPL-1.0 USA-centric because of its choice of
    law provision and avoided it as a result. E.g. why would a German
    automaker want to contribute code under a license that stipulates US
    law when they go to great lengths to shield their company from US
    law? Telling them that the lawsuit could still proceed in a German
    court did not give them much comfort.

 2. Many lawyers don't pay attention to them. For example, I can think
    of multiple instances where lawyers insisted that the EPL-1.0 was a
    strong copyleft license because it relied upon the US Copyright
    Act's definition of derivative work (as indicated by the choice of
    law provision) rather than defining the term in the license. So
    instead they read the EPL-1.0 using the FSF's interpretation of
    derivative-work-includes-linking. Suffice it to say we vigorously
    disagreed with their interpretation, but we were never able to
    change their minds, even after pointing them directly at the US law.
    So for EPL-2.0 we cut-and-paste the definition of derivative work
    from the US law into the license to fix that. Go figure.

To summarize: as a practitioner, I found the EPL-1.0 choice of law 
provision to be a barrier to both contribution and adoption. Because of 
that direct personal experience, I believe such provisions are a bad idea.

And at the risk of belaboring the point, I do think that think the fact 
that 95%++ of all FLOSS code is published using licenses without a 
choice of law provision is a valid point and should not be dismissed as 
a "...just because". Further, I agree with Bradley on his point that if 
someone thinks that there are issues with the existing major licenses 
under German law we should be fixing /that /problem. I think approving a 
new license in 2023 that includes a choice of law provision is ... 
quaint. IMHO, it is an anachronism. Probably not a fatal flaw for 
approval because the OSI and/or this list has never come out firmly 
against such clauses. But I am sure that the Open Logistics Foundation 
relies upon large heaps of software using licenses which do not specify 
German law. Relying on that software while believing there is a 
fundamental flaw in their licenses seems like a contradiction, no?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20221213/49444e3d/attachment.html>