<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 1:03 PM 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 11:02 AM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>> wrote:<br>
><br>
><br>
><br>
> On Mon, Jun 13, 2022 at 11:57 AM Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>> wrote:<br>
>><br>
>> 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>
><br>
><br>
> What do you mean "injection of the committer comment"? Do you mean<br>
> Karel's example? Or just something in the git commit?<br>
><br>
Karel's example. Something to show the due diligence that was done.<br></blockquote><div><br></div><div>+1 </div><div><br></div><div>Ideally the entire thing doesn't have to go in every file but the SPDX tag</div><div>and at least a reference to an explanation file would be good. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> If we can name this for SPDX, that would be great. Ideally all files have<br>
> an SPDX annotation and that points to a unique master copy of the license<br>
> at the top of the RTEMS source tree.<br>
><br>
If it doesn't match an SPDX tag, I think that is a problem for us to accept.<br></blockquote><div><br></div><div>Supposedly, SPDX allows custom tags and the tooling allows a way for us</div><div>to define the tag to license text file association. I have no idea how any of the</div><div>tooling works. We need someone to work with their tools to see how they</div><div>work.  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> I've suggested an "origin" file before where details like Karel captured<br>
> can be placed once in a directory.<br>
><br>
That's ok, but harder to maintain.<br>
<br>
> --joel<br>
>><br>
>><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>