On 22/9/2022 11:44 pm, Joel Sherrill wrote: > > > On Thu, Sep 22, 2022 at 4:44 AM Karel Gardas <karel@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 <j...@rtems.org > <mailto:j...@rtems.org>> wrote: > >>>> > >>>> > >>>> > >>>> On Wed, Sep 21, 2022 at 8:48 AM Karel Gardas > >>>> <karel@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
