Am 08.08.22 um 06:09 schrieb Chris Johns:
On 7/8/2022 10:20 pm, o...@c-mauderer.de wrote:
Am 07.08.22 um 13:06 schrieb Duc Doan:
Dear all,
I am working on a project that needs to include ST's STM32F4 HAL into
RTEMS, specifically release v1.27.1 at:
https://github.com/STMicroelectronics/STM32CubeF4. However, the CMSIS
files in this repository have Apache-2.0 license. What do you think
about this? Should I add them to RTEMS, or is there anything I need to
do to include these sources?
Thanks for bringing up this issue. I think one important point is that all newer
ARM CMSIS files are Apache 2.0:
https://github.com/ARM-software/CMSIS_5
So that affects all ARM cores and not only STM32. From my point of view, we
sooner or later have to accept this license if we don't want to maintain our own
fork of ARM CMSIS.
Apache requires any update carry a prominent notice plus NOTICE text files need
special handling.
How do you see that being handled?
Chris
We have three problems:
1. NOTICE files. We have to add them to the code if they are there. We
maybe need a decision whether we want to collect them at the root level
or put them together with the code. Both have advantages and
disadvantages, but that should be solvable.
2. The clause 4 b of the license: "You must cause any modified files to
carry prominent notices stating that You changed the files". I think
that's a two part solution:
a) Mark all changes with "#ifdef __RTEMS__" like we do in libbsd. That's
a good idea for all third party code that we might want to update in the
future.
b) Make a general statement that "Apache Code is adapted to work with
RTEMS".
That is oversimplified and needs fine-tuning like where the statement
should be located, but I think that part is solvable too.
3. The most difficult problem: How can we manage the patch review. Every
file that changes an Apache licensed file needs special review. Note
that a good solution to this problem wouldn't be only useful for Apache
license but could also help make changes in third party code more
visible and therefore help with upgrading that code.
At the moment I only have some rough ideas. Let's try to discuss them
and see whether one of them could be an useable solution:
a) Something that we could use as a general rule for third-party code: A
special subdirectory like "third-party", "contrib" or "external". If one
of these subdirectories appears in a patch, we know that we have to take
a thorough look at these files. It's still manual and therefore
error-prone. But it would be a start.
b) We could add an option to have checksums for these files in the yaml
files. If someone changes one of the files, the build system could throw
a warning. Will need some work to change the build system and therefore
is not a simple and quick solution, but it would automate the process.
c) We could pull in external code only as submodules. That would prevent
changes to that code at all. The big disadvantage is that it adds nasty
external dependencies. The big problem with this is that the location of
the external code can change or can be no longer available. It also is a
big problem with the release process. Most likely not a good solution.
Please feel free to add more ideas.
Regardless what we decide: Maybe we should generate a documentation
point about "Best Practices When Adding Third-Party Code" out the
discussion?
Best regards
Christian
--
--------------------------------------------
embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
mobile: +49-176-152 206 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
