<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html;
      charset=windows-1252">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 14/08/2020 11:42, Valentin David
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:H2V1FQ.QAIEKT0497XE1@codethink.co.uk">
      <div id="geary-body" dir="auto"><span style="white-space: pre-wrap;"></span>
        <div>
          <blockquote type="cite">
            <div class="plaintext" style="white-space: pre-wrap;">C) What sort of format would be good for the machine-readable summary? json? YAML?</div>
          </blockquote>
          <span style="white-space: pre-wrap;"><div>
</div><div>json is so much easier and faster to parse. So for machine-readable, json.</div>
</span>
          <blockquote type="cite">
            <div class="plaintext" style="white-space: pre-wrap;">D) What sort of format would be good for the human-readable summary? markdown? html?</div>
          </blockquote>
          <span style="white-space: pre-wrap;"><div><span style="white-space: pre-wrap;">
</span></div><div><span style="white-space: pre-wrap;">markdown would be nice. But if it has limitation for formatting, you can go for html.</span></div></span></div>
      </div>
    </blockquote>
    <p>
      I've been working on json and html outputs. (see next email)</p>
    <p><br>
    </p>
    <blockquote type="cite"
      cite="mid:H2V1FQ.QAIEKT0497XE1@codethink.co.uk">
      <div id="geary-body" dir="auto">
        <div>
          <blockquote type="cite">
            <div class="plaintext" style="white-space: pre-wrap;">E) What would be a more useful output for freedesktop-sdk: just the summaries?</div>
          </blockquote>
          <blockquote type="cite">
            <div class="plaintext" style="white-space: pre-wrap;">or should we also include the raw licensecheck output?</div>
          </blockquote>
          <div><br>
          </div>
          <div>To be published? The summaries, I suppose. But I suppose
            we want to be able to get the output in a way.</div>
        </div>
      </div>
    </blockquote>
    For now I've included them in the output folder, along with the
    summaries.
    <p><br>
    </p>
    <blockquote type="cite"
      cite="mid:H2V1FQ.QAIEKT0497XE1@codethink.co.uk">
      <div id="geary-body" dir="auto">
        <div>We probably need to have a way to annotate the licensecheck
          data in the elements. For example build scripts that are
          intermediate stage within a project are not important for the
          result. Other cases are we do not build some of the code (for
          example FFmpeg). We still want to tell the license of the
          source code. But we should also say what applies to the
          element's artifact. Optionally, specify it for each split
          domain. There is also documentation which usually has
          difference licensing.</div>
      </div>
    </blockquote>
    <br>
    <p>The current approach is to build something that's completely
      external to the BuildStream program (although it will still
      hopefully be maintained under the BuildStream umbrella, in the
      BuildStream GitLab group). That means that the script won't have
      access to internal element data and config options. Instead, it
      works by invoking "bst show" to get a list of dependencies, and
      then checking out the source code from each dependency in order to
      perform the license scan.</p>
    <p>In that approach, I don't think there's any way to pay attention
      to split domains.</p>
    <p>For excluding certain elements (like intermediate stages), I was
      planning to introduce an 'ignore list', which users can maintain,
      and which the script will read. Any element on the ignore list
      wouldn't be scanned and wouldn't be mentioned in the output. This
      could also be used to remove stack and compose elements from the
      list, which aren't worth including in the output since they don't
      have any sources to scan.</p>
    <p>Scanning artifacts as well as sources is an interesting
      suggestion. I don't think artifacts are ever likely to contain
      license information which wasn't in the sources, so it wouldn't
      add any additional license information to the results. But I
      suppose in some cases it would be interesting to see which license
      information ends up in the actual artifact and which is only found
      in the source code.</p>
    <p>On the other hand, I think scanning artifacts as well as sources
      would add a lot of extra time, and the process already takes a
      very long time to complete. It took nearly 10 hours for the
      runners to do a full scan of everything in Freedesktop-sdk as it
      is. I don't think it's worth doing something that'll make it take
      even longer.<br>
    </p>
  </body>
</html>