[PATCH v6 00/10] New GPIO, ADC API and STM32F4 BSP implementation

[Karel Gardas]

On 9/22/22 00:00, Gedare Bloom wrote:
> On Wed, Sep 21, 2022 at 9:12 AM Joel Sherrill <joel at rtems.org> wrote:
>>
>>
>>
>> On Wed, Sep 21, 2022 at 8:48 AM Karel Gardas <karel at functional.vision> wrote:
>>>
>>>
>>> The problem is that we still need to discuss licensing here. Randomly
>>> checked files from the HAL patch contains this as a license:
>>>
>>>     * This software is licensed under terms that can be found in the
>>> LICENSE file
>>>     * in the root directory of this software component.
>>>     * If no LICENSE file comes with this software, it is provided AS-IS.
>>>
>>> and in the past Sebastian suggested to clear the message hence I used
>>> something used here:
>>>
>>> https://github.com/dtbpkmte/GSoC-2022-RTEMS/blob/master/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/system_stm32h7xx.c
>>
>>
>> I'm OK with an explanation like that but I hate to see that much duplicated
>> over and over. Would it be possible to put the lengthy explanation in one
>> place with the HAL addition and then have a short explanation in each file:
>>
>> /*
>>   * RTEMS committer clarification comment on license above:
>>   *
>>   * This file comes from STM32CubeH7 project from its Projects subdirectory. See
>>   * RTEMS_PATH_TBD for details on the license for this file.
>>   */
>>
>> With RTEMS_PATH_TBD probably easy to identify because it would
>> be something like bsps/arm/shared/STMHM7 and then the single
>> file with a name that is like LICENSE_STM32CubeH7.txt so it isn't just
>> LICENSE.txt which is easy to confuse.
>>
>> Just a practical matter of avoiding duplication. We have precedence
>> for this over the project history.
>>
>> This is just record keeping to maintain proper attribution, origin URL,
>> licensing, etc. without burden of duplication. They obviously thought it
>> was a duplication burden. We should use their trick and just point to
>> our location for that file. :)
>>
>> It's not like we are trying to nick the code and not give credit. We are
>> likely in the small minority even doing this much. My expectations are
>> pretty low for most people/projects.
>>
> 
> We had a discussion about this topic over on Discord. The general
> resolution there was that we should consider importing the HAL code
> as-is, and then layer on another patch to inject SPDX tags for the
> appropriate license into each imported file. Then the committer (In
> this case, Duk) should write up an ORIGIN kind of file to put into the
> directory above the HAL to explain the history of the code there,
> where it came from (URLs), how the licenses were sorted, and any other
> information that helps understand the source of that code. This
> balances the effort needed to update the HAL code later, since if it
> changes only minimally, we can just re-import it, re-inject the SPDX
> tags, and update the ORIGIN file. In this case, I'd say add something
> like ORIGIN.HAL in the stm32f4 directory to capture the documentation
> about the import process for the HAL.

Sounds good! Last remark and question. What about Apache 2.0 license 
which covers at least some of the files from STM and which we use in 
"hal" subdirectory. Is everything settled and the project may use such 
files? In the past at least Sebastian and Chris were reserved and raised 
some questions about Apache 2.0 license details...

Asking since this exactly applies to STM32H7 BSP HAL too so it'd ve 
great to have that sorted out in the same way here.

Thanks,
Karel