Allowing for a default set of licenses for a model distribution

[lehors]

The MOF configuration file currently expects a license to be specified for each component that is provided. This is clearly not practical and is totally disconnected from the reality we are in. In fact the vast majority of model distributions contains a single license at best. I think we should focus on encouraging model producers to have 3 licenses (for code, doc, and data) per distribution and not expect them to have a license per component.

So, I would like to propose that we change the format to allow 3 licenses to be specified at the top of the configuration file: one for code, one for doc, and one for data, which will be considered to be the default ones for the related components that are provided. We can still allow this to be overridden for each component but this would be totally optional.

On the MOT side, this would translate in a change to the evaluate and submit forms so that these can be entered first and then we would allow "default" to be selected for each component included in the distribution.

[gregcube]

I like and support this idea.

[SachinVarghese]

Thanks for starting this thread. For sure, MOT could be simplified in terms of user experience and I'm in agreement with this suggestion without changing the MOF spec. I really like the idea to simplify the MOT usage but it is possible that each MOF component could have a different licence. People sticking in one license for all components at a model level today rather than acknowledging all the various components and licences that went into building the model is part of the problem we are trying to solve here.

From a workflow POV, I also feel that we should move to a pull request based flow to update the source info in Git rather than relying on UI forms. This will be easier to support long term with changing versions of MOF and license updates if any.

[lehors]

I agree we want to keep encouraging model producers to have a type-appropriate license for each type of component. I don't think we need to require a license for each component though. In fact, the MOF already provides for more flexibility than the MOT supports. It allows for a single LICENSE file to be included in the model distribution that contains multiple licenses to cover the whole distribution.

[matthew-d-white]

Just a note on the single license topic. We are building just that with the OpenMDW license. I will be introducing it at the LF Member Summit next week: https://sched.co/1urXi. In having a single license for any of model, data & parameters it will make complying with the MOF easier and assessing the class of models much easier (a single LICENSE file in the root directory vs. many.).

The license will need some additional review before its published, but I think this will really make adoption much easier for the MOF.

[lehors]

So, this is different from what I'm proposing. You're talking about having a single license for all types, I was merely talking about having a single license for each type, as opposed to the current expectation of having a license for each component. But we might as well plan for a single license for all types as well to cover all cases.
We'll need to figure the best way to capture that.

[gvlx]

I suppose this could just a UX issue on the tool, where we could just ask it use a certain license as the default for the form (and replace all by that one, if needed).

[gregcube]

For the YAML representation of a model; how do we feel about something like this to accept distribution-wide and component-type specific licenses?

framework:
  name: 'Model Openness Framework'
  version: '1.0'
  date: '2024-12-15'
release:
  name: Model-name
  version: 7B
  license:
    distribution: Apache-2.0
    code:
    document:
    data: CDLA-Permissive-2.0
  date: '2024-10-03'
  type: language
  architecture: undisclosed
  origin: ''
  producer: ''
  contact: ''
  repository: ''
  huggingface: ''
  components:
    -
      name: 'Model architecture'
      description: "Well commented code for the model's architecture"
      license: AFL-2.0  # Component-specific license. 
    -  
      name: 'Data preprocessing code'                                                                       
      description: 'Code for data cleansing, normalization, and augmentation' 
      license: unlicensed  # Component is included, but has no license. 
    -  
      name: 'Model parameters (Final)'  
      description: 'Trained model parameters, weights and biases'
      # Omitted license implies inheritance from release/license/data.   
    - 
      name: 'Data card' 
      description: 'Documentation for datasets including source, characteristics, and preprocessing details'
      # Inherited from release/license/distribution (document and code are empty)

It adds the license key under release --
distribution would be considered the global/distribution-wide license.

If a component is not included under release/components, then it's, well, not included. We no longer would need the Component not included marker. This would translate to an on/off checkbox on the UI.

Where do we land on including component and license paths?

Component location path: Mandatory, optional, remove altogether?
License path: Mandatory, optional, remove altogether?

If license path is mandatory or optional, we'll need to further refine the YAML; maybe like this?:

release:
  license:
    distribution:
      path: /path/to/license
      name: Apache-2.0
    code:
      path: /path/to/license
      name: MIT

Let me know your thoughts.

[lehors]

This is actually nicer than what I had come up with. As you know I'm inclined to get rid of the paths altogether but I think @matthew-d-white cared about them so I think making it optional is a good compromise.

[matthew-d-white]

I'm all in favor of making it simpler, making it optional makes a lot of sense. As a best practice having the licenses all in one LICENSE file in the root and covering the three content types would be the easiest to manage.

This would not work in the scenario where one or more of the components come with their own licenses from their original developers and don't line up with the model producers choices? In those cases the paths would be necessary.

[SachinVarghese]

Looks good, nice work! We should also discuss if we could trim some of these following attributes when org, contact and respository are included

  type: language
  architecture: undisclosed
  origin: ''
  producer: ''
  huggingface: ''

And, having licence path as optional improves the utility of the tool, mainly when the licence is open but is not listed on the MOF spec.

[lehors]

And, having licence path as optional improves the utility of the tool, mainly when the licence is open but is not listed on the MOF spec.

There seems to be confusion about what the license path is about. This is supposed to be the path to the license file in the model distribution. Evidently some people think this is the path/URL to the license definition.

[lehors]

This has now been implemented with PR #89.