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

Chris Johns chrisj at rtems.org
Thu Sep 22 22:18:09 UTC 2022


On 22/9/2022 11:44 pm, Joel Sherrill wrote:
> 
> 
> On Thu, Sep 22, 2022 at 4:44 AM Karel Gardas <karel at functional.vision> wrote:
> 
>     On 9/22/22 10:41, Sebastian Huber wrote:
>     > 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
>     <mailto: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 <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"
>     >
> 
> 
>     With a need to use SPDX identitifer on top of every file the project may
>     probably also do:
> 
>     (1) add an option of 'This file was changed by RTEMS project.' clausule
>     to top of the file probably below SPDX id for Apache 2.0 licensed files.
> 
> 
> +1 
> 
> 
>     and
> 
>     (2) implement git commit hook to check that every single file with
>     Apache 2.0 SPDX contains (1).
> 
>     Would that fulfill requirements of Apache 2.0 license?
> 
> 
> I think it would. Even adding the SPDX tag would technically modify the file
> so adding the "changed by the RTEMS Project" and importing the base code
> gives us tracking on changes. 
> 
> 
>     > 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.

My reading of this means we need to carry a NOTICE file is present in any part
of the source package we import but we can add suitable attribution in the
Source form or documentation. I take this to mean a suitable tag to each file.

> 
>     Currently we are talking here about files from:
> 
>     CMSIS_5
>     STM32CubeH7
>     STM32CubeF4
> 
>     projects (as named on github.com <http://github.com>).
> 
>     None of those projects contain 'NOTICE' or 'NOTICE*' file as of today.
> 
> 
> I think the ORIGIN file we discussed would have to say there is no NOTICE
> file in the original and none passed along.
> 
> If there were a NOTICE file, we would have to continue the discussion.
> Quite likely, anything someone put in a NOTICE file would result in us
> rejecting the code. But we haven't seen one yet. 
> 
> To summarize, I think your approach to Apache code that has no NOTICE
> file matches mine.
> 
> + import base with ORIGIN file including that there was no NOTICE file
> + add SPDX and "modified by RTEMS project" notice
> + proceed
> 
> If we agreed on the procedure for the BSD license HAL code that procedure
> should go in the Software Engineering Guide. Ditto for Apache once we
> agree on it. These are important procedures we are agreeing to and need
> to be recorded.

I would like to see this written up in the eng manual before anything hits our
repos. I think I understand what has been said however the written process in
the eng manual would make it certain and agreed.

Thanks
Chris


More information about the devel mailing list