<div dir="ltr"><div>J.,</div><div><br></div><div>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.<br></div><div><br></div><div>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.<br></div><div><br></div><div>Eric<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Feb 14, 2021 at 2:35 PM J. Ritchey <<a href="mailto:x1x2c3%2Bosi@gmail.com">x1x2c3+osi@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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). <br><br>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.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Feb 14, 2021 at 11:47 AM Eric Schultz <<a href="mailto:eric@wwahammy.com" target="_blank">eric@wwahammy.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>J.,</div><div><br></div><div>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. <br></div><div><br></div><div>"[A]ny legal entity who receives material licensed under this license is granted ... permission to do anything LAWFUL with the material..."</div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>Eric<br></div><div><br></div><div>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.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Feb 14, 2021 at 12:50 PM J. Ritchey <<a href="mailto:x1x2c3%2Bosi@gmail.com" target="_blank">x1x2c3+osi@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.<br><br>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. <br><br>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. <br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Feb 14, 2021 at 4:17 AM Lukas Atkinson <<a href="mailto:opensource@lukasatkinson.de" target="_blank">opensource@lukasatkinson.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I would ask the Board to not approve this license: it leads to <br>
unnecessary license proliferation, and likely fails to provide <br>
sufficient software freedom.<br>
<br>
On a meta-level, the submission of this license makes a strong argument <br>
that submitted licenses should have either received legal review or at <br>
least non-negligible use.<br>
<br>
This license has neither: not even the license author seems to have <br>
published any works/“material” under this license, though a few social <br>
media posts reference earlier versions.<br>
<br>
The proliferation problem is enhanced by the lack of improvements over <br>
existing licenses. The submission identifies various differences, but I <br>
don't agree with their value.<br>
<br>
- The license text is not more comprehensible than comparable licenses. <br>
The license is grammatically complex. The terminology deviates from <br>
terms of art and well-understood phrases. Using “material” instead of <br>
“work” is not more inclusive, since “creative work” is a term of art.<br>
<br>
- I don't see how the proposed license would be better than Fair or 0BSD <br>
at ensuring that recipients know about their rights and obligations. <br>
This is especially relevant since recipients *do* have obligations per <br>
“The legal entity is responsible…”.<br>
<br>
- The blocklist vs allowlist approach is interesting, but has probably <br>
not been executed correctly. The licensee is allowed to do “anything <br>
lawful […] which does not violate this license”. But distribution of a <br>
copyrighted work is not lawful without permission. This “license” might <br>
not be granting any rights at all. Although the OSI has given legacy <br>
approval to unclear licenses in the past (hello, Unlicense), such <br>
approval would be unhelpful for new licenses.<br>
<br>
Aside from the lack of explicit permission, the choice of law clause is <br>
troubling, especially when paired with the inseverability clause. The <br>
choice of law might be ineffective as constructed. Since various parts <br>
of the license are likely “unenforceable in applicable jurisdictions”, <br>
this license cannot be accepted.<br>
<br>
_______________________________________________<br>
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 <a href="http://opensource.org" rel="noreferrer" target="_blank">opensource.org</a> email address.<br>
<br>
License-review mailing list<br>
<a href="mailto:License-review@lists.opensource.org" target="_blank">License-review@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" rel="noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a><br>
</blockquote></div>
_______________________________________________<br>
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 <a href="http://opensource.org" rel="noreferrer" target="_blank">opensource.org</a> email address.<br>
<br>
License-review mailing list<br>
<a href="mailto:License-review@lists.opensource.org" target="_blank">License-review@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" rel="noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Eric Schultz, Developer and FOSS Advocate<br></div><div><a href="http://wwahammy.com" target="_blank">wwahammy.com</a><br></div><div><a href="mailto:eric@wwahammy.com" target="_blank">eric@wwahammy.com</a><br></div><div>@wwahammy</div><div>Pronouns: He/his/him<br></div></div></div></div></div></div></div></div></div>
_______________________________________________<br>
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 <a href="http://opensource.org" rel="noreferrer" target="_blank">opensource.org</a> email address.<br>
<br>
License-review mailing list<br>
<a href="mailto:License-review@lists.opensource.org" target="_blank">License-review@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" rel="noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a><br>
</blockquote></div>
_______________________________________________<br>
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 <a href="http://opensource.org" rel="noreferrer" target="_blank">opensource.org</a> email address.<br>
<br>
License-review mailing list<br>
<a href="mailto:License-review@lists.opensource.org" target="_blank">License-review@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" rel="noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Eric Schultz, Developer and FOSS Advocate<br></div><div><a href="http://wwahammy.com" target="_blank">wwahammy.com</a><br></div><div><a href="mailto:eric@wwahammy.com" target="_blank">eric@wwahammy.com</a><br></div><div>@wwahammy</div><div>Pronouns: He/his/him<br></div></div></div></div></div></div></div></div></div>