Adding third-party source with Apache-2.0 license

[Christian MAUDERER]

Am 08.08.22 um 06:09 schrieb Chris Johns:
> On 7/8/2022 10:20 pm, oss at 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.mauderer at 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/