On 9/22/22 00:00, Gedare Bloom wrote:
On Wed, Sep 21, 2022 at 9:12 AM Joel Sherrill <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
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.
Thanks,
Karel
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
