<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 13, 2022 at 11:57 AM Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Jun 13, 2022 at 10:38 AM Karel Gardas <karel@functional.vision> wrote:<br>
><br>
> On 6/13/22 18:27, Joel Sherrill wrote:<br>
> > This impacts other imports from STM so I am curious what Karel,<br>
> > Sebastian, and Andrei are seeing for the license in the code they are<br>
> > importing and what they plan to do.<br>
><br>
> So far on H7, the HAL used is older code base which is clearly BSD-3<br>
> license:<br>
><br>
> <a href="https://git.rtems.org/rtems/tree/bsps/arm/stm32h7/hal/stm32h7xx_hal.c#n22" rel="noreferrer" target="_blank">https://git.rtems.org/rtems/tree/bsps/arm/stm32h7/hal/stm32h7xx_hal.c#n22</a><br>
><br>
> however to support new boards or peripherals I've imported few files<br>
> which use the same unclear license message. I've clarified it in any<br>
> imported file like:<br>
><br>
> <a href="https://git.rtems.org/rtems/tree/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/system_stm32h7xx.c#n35" rel="noreferrer" target="_blank">https://git.rtems.org/rtems/tree/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/system_stm32h7xx.c#n35</a><br>
><br>
> the problem is obviously scalability of this solution and future merges.<br>
> You can do that one one/two board files, but probably not on whole HAL<br>
> with ~100 files.<br>
> I also remember that Sebastian recommended to completely replace this<br>
> license note with the specified license (to which note points). But I've<br>
> not done that due to reluctancy of touching STM license notes here and<br>
> hence came with committer clarification message below every such note.<br>
><br>
<br>
My preference here would be to use injection of the committer comment,<br>
along with the addition of the SPDX tag at the top line. You should be<br>
able to automate this injection even for 100+ files, as long as they<br>
are using the same license. Keeping these changes together at the top<br>
of the file should also help handle merge problems if updates are<br>
pulled later.<br></blockquote><div><br></div><div>What do you mean "injection of the committer comment"? Do you mean </div><div>Karel's example? Or just something in the git commit?</div><div><br></div><div>If we can name this for SPDX, that would be great. Ideally all files have </div><div>an SPDX annotation and that points to a unique master copy of the license </div><div>at the top of the RTEMS source tree.</div><div><br></div><div>I've suggested an "origin" file before where details like Karel captured </div><div>can be placed once in a directory.</div><div><br></div><div>--joel</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> Hence I asked Duc on discord to ask here for advice. BTW, new HAL for H7<br>
> will be probably in the same situation like Duc seing with current F4.<br>
><br>
> <a href="https://github.com/STMicroelectronics/STM32CubeH7/blob/master/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal.c" rel="noreferrer" target="_blank">https://github.com/STMicroelectronics/STM32CubeH7/blob/master/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal.c</a><br>
><br>
><br>
> So we definitely need to find a solution to this issue.<br>
><br>
> Thanks,<br>
> Karel<br>
> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</blockquote></div></div>