<div dir="ltr">These are not OSI rules, but they're some clues for license submitters about how I think the license review process should work.<div><br></div><div>There are already too many Open Source licenses. If we never accepted another, that would not be a particularly bad thing. OSI can't prevent anyone from using such licenses, but some of us will make it clear if we don't believe your license is Open Source.</div><div><br></div><div>A license is a sort of program designed to be executed by the courts. If you have not made use of an attorney in drafting your license, you are very unlikely to understand how the courts would actually execute your license. The result would generally be harmful to Open Source developers who depend on your license to work as they expect. I made up a name for these licenses some years ago: <i>Crayon Licenses,</i> from a Monty Python sketch in which a man has a cat license, with the word "dog" crossed out and "cat" written in, in crayon. Please don't submit crayon licenses, reviewers will not see them as a good deal for the Open Source developer community, and are likely to abandon the review process as soon as they understand that they're crayon.</div><div><br></div><div>Many of the presently accepted and newly submitted licenses are duplicative of other accepted licenses in their effect, and exist solely because a particular lawyer at a particular establishment was happier with their own language. Our own attorneys may not concur that they are better. In general, licenses that are duplicative of other licenses in their effect should not be accepted any longer, unless it's to meet new developments in case law or solve an obvious legal deficit. The combinatorial problem of Open Source licenses has a cost for everyone.</div><div><br></div><div>You are encouraged to withdraw or deprecate your own approved licenses. There is no shame attached to this and you will be thanked, the field has evolved and we've all learned since those licenses were submitted.</div><div><br></div><div>Many of the licenses submitted cater to the needs of the submitting organization at the <i>expense </i>of the broader Open Source community. If your license doesn't consider the broader developer community and its needs, it's difficult to see why OSI should approve it. Some recently-submitted licenses propose to create precedents which would in general be harmful for the community. </div><div><br></div><div>A whole category of licenses has been submitted to push the boundaries of Open Source beyond what was intended in the writing of the Open Source Definition. These are not generally well-received by the reviewers. Many of the proposed business methods result in something less than Open Source, and there is little reason to support them.</div><div><br></div><div>Don't imply legal threats to the OSI or reviewers during the review process. It never works and doesn't make you friends.</div><div><br></div><div>    Thanks</div><div><br></div><div>    Bruce<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></div>