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

[Sebastian Huber]

On 22/09/2022 10:30, Karel Gardas wrote:
> 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.

I don't like the Apache 2.0 license due to this clause:

"You must cause any modified files to carry prominent notices stating 
that You changed the files; and"

This means that the reviewer of RTEMS Project contributions has to check 
this for each Apache 2.0 file.

We also have to check if imported Work as a NOTICE file, since then this 
applies also:

"If the Work includes a "NOTICE" text file as part of its distribution, 
then any Derivative Works that You distribute must include a readable 
copy of the attribution notices contained within such NOTICE file, 
excluding those notices that do not pertain to any part of the 
Derivative Works, in at least one of the following places: within a 
NOTICE text file distributed as part of the Derivative Works; within the 
Source form or documentation, if provided along with the Derivative 
Works; or, within a display generated by the Derivative Works, if and 
wherever such third-party notices normally appear. The contents of the 
NOTICE file are for informational purposes only and do not modify the 
License. You may add Your own attribution notices within Derivative 
Works that You distribute, alongside or as an addendum to the NOTICE 
text from the Work, provided that such additional attribution notices 
cannot be construed as modifying the License."

This would be an extra requirement for RTMES users.

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber at embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/