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

[Brad Bishop]

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.

>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.