[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