I suspect that the conversation is getting snagged on a false dichotomy:
enforceability is not in fact a binary characteristic of a license, only
of a license in the context of a specific dispute, with specific
plaintiff and respondent, in a specific jurisdiction, on specific facts,
at a specific phase of a legal process (trial vs. appeal), etc. The
temptation to leap from "a license cannot be intrinsically enforceable"
to "nothing can be known pre facto about a license's enforceability" is
an erroneous one. The temptation to shoehorn into simple to understand
discrete categories (particularly binary ones) is strong and often
valuable, but also often incorrect, as in this case.
This problem is not unique to F/OSS licensing, it applies to all legal
drafting[1]. The reasonable response is not to throw one's hands into
the air and declare that because perfection is not possible, therefore
no worthwhile outcomes can be achieved. It's to draft diligently.
For OSI I'd suggest that this means that a candidate license could
reasonably declined with a recommendation to work with a legal
professional to tighten up the drafting, if it is apparent during review
that there are substantial omissions of conventional drafting practice.
(Obviously, "substantial omissions" *also* doesn't fall neatly into
yes/no categories. Subjective judgement is required.)
- Roland
1: It applies to all human creative endeavours in fact, even to
programming where sometimes things can't readily be shoehorned into neat
categories so some creativity must be employed to produce a
useful-if-inelegant solution.
------------------------------------------------------------------------
On 26/10/23 07:47, Nicholas Matthew Neft Weinstock wrote:
That's a really interesting way of looking at it:
In order to be within the OSD, the license needs to be actually capable of
granting the necessary rights/licenses.
That's certainly true in other contexts. If the license only grants the right
to COPY but not MODIFY or DISTRIBUTE, it doesn't grant the rights necessary to
satisfy the OSD.
The same makes sense in the question of enforceability. If the license is not
able to grant the necessary rights because it is unenforceable, how can it
grant the rights necessary to satisfy the OSD?
On the other hand, the difficulty in this analysis is that some matters of
enforceability might change over time. If a provision was enforceable when OSI
approved the license, and then the law changed and it is no longer enforceable,
does the license status change? How would that be identified, determined and
enforced? Or if a license was rejected due to lack of enforceability, and then
the law caught up and the relevant provision is suddenly enforceable, would it
be eligible for reconsideration?
Maybe there are two sub-categories of "enforceability." So if a provision is
so poorly written as to be unenforceable, that's something to consider. But if a
provision is written well and it's a question of legality, this should not be considered.
-Nick
-----Original Message-----
From: License-discuss<license-discuss-boun...@lists.opensource.org> On Behalf
Of Josh Berkus
Sent: Wednesday, October 25, 2023 1:26 PM
To:license-discuss@lists.opensource.org
Subject: Re: [License-discuss] Evaluating the Enforceability of a License
Should Not be a Criteria for OSI License Review
WARNING: This email originated from outside of Qualcomm. Please be wary of any
links or attachments, and do not enable macros.
On 10/7/23 22:25, Patrick Schleizer via License-discuss wrote:
>
> Concerns regarding the enforceability of a license, especially across
> different jurisdictions, should not be a determinant in the approval
> or rejection of a license. Enforceability can vary significantly
> across different regions due to the diverse legal landscapes, making
> it a less consistent metric for license review. The issue lies in the
> fact that enforceability is largely subjective and lacks an
> independent, quick reproducible testing framework
Nothing else in the OSD includes an "independent, quick[ly] reproduceable testing
framework". Why should enforceability?
Nor can you separate enforceability from OSD evaluation. If the license
complies with the OSD only by means of legal text that is unenforceable in a
majority of the world, then it doesn't comply with the OSD. The author's
intent doesn't matter if they weren't successful.
We also regularly have licenses submitted that aren't written with legal advice
and are so poorly drafted that they would not be enforceable anywhere at all.
Do you really think that the OSI should approve these?
--
Josh Berkus
_______________________________________________
The opinions expressed in this email are those of the sender and not
necessarily those of the Open Source Initiative. Official statements by the
Open Source Initiative will be sent from an opensource.org email address.
License-discuss mailing list
License-discuss@lists.opensource.org
http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
_______________________________________________
The opinions expressed in this email are those of the sender and not
necessarily those of the Open Source Initiative. Official statements by the
Open Source Initiative will be sent from an opensource.org email address.
License-discuss mailing list
License-discuss@lists.opensource.org
http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
_______________________________________________
The opinions expressed in this email are those of the sender and not
necessarily those of the Open Source Initiative. Official statements by the
Open Source Initiative will be sent from an opensource.org email address.
License-discuss mailing list
License-discuss@lists.opensource.org
http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
