anchor.diff:  <li><a href="https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing">a "good" license according to Fedora</a></li> 
   </ul>
   <p>The software MAY also be licensed other ways (e.g., "GPLv2 or proprietary" is acceptable).</p>
  +<p><em>Note</em>: We intend for the automated tool to focus on identifying common OSS licenses such as:     <a href="http://creativecommons.org/publicdomain/zero/1.0/">CC0</a>, <a href="https://opensource.org/licenses/MIT">MIT</a>, <a href="https://opensource.org/licenses/BSD-2-Clause">BSD 2-clause</a>, <a href="https://opensource.org/licenses/BSD-3-Clause">BSD 3-clause revised</a>, <a href="https://opensource.org/licenses/Apache-2.0">Apache 2.0</a>, <a href="https://opensource.org/licenses/lgpl-license">Lesser GNU General Public License (LGPL)</a>, and the <a href="https://opensource.org/licenses/gpl-license">GNU General Public License (GPL)</a>.</p>
  +<p><em>Rationale</em>: These criteria are designed for OSS projects, so we need to ensure that they're only used where they apply.  Some projects are thought of as OSS yet are not actually released as OSS (e.g., they might not have any license, in which case the defaults of the country's legal system apply, or they might use a non-OSS license).  Unusual licenses can cause long-term problems for OSS projects and are more difficult for tools to handle.  We expect that more advanced badges would set a higher bar (e.g., that it <em>must</em> be released under an OSI-approved license).</p>
  +</ul>
  +
   }}) %>
          <hr>
   
  
positive.code: to high severity if its <a href="https://nvd.nist.gov/cvss.cfm">CVSS 2.0</a> base score is 4 or higher.
  <br><br>
  <b>Note</b>: this means that users might be left vulnerable to all attackers
  worldwide for up to 60 days. This criterion is often much easier to meet than what Google
  recommends in Rebooting responsible disclosure, because Google recommends that the 60-day
  period start when the project is notified even if the report is not public.<br>
  <b>Rationale</b>: We intentionally chose to start measurement from the time of public knowledge,
  and not from the time reported to the project, because this is much easier to measure and
  verify by those outside the project.
  
negative.code: 
        <%= render(partial: "status_chooser", locals: {f: f, is_disabled: is_disabled,
                 criteria: "version_semver", desc: %{
  It is SUGGESTED that the
  <a href="http://semver.org">Semantic Versioning (SemVer) format</a> 
  is used for releases.},
                 details: %{
  Commit IDs (or similar) MAY be used as version numbers. They are unique, but note that these can
  cause problems for users as they may not be able to determine whether or not they're up-to-date.
  