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

[Brad Bishop]

On Wed, Oct 18, 2023 at 12:51:47PM +0530, Sunitha Harish wrote:
>
>On 13-10-2023 21:33, Brad Bishop wrote:
>>On Fri, Oct 13, 2023 at 05:04:23PM +1030, Andrew Jeffery wrote:
>>>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.

The suggestion here is to:

1 - write your license server application
2 - throw it up on Github somewhere other than openbmc
3 - submit a recipe to meta-oe

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.

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.

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.