<div dir="ltr">There was quite a lot I did not think of when writing the OSD, and which perhaps did not belong in the OSD but which OSI should do as part of the license approval process for the benefit of developers and users. It's probably time to put together a list of what those things are, for everybody's information.<div><br></div><div>With regard to <b>simple users,</b> those who make use of the Open Source software and do not modify or redistribute it, there should be as close to <b>no legal load</b> as possible. We need to be cognizant that many of these users are individuals and very small businesses that can't reasonably assume any legal load at all. We can't protect them from patent issues brought by others than the licensor of the software, but to the extent that we can protect them, we should. In particular, <b>simple users should not ever have to read the license.</b></div><div><br></div><div>We should also endeavor to keep the legal load upon <b>Open Source developers</b> as low as possible. These are also individuals, small businesses, etc. We expect them to understand the license somewhat, but they are not legal experts and do not necessarily have easy access to legal experts or even the inclination to use them.</div><div><br></div><div>So, we can think about some things that would increase the load on those communities.</div><div><br></div><div>Use-coupled license responsibilities. We should not allow them at all. If you're an infringer if you don't put the correct web badge on your site, it's a bad license for Open Source because it means the user has to track what programs they're running and put the proper badges online, and make sure in perpetuity that those badges keep being presented. No thanks.</div><div><br></div><div>License proliferation: We don't want them to have to do more license combinatorial analysis than should be necessary. Thus, we should not in general accept new licenses, unless they in some way present a benefit to the community in a way that presently-accepted licenses do not.</div><div><br></div><div>Crayon licenses: We should not today approve licenses that were developed without the assistance of a lawyer, because they are likely to not be parsed by a judge the way the developer expects. The name "crayon license" comes from a Monty Python sketch including a "cat license" which has "dog" crossed out and "cat" written in, in crayon. Some developers have been really seriously harmed (by Artistic License 1) and there are a few unfortunately-OSI-accepted time bombs waiting for new victims.</div><div><br></div><div>Additional loads on the developer: We already place a number of loads on them when distributing, in general they have to present a copyright statement and license, sometimes a notice of source code availability, sometimes they have to distribute source code, and they perform some management of contributors and their rights. That's already a significant load, and additional loads upon the developer might not be a reasonable expectation.</div><div><br></div><div>What we get from this is that there will be some licenses which are OSD-compliant but which should not be OSI-certified.</div><div><br></div><div>Surely there are more things we should watch out for, this is just off the top of my head.</div><div class="gmail_extra"><br><div class="gmail_quote">    Thanks</div><div class="gmail_quote"><br></div><div class="gmail_quote">    Bruce</div></div></div>