D-bus model proposal for pay for access features - LicenseService at OpenBMC

[Sunitha Harish]

On 13-10-2023 21:33, Brad Bishop wrote:
> On Fri, Oct 13, 2023 at 05:04:23PM +1030, Andrew Jeffery wrote:
>> On Fri, 2023-10-13 at 00:13 -0400, Brad Bishop wrote:
>>> On Fri, Oct 13, 2023 at 12:32:09PM +1030, Andrew Jeffery wrote:
>>>
>>> > I think for this
>>> > to go anywhere it has to be demonstrated that there's a group of 
>>> people
>>> > needing a solution
>>>
>>> Isn't this self-evident from the schema being adopted by the DMTF?
>>
>> My comment was more in the context of OpenBMC and less in the context
>> of the DMTF. Standards that the DMTF produce are more broadly
>> applicable than to OpenBMC, so not all interested parties pushing it in
>> the DMTF are going to be parties willing to do the social legwork to
>> gain acceptance for and to maintain an implementation in OpenBMC.
>
> Makes sense.
>
>>> > and some collective interest in maintaining one. If
>>> > we can't get multiple parties to collaborate on a design then I don't
>>> > see a reason for trying to maintain it upstream.
>>>
>>> How many parties collaborated on getting FSI into Linux?   How many
>>> parties are collaborating on <foocorp>-misc or <platform>-misc?  Are
>>> those different somehow?
>>
>> How do FSI, <foocorp>-misc or <platform>-misc run afoul of common open
>> source beliefs and values? 
>
> Obviously they don't.  I asked this only in response to the comment 
> about a lack of collaboration from multiple parties as rationale for 
> exluding something.  It sounds like that is a red-herring.
>
>> I'm asking for a higher bar to establish whether a license server
>> implementation that constrains user freedoms is something the OpenBMC
>> community significantly values. Satisfying that (in my mind) requires a
>> diverse set of community members come forward and demonstrate that
>> they're willing to collaborate on design and maintenance, as a proxy
>> for value.
>
> Fair enough.
>
Intention is not to implement a license server at BMC. The idea is to 
just add support for the user interfaces via BMC, which can help routing 
the licenses to the host sitting on top of the firmware. I will start a 
discord message on this - to look for more community interest.
>> However, there is an escape hatch for project social issues. For
>> example interested parties might choose to collaborate on the license
>> manager implementation outside of the OpenBMC org, and package it
>> through Yocto or OpenEmbedded.
>
> 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.
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.