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

J. Ritchey x1x2c3+osi at gmail.com
Sun Feb 21 20:21:17 UTC 2021


I never claimed the BSD is copyleft, and it isn't. Nore is my license.

On Sun, Feb 21, 2021 at 12:18 PM McCoy Smith <mccoy at lexpan.law> wrote:

> You rather conspicuously avoided the sections discussing BSD, which is the
> license you claim is copyleft and upon which you claim you model your
> license. Citing GPL as copyleft doesn’t address the point.
>
>
>
> *From:* License-review <license-review-bounces at lists.opensource.org> *On
> Behalf Of *J. Ritchey
> *Sent:* Sunday, February 21, 2021 12:11 PM
> *To:* License submissions for OSI review <
> license-review at lists.opensource.org>
> *Subject:* Re: [License-review] Request - For Approval - Ritchey
> Permissive License v11
>
>
>
> "By law (in the USA and in most other jurisdictions), the copyright holder
> (most typically, the author) of the work controls how others may copy,
> modify and/or distribute the work." -
> https://copyleft.org/guide/monolithic/
>
> "The Innovation of Optional “Or Any Later” Version [...]  Copyright
> holders using those licenses seems to find it acceptable to fully delegate
> all future licensing decisions for their copyrights to these organizations
> without a second thought." - https://copyleft.org/guide/monolithic/
>
> "many existing copylefted projects continue with GPLv2-only" -
> https://copyleft.org/guide/monolithic/
>
> "copyright statutes generally require permission from the copyright holder
> to grant explicit permission to modify a work in any manner. As discussed
> in the next chapter, the GPL does grant such permission, but requires the
> modified work must also be licensed under the terms of the GPL" -
> https://copyleft.org/guide/monolithic/
>
> "the copyright holder of a particular software program has the prerogative
> to grant alternative agreements under separate copyright licenses. " -
> https://copyleft.org/guide/monolithic/
>
> "GPLv2 did not permit any additional requirements. However, over time,
> many copyright holders generally tolerated certain types of benign
> additional requirements"  - https://copyleft.org/guide/monolithic/
>
> "LGPLv2.1 is in essence a permissive variant of GPLv2, and it permits
> relicensing under the GPL" - https://copyleft.org/guide/monolithic/
>
> Even the document you've referenced supports my statement that you cannot
> take someone else's creative work that is protected by Copyright, and
> distribute it under a different license without permission. The Copyright
> holder has authority over what you can do. For example, when licensing a
> work with the GLPv3 the licensor can use the "or any later version"
> statement to grant licensees permission to use newer versions of the GLP as
> well. The LGPLv3 has a similar feature.
>
>
>
>
>
> On Sun, Feb 21, 2021 at 10:40 AM McCoy Smith <mccoy at lexpan.law> wrote:
>
> “All it states is this stuff is under this license, and you can't change
> that. This is common. For example the 3-Clause BSD license requires all
> code to remain under the 3-Clause BSD license.”
>
> You keep making this incorrect assertion. You might want to read up on
> this a bit, for example, something co-authored by the very person to whom
> you are making this assertion:
>
> https://copyleft.org/guide/monolithic/
>
> You’re not really helping your cause by continuing to try to dispute
> points that you should instead concede.
>
>
>
> *From:* License-review <license-review-bounces at lists.opensource.org> *On
> Behalf Of *J. Ritchey
> *Sent:* Sunday, February 21, 2021 10:27 AM
> *To:* License submissions for OSI review <
> license-review at lists.opensource.org>
> *Subject:* Re: [License-review] Request - For Approval - Ritchey
> Permissive License v11
>
>
>
> Because the license is designed to be short, it doesn't define terms (eg:
> "lawful"). Instead it binds to a jurisdiction to set precedence for how a
> term may be interpreted. For example the Copyright Act itself uses the
> terms lawful, unlawful, and lawfully. So does the Criminal Code. The term
> lawful is also used in the Constitution Acts going back as far as 1867.
> It's important to note that none of these define the term either, but they
> are citable examples of established use. In comparable licenses which don't
> bind to a jurisdiction, or include definitions, a term might seem clear to
> the reader, and then be interpreted differently by the law, especially if
> the licensor, and licensee are from different places. In this instance,
> lawful would seem to mean permitted by law which is the intent. As for what
> actions would be considered lawful, that would depend on what is being
> licensed, because that determines which laws are relevant. If you're using
> the license on a copyrighted work then the Copyright Act would be
> applicable to what is lawful. On a patented work the Patent Act would be.
> Etc. You do raise a good point though that it's questionable whether the
> license is actually extending rights defined in such acts, or merely
> reminding people they have to adhere to them.
>
> Section 6 of the OSD states "must not restrict anyone from making use of
> the program in a specific field of endeavor". Cambridge Dictionary defines
> endeavour as "to try to do something". By that definition prohibiting
> unlawful activities would be a violation. This would also mean that nearly
> every other OSI approved license violates section 6 too though. Nearly all
> OSI approved licenses require retention of license text in copies, and
> restrict licensees to redistributing under the same license. Not doing so
> is unlawful in accordance with Copyright law, but these licenses
> discriminates against that unlawful endeavor. Some licenses such as the
> 3-Clause BSD license also require binaries to display a notice. Not doing
> so is unlawful, and requiring users to prohibits trying to do something. So
> aside from the Zero-Clause BSD License there probably aren't any OSI
> approved licenses that don't to some extent violate section 6 of the OSD.
>
> This license does go far beyond the typical disclaimers. As another member
> mentioned, sometimes things can't be disclaimed. This license uses a
> security in layers approach to try and protect the licensor in that event
> by shifting responsibilities downstream. So long as each person in the
> chain retains the license text when distributing, they'll have disclaimers
> protecting them. If they don't, they'll hopefully only be putting
> themselves at risk since they inherited that responsibility. Some people
> may not desire that from a license, but that's what having different
> licenses is for; providing a selection. If anything this unique feature is
> proof that this license is bringing something new to the table, and not
> just duplicating what's already there.
>
> The phrase "the material" is used consistently through the document, and
> first appears in the statement "receives material licensed under this
> license [...] the material" so by reference it has inferred "the material"
> means content the licensee received under these terms. In a legal dispute
> that pattern of use may be cited to clarify the meaning. It also doesn't
> contain any statements which infer or state further restrictions such as
> terms regarding other peoples' work, or the sorts of projects it can be
> included in. All it states is this stuff is under this license, and you
> can't change that. This is common. For example the 3-Clause BSD license
> requires all code to remain under the 3-Clause BSD license.
>
> Binding of the license to a jurisdiction isn't about ignoring that a
> particular jurisdiction might be inconvenient to some users. Quite the
> opposite. It's about minimizing the risk of the licensor since they're the
> one taking the greatest risk by sharing their work freely. When you buy a
> product from a company, and sue them for damages they may have disclaimers
> or limitations to protect them, but if those fail they have their profits
> to pay legal fees, and payouts with. People giving their work away for free
> to the open source community don't, so they may want greater protections.
> This license tries to provide that. Imagine being sued in one of those
> countries with unjust laws you hinted at.
>
> Whether or not I agree with your reading of the statements is irrelevant.
> As the author, my interpretation is biased. I appreciate your detailed
> feedback.
>
>
>
> On Sat, Feb 20, 2021 at 12:11 PM Pamela Chestek <pamela at chesteklegal.com>
> wrote:
>
> Speaking personally, not in my role with OSI.
>
> I find the license insolubly ambiguous.
>
> In the phrase "permission* to do anything lawful *with the material which
> does not violate this license" the concept of lawfulness begs the question.
> By not saying what is a lawful use, we have no way of knowing what an
> unlawful use would be. Someone could say "I meant only to allow you to
> distribute the software, not modify the software, and modifying is unlawful
> under copyright law so you are therefore in breach of this license." Maybe
> your intention is to allow all permitted uses under copyright law. But what
> about patent law? What about moral rights? Copyright and patent are
> exclusionary rights, so by not saying what *is *allowed, i.e., what you
> have made lawful by the grant of the license, we are left only to guess. It
> is completely unworkable.
>
> Others have pointed out a different interpretation of the "lawful" term,
> which is that one cannot use the software in ways that break the law. This
> is a clear violation of OSD6, no discrimination against fields of endeavor.
> It's easy to say that it's a good thing to prohibit unlawful uses, but what
> about laws in some countries that violate fundamental human rights?
>
> "The legal entity is responsible for all consequences of sharing the
> material, and all obligations to recipients (including warranties,
> liabilities, representations, obligations, damages, and guarantees)." So
> you are saying that the licensee has the legal obligation to provide a
> warranty and indemnify the licensor from liability for any of the
> licensor's misrepresentations, obligations, damages and guarantees? That,
> no matter what the licensor's wrongdoing, it is the licensee who has to
> take on the legal burden of it instead of the licensor? That is far beyond
> any other open source license - disclaimers of liability for everyone are
> allowed, and an entity can voluntarily choose to take on a duty, like
> offering a warranty, but forcing it on the licensee is unacceptable in my
> view. And what about the next downstream, does that person accumulate the
> liability from everyone that is upstream of them? You stated in your
> rationale that there is not requirement that this license be included with
> the distribution, but you have replaced it with something far more
> draconian.
>
> "The material must entirely remain solely under this license." You have
> claimed that this license is similar to the permissive licenses like BSD
> and MIT. However, the phrase "remain solely under this license" can be read
> to mean "and not any other license," i.e., you cannot combine software
> under this license with any software that also militates compliance with a
> different license, most notably the GPL. So it creates a license
> incompatibility issue. License incompatibility in and of itself is not a
> reason to reject the license, but the fact that the wording can be read
> both ways means it has insufficient clarity.
>
> Other's have discussed the improvidence of have a mandatory jurisdiction
> for claims. Your statement that the license may therefore not be appealing
> to those outside of Canada ignores that there are two parties to a license,
> the licensor, who might be in Canada, but your users will be all over the
> world and you are forcing them into a venue that may be impossible for them.
>
> You will undoubtedly disagree with my reading of your sentences. However,
> the fact that I can read them differently from what you intended shows what
> others have said, writing an unambiguous license, particularly a short one,
> requires special skills. I believe this license is unacceptable.
>
> Pam
>
> Pamela S. Chestek
>
> Chestek Legal
> PO Box 2492
> Raleigh, NC 27602
> 919-800-8033
> pamela at chesteklegal.com
> www.chesteklegal.com
>
> On 2/13/2021 7:30 PM, J. Ritchey wrote:
>
> Submitting 'Ritchey Permissive License v11' for approval.
>
> License Text:
>
> Ritchey Permissive License v11:
>
> Subject to the terms of this license, any legal entity who receives
> material licensed under this license is granted royalty-free, perpetual,
> non-exclusive, permission to do anything lawful with the material which
> does not violate this license. Permissions are automatically revoked
> permanently from the legal entity upon breach of this license. The material
> is provided "as is", without implied fitness for any purpose. All
> obligations to the legal entity (including warranties, liabilities,
> representations, obligations, damages, and guarantees) are disclaimed by
> all parties involved (including the authors, rights holders, copyright
> holders, patent holders, and providers of the material). The legal entity
> is responsible for all consequences of sharing the material, and all
> obligations to recipients (including warranties, liabilities,
> representations, obligations, damages, and guarantees). The material must
> entirely remain solely under this license. This license is governed by the
> laws of the province of British Columbia (as they were on April 21, 2019),
> and the applicable laws of Canada (as they were on April 21, 2019). Any
> legal proceedings related to this license may only occur in the courts of
> British Columbia. The legal entity must be capable of being bound to this
> entire license, and agrees to be. If any portions of this license are
> unenforceable in applicable jurisdictions, this license cannot be accepted.
> The license text is provided under these terms.
>
>
> Rationale:
> First released in 2015 *(then named Comprehensible Open License)*, the
> Ritchey Permissive License aims to provide wide permissions, and ask little
> in return. It also strives to use plain language where possible *(this
> was the inspiration for its original name, and originally was prioritized
> above all else)*, and limit its size. The goals of this license are not
> unique, but the manner in which they are achieved is. That's what makes it
> a useful alternative to existing options, and is my rationale for
> submitting it.
>
> Distinguish:
> In terms of comparison to already OSI approved licenses, the Ritchey
> Permissive License v11 is most similar to the Zero-Clause BSD, ISC License
> (ISC), MIT No Attribution License, Fair License (Fair), MIT License, and
> 2-Clause BSD License. These licenses are all short, and grant wide
> permissions. But there are important differences.
>
> Like the Zero-Clause BSD license, and MIT No Attribution License, this
> license does not require a copy of the license to be included when
> distributing a work. This feature could result in downstream recipients of
> a work never seeing important disclaimers. Unlike the Zero-Clause BSD, and
> MIT No Attribution License, this license tries to provide some protection
> against that by shifting these responsibilities to the person sharing the
> work.
>
> Like the Zero-Clause BSD, Fair License (Fair), ISC License (ISC), MIT
> License, and 2-Clause BSD License it provides wide permissions. However
> they use a whitelist approach (eg: you can do x, y, z), and this license
> uses mostly a blacklist approach (eg: you can't do x, y, z). This
> difference is important, because x, y, and z may not be interpreted as
> intended. A whitelist approach prioritizes protecting a work. A blacklist
> approach prioritizes protecting the freedom of people to use the work. The
> MIT No Attribution License uses a blacklist approach, but the difference in
> wording may make one license more appealing than the other to potential
> users.
>
> Like the Fair License (Fair) which refers to products as "works" the
> Ritchey Permissive License v11 uses the inclusive term "material" so that
> the license can be better used with things beyond software (eg:
> documentation, icon packs, etc). The difference in the definitions of these
> terms may make one license more desirable over the other to potential users.
>
> Like the Zero-Clause BSD, ISC License (ISC), Fair License (Fair), MIT
> License, and 2-Clause BSD License the Ritchey Permissive License v11 is a
> short license that doesn't include a definitions section like larger
> licenses do. Unlike them, it binds itself to a jurisdiction, setting a
> basis for how terms may be interpreted.
>
> Legal review:
> No legal review of this license has been done. None is planned.
>
> Proliferation Category:
>
> I suggest the "Other/Miscellaneous licenses" category, because of its ties
> to Canadian law. While the license isn't made for Canadians, this link may
> limit its appeal to foreigners.
>
>
>
> In summary, the Ritchey Permissive License v11 is similar to existing
> options, but differences in features, or wording make it a useful
> alternative. That's why it was made.
>
>
>
> _______________________________________________
>
> 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
>
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20210221/91af45f0/attachment-0001.html>


More information about the License-review mailing list