<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 22, 2022 at 4:44 AM Karel Gardas <karel@functional.vision> 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 9/22/22 10:41, Sebastian Huber wrote:<br>
> On 22/09/2022 10:30, Karel Gardas wrote:<br>
>> On 9/22/22 00:00, Gedare Bloom wrote:<br>
>>> On Wed, Sep 21, 2022 at 9:12 AM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>> wrote:<br>
>>>><br>
>>>><br>
>>>><br>
>>>> On Wed, Sep 21, 2022 at 8:48 AM Karel Gardas <br>
>>>> <karel@functional.vision> wrote:<br>
>>>>><br>
>>>>><br>
>>>>> The problem is that we still need to discuss licensing here. Randomly<br>
>>>>> checked files from the HAL patch contains this as a license:<br>
>>>>><br>
>>>>> * This software is licensed under terms that can be found in the<br>
>>>>> LICENSE file<br>
>>>>> * in the root directory of this software component.<br>
>>>>> * If no LICENSE file comes with this software, it is provided <br>
>>>>> AS-IS.<br>
>>>>><br>
>>>>> and in the past Sebastian suggested to clear the message hence I used<br>
>>>>> something used here:<br>
>>>>><br>
>>>>> <a href="https://github.com/dtbpkmte/GSoC-2022-RTEMS/blob/master/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/system_stm32h7xx.c" rel="noreferrer" target="_blank">https://github.com/dtbpkmte/GSoC-2022-RTEMS/blob/master/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/system_stm32h7xx.c</a> <br>
>>>>><br>
>>>><br>
>>>><br>
>>>> I'm OK with an explanation like that but I hate to see that much <br>
>>>> duplicated<br>
>>>> over and over. Would it be possible to put the lengthy explanation <br>
>>>> in one<br>
>>>> place with the HAL addition and then have a short explanation in <br>
>>>> each file:<br>
>>>><br>
>>>> /*<br>
>>>> * RTEMS committer clarification comment on license above:<br>
>>>> *<br>
>>>> * This file comes from STM32CubeH7 project from its Projects <br>
>>>> subdirectory. See<br>
>>>> * RTEMS_PATH_TBD for details on the license for this file.<br>
>>>> */<br>
>>>><br>
>>>> With RTEMS_PATH_TBD probably easy to identify because it would<br>
>>>> be something like bsps/arm/shared/STMHM7 and then the single<br>
>>>> file with a name that is like LICENSE_STM32CubeH7.txt so it isn't just<br>
>>>> LICENSE.txt which is easy to confuse.<br>
>>>><br>
>>>> Just a practical matter of avoiding duplication. We have precedence<br>
>>>> for this over the project history.<br>
>>>><br>
>>>> This is just record keeping to maintain proper attribution, origin URL,<br>
>>>> licensing, etc. without burden of duplication. They obviously <br>
>>>> thought it<br>
>>>> was a duplication burden. We should use their trick and just point to<br>
>>>> our location for that file. :)<br>
>>>><br>
>>>> It's not like we are trying to nick the code and not give credit. We <br>
>>>> are<br>
>>>> likely in the small minority even doing this much. My expectations are<br>
>>>> pretty low for most people/projects.<br>
>>>><br>
>>><br>
>>> We had a discussion about this topic over on Discord. The general<br>
>>> resolution there was that we should consider importing the HAL code<br>
>>> as-is, and then layer on another patch to inject SPDX tags for the<br>
>>> appropriate license into each imported file. Then the committer (In<br>
>>> this case, Duk) should write up an ORIGIN kind of file to put into the<br>
>>> directory above the HAL to explain the history of the code there,<br>
>>> where it came from (URLs), how the licenses were sorted, and any other<br>
>>> information that helps understand the source of that code. This<br>
>>> balances the effort needed to update the HAL code later, since if it<br>
>>> changes only minimally, we can just re-import it, re-inject the SPDX<br>
>>> tags, and update the ORIGIN file. In this case, I'd say add something<br>
>>> like ORIGIN.HAL in the stm32f4 directory to capture the documentation<br>
>>> about the import process for the HAL.<br>
>><br>
>> Sounds good! Last remark and question. What about Apache 2.0 license <br>
>> which covers at least some of the files from STM and which we use in <br>
>> "hal" subdirectory. Is everything settled and the project may use such <br>
>> files? In the past at least Sebastian and Chris were reserved and <br>
>> raised some questions about Apache 2.0 license details...<br>
>><br>
>> Asking since this exactly applies to STM32H7 BSP HAL too so it'd ve <br>
>> great to have that sorted out in the same way here.<br>
> <br>
> I don't like the Apache 2.0 license due to this clause:<br>
> <br>
> "You must cause any modified files to carry prominent notices stating <br>
> that You changed the files; and"<br>
> <br>
<br>
<br>
With a need to use SPDX identitifer on top of every file the project may <br>
probably also do:<br>
<br>
(1) add an option of 'This file was changed by RTEMS project.' clausule <br>
to top of the file probably below SPDX id for Apache 2.0 licensed files.<br></blockquote><div><br></div><div>+1 </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
and<br>
<br>
(2) implement git commit hook to check that every single file with <br>
Apache 2.0 SPDX contains (1).<br>
<br>
Would that fulfill requirements of Apache 2.0 license?<br></blockquote><div><br></div><div>I think it would. Even adding the SPDX tag would technically modify the file</div><div>so adding the "changed by the RTEMS Project" and importing the base code</div><div>gives us tracking on changes. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> This means that the reviewer of RTEMS Project contributions has to check <br>
> this for each Apache 2.0 file.<br>
> <br>
> We also have to check if imported Work as a NOTICE file, since then this <br>
> applies also:<br>
> <br>
> "If the Work includes a "NOTICE" text file as part of its distribution, <br>
> then any Derivative Works that You distribute must include a readable <br>
> copy of the attribution notices contained within such NOTICE file, <br>
> excluding those notices that do not pertain to any part of the <br>
> Derivative Works, in at least one of the following places: within a <br>
> NOTICE text file distributed as part of the Derivative Works; within the <br>
> Source form or documentation, if provided along with the Derivative <br>
> Works; or, within a display generated by the Derivative Works, if and <br>
> wherever such third-party notices normally appear. The contents of the <br>
> NOTICE file are for informational purposes only and do not modify the <br>
> License. You may add Your own attribution notices within Derivative <br>
> Works that You distribute, alongside or as an addendum to the NOTICE <br>
> text from the Work, provided that such additional attribution notices <br>
> cannot be construed as modifying the License."<br>
> <br>
> This would be an extra requirement for RTMES users.<br>
<br>
Currently we are talking here about files from:<br>
<br>
CMSIS_5<br>
STM32CubeH7<br>
STM32CubeF4<br>
<br>
projects (as named on <a href="http://github.com" rel="noreferrer" target="_blank">github.com</a>).<br>
<br>
None of those projects contain 'NOTICE' or 'NOTICE*' file as of today.<br></blockquote><div><br></div><div>I think the ORIGIN file we discussed would have to say there is no NOTICE</div><div>file in the original and none passed along.</div><div><br></div><div>If there were a NOTICE file, we would have to continue the discussion.</div><div>Quite likely, anything someone put in a NOTICE file would result in us</div><div>rejecting the code. But we haven't seen one yet. </div><div><br></div><div>To summarize, I think your approach to Apache code that has no NOTICE</div><div>file matches mine.</div><div><br></div><div>+ import base with ORIGIN file including that there was no NOTICE file<br></div><div>+ add SPDX and "modified by RTEMS project" notice<br></div><div>+ proceed<br></div><div><br></div><div>If we agreed on the procedure for the BSD license HAL code that procedure</div><div>should go in the Software Engineering Guide. Ditto for Apache once we</div><div>agree on it. These are important procedures we are agreeing to and need</div><div>to be recorded.</div><div><br></div><div>Gedare.. are you ok with creating the patch for the BSD licensed HAL </div><div>import /acceptance procedure?</div><div><br></div><div>--joel</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Thanks,<br>
Karel<br>
</blockquote></div></div>