<div dir="ltr"><div>I came back to the license-review committee after a 10-year hiatus specifically to address <i>your </i>license. I think after you included me in an email. Thus OSI can not have been expected to have warned you about my weight :-) I don't think it would have been approved without me there.<br></div><div><br></div><div>We have had previous quite obnoxious and unambiguous proposers of legal action against OSI. Perhaps that has primed people for any trigger, I haven't been around to know.<br></div><div><br></div><div>I don't remember the specifics of the ethics issue in question, but I would not suggest that simple proposition of a license to this list would trigger any issue. I am concerned in general about the impact of this group's choices on the law-naive Open Source developer. Someone like Bob Jacobsen (v. Katzer) who I think initially used the original Artistic License and saw the lower court say it was a dedication to the public domain. Does this group create risk for that developer that the developer won't understand? When someone admitted to the Bar promotes his own license to a developer who is not his client, what is the lawyer's responsibility in law, and in ethics?</div><div><br></div><div>    Thanks</div><div><br></div><div>    Bruce<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 12, 2018 at 8:17 PM, Kyle Mitchell <span dir="ltr"><<a href="mailto:kyle@kemitchell.com" target="_blank">kyle@kemitchell.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2018-06-12 17:06, Bruce Perens wrote:<br>
> These are not OSI rules, but they're some clues for license submitters<br>
> about how I think the license review process should work.<br>
<br>
</span>One upshot of the L0-R license review process, on my end,<br>
was that Bruce throws significant weight.  There are many<br>
capable, independent thinkers on this list.  But there's<br>
little collective stomach for opposing the strongly worded<br>
opinions of old hands, or even for probing the reasons<br>
behind those views.  The published guide to the<br>
license-review process, which does claim to set out OSI<br>
rules, won't tell you that.<br>
<br>
My experience reinforced the impression that despite the<br>
excellent technical feedback that can be and will be had on<br>
license-review, the operative parts of the process turn more<br>
on personal prerogative and esteem than stewardship in a<br>
technical spirit.  I fully expect that view to be written<br>
off as sour grapes, though others have expressed it here,<br>
and not just when proposing licenses.<br>
<br>
If I could, I'd find a way around that impasse.  The old<br>
hands have a great deal to teach.  But that wisdom can't<br>
really be learned by receipt and recitation.  When old hands<br>
stop answering mailing lists---more than a few already<br>
have---we'll lose a great part of it.  A hundred hours in<br>
the mailing list archive won't make it clear.<br>
<span class=""><br>
> There are already too many Open Source licenses. If we never accepted<br>
> another, that would not be a particularly bad thing. OSI can't prevent<br>
> anyone from using such licenses, but some of us will make it clear if we<br>
> don't believe your license is Open Source.<br>
<br>
</span>Do not be shocked, during your license-review process, to<br>
see arguments to the effect that the process you've prepared<br>
for shouldn't exist to begin with.  And from several list<br>
participants.  Among whom you may be asked to develop<br>
consensus.<br>
<span class=""><br>
> A license is a sort of program designed to be executed by the courts.<br>
<br>
</span>A fun metaphor!  A favorite of mine, too.<br>
<br>
Unfortunately, the spec for American courts leaves much<br>
behavior undefined.<br>
<span class=""><br>
> If you have not made use of an attorney in drafting your license, you are very<br>
> unlikely to understand how the courts would actually execute your license.<br>
> The result would generally be harmful to Open Source developers who depend<br>
> on your license to work as they expect. I made up a name for these licenses<br>
</span>> some years ago: *Crayon Licenses,* from a Monty Python sketch in which a<br>
<span class="">> man has a cat license, with the word "dog" crossed out and "cat" written<br>
> in, in crayon.<br>
<br>
</span>I hadn't connected the phrase to the sketch!  Definitely one<br>
to borrow.  Thanks.<br>
<span class=""><br>
> Please don't submit crayon licenses, reviewers will not see<br>
> them as a good deal for the Open Source developer community, and are likely<br>
> to abandon the review process as soon as they understand that they're<br>
> crayon.<br>
<br>
</span>Feel free to discuss crayon licenses with lawyers privately.<br>
License drafters don't tend to share the view that the last<br>
good open source license has been written.  If you've<br>
stumbled on something interesting---in functionality or<br>
implementation---it may be worth refining, professionally.<br>
And of course maybe it won't, and that's a judgment all the<br>
professional will get to make.  Either way, be reasonable<br>
about how you propose your ideas and to whom, and manage<br>
your expectations.  We stay busy.<br>
<span class=""><br>
> Many of the presently accepted and newly submitted licenses are duplicative<br>
> of other accepted licenses in their effect, and exist solely because a<br>
> particular lawyer at a particular establishment was happier with their own<br>
> language. Our own attorneys may not concur that they are better. In<br>
> general, licenses that are duplicative of other licenses in their effect<br>
> should not be accepted any longer, unless it's to meet new developments in<br>
> case law or solve an obvious legal deficit. The combinatorial problem of<br>
> Open Source licenses has a cost for everyone.<br>
<br>
</span>I would _strongly_ recommend those involved in<br>
license-review stay open to old combinations of license<br>
features in new, plainer language.  More accessible drafting<br>
yields substantial lawyer-, cost-, and drama-reducing<br>
benefits.  Plain English legal drafting is making inspiring<br>
headway, as a craft.  Open source licensing shouldn't cut<br>
itself out of the benefits.<br>
<br>
There are also gains to be had from "branding" and<br>
historical affinities.  For example, OSI approved<br>
BSD+Patent.  I don't know that an _exact_ analog to the<br>
particular combination of permissive license and patent<br>
language chosen there existed before.  But the optics of,<br>
well, BSD plus patent language, do have special value.<br>
<span class=""><br>
> You are encouraged to withdraw or deprecate your own approved licenses.<br>
> There is no shame attached to this and you will be thanked, the field has<br>
> evolved and we've all learned since those licenses were submitted.<br>
<br>
</span>I think I know the answer, but for others referring later:<br>
<br>
Would you encourage new licenses duplicative of withdrawn<br>
and deprecated licenses?<br>
<span class=""><br>
> Many of the licenses submitted cater to the needs of the submitting<br>
</span>> organization at the *expense *of the broader Open Source community. If your<br>
<span class="">> license doesn't consider the broader developer community and its needs,<br>
> it's difficult to see why OSI should approve it. Some recently-submitted<br>
> licenses propose to create precedents which would in general be harmful for<br>
> the community.<br>
><br>
> A whole category of licenses has been submitted to push the boundaries of<br>
> Open Source beyond what was intended in the writing of the Open Source<br>
> Definition. These are not generally well-received by the reviewers. Many of<br>
> the proposed business methods result in something less than Open Source,<br>
> and there is little reason to support them.<br>
<br>
</span>I hold my lines here.<br>
<br>
On community interest:<br>
<br>
Conclusory statements of community interest, superseding the<br>
Definition and any drive to refine it transparently, belie<br>
OSI's stated approach to license approval, which would stand<br>
it on steadier ground.  As long as policy assessments trump<br>
the Definition, this process isn't primarily technical, but<br>
political.  The community OSI represents may not include<br>
your community.  The concerns of developers that motivate<br>
your proposal may not resonate.<br>
<br>
On OSD:<br>
<br>
Community compacts like the Definition matter insofar as the<br>
community can scrutinize them, understand them, and rely on<br>
common understanding.  Honoring that understanding, not<br>
revelation of original drafting intent, creates legitimacy.<br>
<br>
When my contracts turn out vague, ambiguous, or incomplete,<br>
process tries to suss out the common understanding of the<br>
parties who agreed to work under them.  My drafting<br>
experience doesn't trump anything, though it often helps<br>
decide how best to amend.  Where OSD is vague, ambiguous, or<br>
incomplete, likewise, open source needs debate, not decree.<br>
<br>
I've praised the Definition in high tones.  It's reached the<br>
true benchmark of a great operative document:  It's done<br>
decades of service, and still worth revising.<br>
<span class=""><br>
> Don't imply legal threats to the OSI or reviewers during the review<br>
> process. It never works and doesn't make you friends.<br>
<br>
</span>Was my mention of tax-exemption received as a threat?  It<br>
wasn't intended that way.  I don't want to see OSI involved<br>
in any issue of the kind, a hot topic in the practice<br>
community at present.<br>
<br>
When a small part of our conversation triggered an<br>
issue-spotting reflex, I mentioned it.  I built that reflex<br>
advising clients, but OSI isn't my client, so I also had to<br>
made clear the org would need to keep its own counsel.<br>
There _was_ a tinge of self-interest:  I didn't want to<br>
appear, on a public mailing list, as a lawyer leading a<br>
non-profit into touching a rail non-lawyers may not<br>
recognize as hot.<br>
<br>
At the same time, in private correspondence on L0-R, I<br>
received messages asking how I couldn't be brought up on<br>
legal-ethics charges for proposing L0-R.  That wasn't<br>
pleasant, but I didn't read too much into it.  I don't now.<br>
<br>
In the end, my work is words, and I want to take full<br>
responsibility for my part in any painful miscommunication.<br>
I sincerely apologize if I caused anxiety, especially for<br>
those with unpleasant prior experience of legal disputes.<br>
<span class="HOEnZb"><font color="#888888"><br>
-- <br>
Kyle Mitchell, attorney // Oakland // (510) 712 - 0933<br>
<br>
______________________________<wbr>_________________<br>
License-review mailing list<br>
<a href="mailto:License-review@lists.opensource.org">License-review@lists.<wbr>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/<wbr>mailman/listinfo/license-<wbr>review_lists.opensource.org</a><br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Bruce Perens K6BP - CEO, Legal Engineering<br>Standards committee chair, license review committee member, co-founder, Open Source Initiative<div>President, Open Research Institute; Board Member, Fashion Freedom Initiative.<br></div></div></div></div></div></div></div>
</div>