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

[Mike Milinkovich]

Re-posting to License discuss

On 2022-12-13 2:26 p.m., Mike Milinkovich wrote:
> 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-discuss_lists.opensource.org/attachments/20221214/84909aac/attachment.html>