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

[Brad Bishop]

On Fri, Oct 13, 2023 at 12:32:09PM +1030, Andrew Jeffery wrote:
>On Fri, 2023-10-06 at 13:17 -0400, Brad Bishop wrote:
>> On Fri, Oct 06, 2023 at 07:29:27AM -0500, Patrick Williams wrote:
>> > On Fri, Oct 06, 2023 at 10:21:01AM +0530, Sunitha Harish wrote:
>> > > Hi Patrick,
>> > >
>> > > Re-starting this discussion with the design that is being worked at
>> > > License Manager: Add license manager design (Ibd6c6f35) · Gerrit Code
>> > > Review (openbmc.org) <https://gerrit.openbmc.org/c/openbmc/docs/+/64710>.
>> >
>> > I've already written enough on this topic.  You've not added much in
>> > terms of what I've already written, so I'm not sure what more you want
>> > me to say.
>>
>> I just want to say that OEMs have many, many happy customers that gladly
>> pay for unlocking things.  They just don't typically hang out here 🙂.
>> I just bought a BMC license key the other day for my ~8 year old
>> Supermicro x10slh-f.  For what it is worth.  I know a lot of people have
>> a problem with charging for security fixes but this is bigger than just
>> that.
>>
>
>Brad: Given the interest, are you able to provide feedback on IBM's
>design proposal?
>
>https://gerrit.openbmc.org/c/openbmc/docs/+/64710

Hah - that's what I get for opening my mouth 🤣.  I wouldn't say I'm 
interested.  I'm not sure why I felt compelled to respond - Maybe I was 
just feeling chatty and wanted to support one of my fellow server OEMs.

Anyhow, I took a quick look and in general the proposal seems lacking in 
details.  References to dbus objects and interfaces need to be filled in 
with details.  "License data" needs to be explained - what is it, in 
terms of Redfish and DBus?  Other vague statements about Redfish need to 
be explained in specific terms of the new schema (resources, actions, 
etc). Interactions between applications need to be spelled out 
explicitly (more dbus interfaces?).  The resulting Redfish data model is 
not apparent to me (I admit I've never looked at the new schema, but I 
do know a thing or two about Redfish so ideally I shouldn't need to?).  
Much like the Redfish concern, the PLDM data model needs to be expanded 
upon and explained in terms of a PLDM specification.

>More broadly, setting aside Patrick's legal concerns,

And they do seem like reasonable concerns, but I am not a lawyer.  I 
don't think engineers are going to be able to allay those concerns. 

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

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

>From a personal perspective, the concept grinds badly against common
>believes and values in open source software projects and I'm not going
>to go out of my way to support it. 

I'm sure it probably sounds like I'm advocating for this feature.  I'm 
really not.  I'm trying to generally improve my understanding of what 
types of code submissions are welcome and what kinds are not through 
questions.  Maybe I just need to stop looking for patterns where none 
exist...