[License-review] Request - For Approval - Ritchey Permissive License v11

[J. Ritchey]

I have published many things under the Ritchey Permissive License. It's the
default license I have used for about half a decade now. But v11 has only
just come out. My most recent publicly available works are still on v10.

In regards to the terms "works" and "material", I was actually making the
point that those terms are more inclusive than the term "software" which is
the term of choice in all other licenses I was comparing to. But also that
the difference in common definition between "works" and "material" could be
important to users since neither license includes definition of these
terms.

In regards letting recipients know about their rights and obligations, this
license doesn't try to do a better job. It tries to provide better
protection for the licensor against indirect licensees who never see the
disclaimer statements.

On Sun, Feb 14, 2021 at 4:17 AM Lukas Atkinson <opensource at lukasatkinson.de>
wrote:

> I would ask the Board to not approve this license: it leads to
> unnecessary license proliferation, and likely fails to provide
> sufficient software freedom.
>
> On a meta-level, the submission of this license makes a strong argument
> that submitted licenses should have either received legal review or at
> least non-negligible use.
>
> This license has neither: not even the license author seems to have
> published any works/“material” under this license, though a few social
> media posts reference earlier versions.
>
> The proliferation problem is enhanced by the lack of improvements over
> existing licenses. The submission identifies various differences, but I
> don't agree with their value.
>
> - The license text is not more comprehensible than comparable licenses.
> The license is grammatically complex. The terminology deviates from
> terms of art and well-understood phrases. Using “material” instead of
> “work” is not more inclusive, since “creative work” is a term of art.
>
> - I don't see how the proposed license would be better than Fair or 0BSD
> at ensuring that recipients know about their rights and obligations.
> This is especially relevant since recipients *do* have obligations per
> “The legal entity is responsible…”.
>
> - The blocklist vs allowlist approach is interesting, but has probably
> not been executed correctly. The licensee is allowed to do “anything
> lawful […] which does not violate this license”. But distribution of a
> copyrighted work is not lawful without permission. This “license” might
> not be granting any rights at all. Although the OSI has given legacy
> approval to unclear licenses in the past (hello, Unlicense), such
> approval would be unhelpful for new licenses.
>
> Aside from the lack of explicit permission, the choice of law clause is
> troubling, especially when paired with the inseverability clause. The
> choice of law might be ineffective as constructed. Since various parts
> of the license are likely “unenforceable in applicable jurisdictions”,
> this license cannot be accepted.
>
> _______________________________________________
> The opinions expressed in this email are those of the sender and not
> necessarily those of the Open Source Initiative. Communication from the
> Open Source Initiative will be sent from an opensource.org email address.
>
> License-review mailing list
> License-review at lists.opensource.org
>
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20210214/25b96fb6/attachment-0001.html>