<div dir="ltr"><div style="font-size:16px">Most of this is implicit within the OSD but they are useful to keep in mind:</div><div style="font-size:16px"><br></div><div style="font-size:16px">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 style="font-size:16px"><br></div><div style="font-size:16px">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 style="font-size:16px"><br></div><div style="font-size:16px">So, we can think about some things that would increase the load on those communities.</div><div style="font-size:16px"><br></div><div style="font-size:16px">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 style="font-size:16px"><br></div><div style="font-size:16px">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 style="font-size:16px"><br></div><div style="font-size:16px">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 style="font-size:16px"><br></div><div style="font-size:16px">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 style="font-size:16px"><br></div><div style="font-size:16px">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 style="font-size:16px"><br></div><div style="font-size:16px"><br></div></div>