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

Mon Feb 15 02:11:19 UTC 2021

J.,

The OSD requires you to not condition the license on lawful uses. I think
one could reasonably conclude that the license says the license is
conditioned on the user complying with the law. If that's the case, again
not a lawyer so maybe it's not the case, the license just is not going to
be approved under any circumstances.

I guess I'm still trying to understand a motivating reason for this
license. I appreciate that you don't like how a number of other licenses
are written but can you point to specific motivating, real-life examples of
where the current set of licenses have been harmful or inadequate in some
way? I ask once again because it would be helpful to know these problems.
It gives you and OSI and the broader community a path forward when this
license is, in all likelihood, rejected.

Eric

On Sun, Feb 14, 2021 at 2:35 PM J. Ritchey <x1x2c3+osi at gmail.com> wrote:

> I don't have the legal authority to permit unlawful usage, nor does any
> other open source license unless it's written by a government. This
> statement is there to provide the licensor protection against being charged
> as an accessory if someone does anyway. While previous versions of this
> license didn't explicitly state "lawful", this license has never been
> intended to endorse, or aid in the commission of crimes. Both of which, I'm
> sure are illegal in Canada (my home country).
>
> I decided to use a disallow vs allow approach in my license to reduce the
> gap between Public Domain freedoms (because I wouldn't have to think up
> every possible thing I want to allow), and the permissions granted by the
> license. I also wanted to reduce the dependence on definition of key terms
> used to allow actions (eg: I don't have to define a term if I haven't used
> it), as I want to keep the license small.
>
> On Sun, Feb 14, 2021 at 11:47 AM Eric Schultz <eric at wwahammy.com> wrote:
>
>> J.,
>>
>> Thanks for submitting your license. I'm not a lawyer but I believe your
>> license may fail to comply with the OSD. In particular, the first sentence
>> seems to limit the usage of licensed material to "lawful" purposes.
>>
>> "[A]ny legal entity who receives material licensed under this license is
>> granted ... permission to do anything LAWFUL with the material..."
>>
>> Perhaps some other part of the license mitigates that (again, not a
>> lawyer) but if it does not, this cannot comply with the OSD if the only
>> permitted uses are legal uses.
>>
>> You mentioned a number of decisions you made here. I think all of them
>> are understandable however if you had motivating examples to explain why
>> the decision was made. In particular could you explain the rationale behind
>> the blocklist/allowlist decision? Is there some motivating examples,
>> preferably based on real world legal issues, which could help all of us
>> understand the problems you're trying to address? Given the few responses
>> so far, I think the license will not be approved in its current state but
>> better understanding the problems you're trying to solve would help
>> everyone decide on next steps.
>>
>> Also, I would personally encourage you to be cautious using a license
>> which has not been formally written or reviewed by legal counsel with
>> considerable experience in open source software licensing. After all, just
>> as most lawyers would be unqualified to create a secure operating system
>> without expert help, most software developers would be unqualified to write
>> legal documents without expert help.
>>
>> Eric
>>
>> PS: While I'm sure you meant no disrespect, please do not use the terms
>> "whitelist/blacklist" here; many Black people consider that phrasing
>> offensive. Allowlist/Blocklist are recommended alternatives and would be
>> communicate the concept effectively.
>>
>> On Sun, Feb 14, 2021 at 12:50 PM J. Ritchey <x1x2c3+osi at gmail.com> wrote:
>>
>>> 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
>>>>
>>> _______________________________________________
>>> 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
>>>
>>
>>
>> --
>> Eric Schultz, Developer and FOSS Advocate
>> wwahammy.com
>> eric at wwahammy.com
>> @wwahammy
>> Pronouns: He/his/him
>> _______________________________________________
>> 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
>>
> _______________________________________________
> 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
>

-- 
Eric Schultz, Developer and FOSS Advocate
wwahammy.com
eric at wwahammy.com
@wwahammy
Pronouns: He/his/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20210214/b04fca73/attachment.html>