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> 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.
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"
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.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
