<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 19-10-2023 15:56, Sunitha Harish
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:3fbaa94e-391d-4d3a-95fb-259503e94dd3@gmail.com">
      <br>
      On 18-10-2023 18:48, Brad Bishop wrote:
      <br>
      <blockquote type="cite">On Wed, Oct 18, 2023 at 12:51:47PM +0530,
        Sunitha Harish wrote:
        <br>
        <blockquote type="cite">
          <br>
          On 13-10-2023 21:33, Brad Bishop wrote:
          <br>
          <blockquote type="cite">On Fri, Oct 13, 2023 at 05:04:23PM
            +1030, Andrew Jeffery wrote:
            <br>
            <blockquote type="cite">However, there is an escape hatch
              for project social issues. For
              <br>
              example interested parties might choose to collaborate on
              the license
              <br>
              manager implementation outside of the OpenBMC org, and
              package it
              <br>
              through Yocto or OpenEmbedded.
              <br>
            </blockquote>
            <br>
            I've been thinking along similar lines lately and I like
            this idea.  For a license server and even in general I think
            less centralized control and less tightly coupled software
            would be a good direction to take.
            <br>
          </blockquote>
          I am not very clear about this. The control and processing of
          the license will not be in BMC scope. The host should manage
          it.
          <br>
        </blockquote>
        <br>
        The suggestion here is to:
        <br>
        <br>
        1 - write your license server application
        <br>
        2 - throw it up on Github somewhere other than openbmc
        <br>
        3 - submit a recipe to meta-oe
        <br>
        <br>
      </blockquote>
      Thank you for clarifying.
      <br>
      <blockquote type="cite">It's possible the meta-oe maintainers
        could reject your recipe for the same reasons as you've been
        rejected here (or any other variety of reasons).  In that case
        you could just make a meta layer with a single recipe and throw
        that up on github too.
        <br>
        <br>
        The downside to this approach is you shouldn't use projects like
        phosphor-logging, sdbusplus, or phosphor-dbus-interfaces or any
        other recipes that are provided by OpenBMC or in meta-phosphor.
        Certainly not if you want to get a recipe into meta-oe. </blockquote>
      <br>
      I think this would defeat the purpose of this proposal. We want to
      use the BMC as a pass through entity for the licenses. It should
      be handling the redfish commands (bmcweb) on LicenseService schema
      - which is tightly coupled with the dbus. And the communication to
      the host at our server is via PLDM/MCTP. So we can not exclude the
      openbmc components. More over this new meta-oe work will turn out
      to be costly.
      <br>
      <br>
      @Ed/@Gunnar, are you interested in supporting the LicenseService
      schema at bmcweb?
      <br>
      <br>
    </blockquote>
    I see an old bmcweb commit - abandoned here <a
      href="https://gerrit.openbmc.org/c/openbmc/bmcweb/+/54037">Adding
      Support for License Service (I5c3625a9) · Gerrit Code Review
      (openbmc.org)</a> after some initial reviews from Ed. Seems like
    Intel/AMI had some features consuming the LicenseService?<br>
    <blockquote type="cite"
      cite="mid:3fbaa94e-391d-4d3a-95fb-259503e94dd3@gmail.com">
      <blockquote type="cite">IMO this isn't necessarily a bad thing,
        though.  This is what I meant by tightly coupled software - if
        you take this approach and avoid OpenBMC specific
        frameworks...who knows - if you make a an really awesome, useful
        piece of software - you might even get collaborators from
        outside OpenBMC.
        <br>
      </blockquote>
      <br>
      If the app which is planned now is processing/validating the
      licenses, then it would turn out to be an awesome piece of
      software. But that is not the intention. Lately, as per Andrew J
      and Manoj's review comments - the design is taking a direction
      where the objects will be hosted at PLDM itself and there is no
      need of a new application called LicenseManager.
      <br>
      <br>
      <br>
    </blockquote>
  </body>
</html>