Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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 nameLicense URL
1GNU General Public License, version 3https://www.gnu.org/licenses/gpl-3.0.en.html
2GNU Lesser General Public License, version 3https://www.gnu.org/licenses/lgpl-3.0.en.html
3GNU Affero General Public License version 3https://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 nameLicense URL
1GNU General Public License, version 3https://www.gnu.org/licenses/gpl-3.0.en.html
2GNU Lesser General Public License, version 3https://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 nameLicense URL









...


3.

...

Long Term Stable

Assessing the code quality of the OSS.  The LTS (Long Term Stable) must be provided by one of the following means

  1. LTS support by upstream community.
  2. Use of existing LTS distribution down stream code base.



4. Source code assessment

...

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-glibc

must 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 matching5. Requirement matching

All requirements assigned to the OSS must be met.

If the requirements are not met, the software must be reassigned to another OSS or AGL developed code.