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

[Joel Sherrill]

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> 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"
> >
>
>
> 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.
>
> Currently we are talking here about files from:
>
> CMSIS_5
> STM32CubeH7
> STM32CubeF4
>
> projects (as named on 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.

Gedare.. are you ok with creating the patch for the BSD licensed HAL
import /acceptance procedure?

--joel


> Thanks,
> Karel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20220922/fc061df1/attachment.htm>