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

Andrew Jeffery andrew at codeconstruct.com.au
Fri Oct 13 17:34:23 AEDT 2023


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.

> 
> > 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? FSI is a specification and implementation of
a communication bus for processor management and doesn't particularly
interfere with any open source ideological principles. Implementing a
subsystem for it in upstream Linux doesn't impact anyone's ability to
run, study, share or modify the software on their system.

What we're discussing here is a community-endorsed implementation of a
license server that exists to constrain people's abilities to run,
study, share or modify the software or hardware that composes their
machine. That certainly isn't supporting the principles on which open
source software collaboration is often built.

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.

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.


Andrew


More information about the openbmc mailing list