[v3.6-branch] doc: services: device_mgmt: mcumgr: Correct license for tool

[nordicjm]

Corrects an incorrect license for a tool (backport of #78923).

Fixes #78927

[henrikbrixandersen]

This needs to go in as a backport of #78923 once it is merged.

[nordicjm]

This needs to go in as a backport of #78923 once it is merged.

The backport will not work because the whole table is different in main vs 3.x

[henrikbrixandersen]

This needs to go in as a backport of #78923 once it is merged.

The backport will not work because the whole table is different in main vs 3.x

It still needs to go into main first. If the automatic backport fails, a manual backport must be done.

[nordicjm]

This needs to go in as a backport of #78923 once it is merged.

The backport will not work because the whole table is different in main vs 3.x

It still needs to go into main first. If the automatic backport fails, a manual backport must be done.

Sure, the main one needs accepting first, but this is fully compliant with the process on https://github.com/zephyrproject-rtos/zephyr/wiki/Change-Control-and-Backports-to-stable-branches

Changes can be submitted to a stable and a released branch in 2 ways:
Directly submitted to the branch as a pull request with the Backport label

[henrikbrixandersen]

Sure, but not like this. This provides no traceability on where this change occurred in main.

[nordicjm]

Sure, but not like this. This provides no traceability on where this change occurred in main.

Nothing is required to go back to main that I've ever seen, it just needs to link to an issue. @nashif can you comment on what is needed? E.g. ed1db96

[henrikbrixandersen]

As an example of a manually submitted PR against a release branch that maintains traceability to main:

• [Backport v3.6-branch] Bluetooth: RFCOMM: check the validity of received frame #78860

Notice how both the PR description and the Git commit log (produced with git cherry-pick -x ... contains references to the corresponding commits to main.

[nordicjm]

As an example of a manually submitted PR against a release branch that maintains traceability to main:

* [[Backport v3.6-branch] Bluetooth: RFCOMM: check the validity of received frame #78860](https://github.com/zephyrproject-rtos/zephyr/pull/78860)

Notice how both the PR description and the Git commit log (produced with git cherry-pick -x ... contains references to the corresponding commits to main.

So top commit from v3.6-branch 2c2540e

    zephyr: Add zero-len check for utf8_trunc
    
    The function did not check if the provided string had a zero
    length before starting to truncate, which meant that last_byte_p
    could possible have pointed to the value before the string.
    
    Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>

What here does any of that?

[henrikbrixandersen]

What here does any of that?

That commit was a result of having to modify the original commit as per the discussion in #78286 (which does contain a reference to the original PR introducing the change on main).

[nordicjm]

What here does any of that?

That commit was a result of having to modify the original commit as per the discussion in #78286 (which does contain a reference to the original PR introducing the change on main).

Exactly, so I reference the issue here, the issue itself references all 3 items, the backport here is done manually because the table in main has moved on - just as the PR you referenced there, so what is different here?

[henrikbrixandersen]

Exactly, so I reference the issue here, the issue itself references all 3 items, the backport here is done manually because the table in main has moved on - just as the PR you referenced there, so what is different here?

Just what I described in my initial comment (#78929 (review)). This needs to be a backport of the commit to main. We can't have this go into a release branch before being accepted and merged on main - and your PR description links to an issue but no where mentions any trace of this being submitted against the main branch as well.