...
- The OSS must be released under a license included in the allow list in Table 1-1.
- When the OSS license is not included in the allowed list, it must be confirmed that it is not included in the deny list in Table 1-2.
- When the OSS license is not listed on both lists, this license must be judged by AGL Instrument Expert Geoup Group and accepted by SAT.
Table 1-1. Allow licence listlicense list
| No. | License name | License URL |
|---|---|---|
| 1 | GNU General Public License, version 2 | https://www.gnu.org/licenses/old-licenses/gpl-2.0.txt |
| 2 | GNU Lesser General Public License, version 2.1 | https://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html |
| 3 | Apache License 2.0 | https://www.apache.org/licenses/LICENSE-2.0 |
| 4 | 3-clause BSD license | https://opensource.org/licenses/BSD-3-Clause |
| 5 | 2-clause BSD license | https://opensource.org/licenses/BSD-2-Clause |
| 6 | MIT License | https://opensource.org/licenses/mit-license.php |
| 7 | Mozilla Public License 2.0 | https://www.mozilla.org/en-US/MPL/2.0/ |
| 8 | zlib/libpng License | https://opensource.org/licenses/Zlib |
| 9 | Boost Software License 1.0 | https://opensource.org/licenses/BSL-1.0 |
| 10 | GCC Runtime Library Exception | https://www.gnu.org/licenses/gcc-exception-3.1.en.html |
...
| No. | License name | License URL |
|---|---|---|
| 1 | GNU General Public License, version 3 | https://www.gnu.org/licenses/gpl-3.0.en.html |
| 2 | GNU Lesser General Public License, version 3 | https://www.gnu.org/licenses/lgpl-3.0.en.html |
| 3 | GNU Affero General Public License version 3 | https://opensource.org/licenses/AGPL-3.0 |
*The GPLv3 and GPLv3 like license does not allow tivoization. This is incompatible with embedded use cases.
1.2.
...
Special case
Licensing restrictions should be relaxed for some use cases such as debugger, host tools and analysis tools. In this document, these use cases are calling the exception use cases.
The OSS used in the exception use case, that must block automatically to installing on the final target image using integration system.
Table 1-3 and Table 1-4 shows exception for Table 1-1 and Table 1-2. In excepted use-case can use licence license both Table 1-1 and Table 1-3. When the same license appears in more than one table, Table 1-3 is preferred over Table 1-2, Table 1-4 is preferred over Table 1-1.
Table 1-3. Exception Special allow licence listlicense list
| No. | License name | License URL |
|---|---|---|
| 1 | GNU General Public License, version 3 | https://www.gnu.org/licenses/gpl-3.0.en.html |
| 2 | GNU Lesser General Public License, version 3 | https://www.gnu.org/licenses/lgpl-3.0.en.html |
*The GPLv3 and GPLv3 like license does not allow tivoization. When these software only to use debugging (not installing in final product), it's no problem.
Table 1-2. Exception Special deny license list
| No. | License name | License URL |
|---|---|---|
...
| No. | Requirement | Example | Req. Level |
|---|---|---|---|
| 1 | Defining the coding rule or guideline | https://www.kernel.org/doc/html/latest/process/coding-style.html | Must |
| 2 | Defining the contribution rule | https://www.kernel.org/doc/html/latest/process/code-of-conduct-interpretation.html | Must |
3 | Have a versioning and stable releaseDefining the release rule. | https://www.gnu.org/software/libc/ | Must |
| 4 | Providing a change logs. | https://sourceware.org/legacy-ml/libc-announce/2020/msg00001.html https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.4.54 | Must |
| 5 | Have a bug tracking system or other bug report and fix solution such as active mailing list, github issue, etc.. | ShallShould | |
| 6 | Have and maintain a test suite. | https://github.com/linux-test-project/ltp | ShallShould |
| 7 | Used in popular distributions such as RHEL, SUSE, Ubuntu, Debian. | ShallShould | |
8 | More than 2 or more active contributors. | https://www.openhub.net/explore/projects | ShallShould |
9 | Including OIN(Open Invention Network) packages list | https://www.openinventionnetwork.com/joining-oin/linux-system/linux-system-table/?cat_id=15&type=table | Recommend |
...
1st step is analyzing for history of code quality using static analysis tool. Has a serious bug been fixed with the minor version up? When major version up is made, how many new serious bugs increase this OSS?
This analysis cannot be based on the number of bug fix. It need to use a static analysis tool to analyze the unfixed bugs.
These OSS must pass on these check items. Qualification point: TBD.
- Outstanding defect per component.
- Outstanding vs fixed defect over period time.
- High and medium impact outstanding defect per category.
Ref. https://scan.coverity.com/projects/gnu-c-library-glibcmust not include "must fix" error from static analysis tool.
Note. The validity of the version used by that OSS, including CVE checks, will be checked in the next phase.
TO J.S.
Could you make a comparison both coverity and the OSS tool (clang) in this criteria.
Coverity vs OSS tool (clang) in architecture phase criteria
5. Requirement matching
All requirements assigned to the OSS must be met.
...