Problem with STM32 HAL license

[Joel Sherrill]

On Mon, Jun 13, 2022 at 1:03 PM Gedare Bloom <gedare at rtems.org> wrote:

> On Mon, Jun 13, 2022 at 11:02 AM Joel Sherrill <joel at rtems.org> wrote:
> >
> >
> >
> > On Mon, Jun 13, 2022 at 11:57 AM Gedare Bloom <gedare at rtems.org> wrote:
> >>
> >> On Mon, Jun 13, 2022 at 10:38 AM Karel Gardas <karel at functional.vision>
> wrote:
> >> >
> >> > On 6/13/22 18:27, Joel Sherrill wrote:
> >> > > This impacts other imports from STM so I am curious what Karel,
> >> > > Sebastian, and Andrei are seeing for the license in the code they
> are
> >> > > importing and what they plan to do.
> >> >
> >> > So far on H7, the HAL used is older code base which is clearly BSD-3
> >> > license:
> >> >
> >> >
> https://git.rtems.org/rtems/tree/bsps/arm/stm32h7/hal/stm32h7xx_hal.c#n22
> >> >
> >> > however to support new boards or peripherals I've imported few files
> >> > which use the same unclear license message. I've clarified it in any
> >> > imported file like:
> >> >
> >> >
> https://git.rtems.org/rtems/tree/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/system_stm32h7xx.c#n35
> >> >
> >> > the problem is obviously scalability of this solution and future
> merges.
> >> > You can do that one one/two board files, but probably not on whole HAL
> >> > with ~100 files.
> >> > I also remember that Sebastian recommended to completely replace this
> >> > license note with the specified license (to which note points). But
> I've
> >> > not done that due to reluctancy of touching STM license notes here and
> >> > hence came with committer clarification message below every such note.
> >> >
> >>
> >> My preference here would be to use injection of the committer comment,
> >> along with the addition of the SPDX tag at the top line. You should be
> >> able to automate this injection even for 100+ files, as long as they
> >> are using the same license. Keeping these changes together at the top
> >> of the file should also help handle merge problems if updates are
> >> pulled later.
> >
> >
> > What do you mean "injection of the committer comment"? Do you mean
> > Karel's example? Or just something in the git commit?
> >
> Karel's example. Something to show the due diligence that was done.
>

+1

Ideally the entire thing doesn't have to go in every file but the SPDX tag
and at least a reference to an explanation file would be good.

>
> > If we can name this for SPDX, that would be great. Ideally all files have
> > an SPDX annotation and that points to a unique master copy of the license
> > at the top of the RTEMS source tree.
> >
> If it doesn't match an SPDX tag, I think that is a problem for us to
> accept.
>

Supposedly, SPDX allows custom tags and the tooling allows a way for us
to define the tag to license text file association. I have no idea how any
of the
tooling works. We need someone to work with their tools to see how they
work.

>
> > I've suggested an "origin" file before where details like Karel captured
> > can be placed once in a directory.
> >
> That's ok, but harder to maintain.
>
> > --joel
> >>
> >>
> >> > Hence I asked Duc on discord to ask here for advice. BTW, new HAL for
> H7
> >> > will be probably in the same situation like Duc seing with current F4.
> >> >
> >> >
> https://github.com/STMicroelectronics/STM32CubeH7/blob/master/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal.c
> >> >
> >> >
> >> > So we definitely need to find a solution to this issue.
> >> >
> >> > Thanks,
> >> > Karel
> >> > _______________________________________________
> >> > devel mailing list
> >> > devel at rtems.org
> >> > http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20220613/e7e0715c/attachment.htm>