6. Tool
Source code scanning tool
You should use a source code scanning tool during the identification of open source and audit phase of the open source compliance process. Source code scanning tools range from freely available, open source-based tools to commercial tools, each with their own strengths and weaknesses, but none of them seem to provide complete functionality to solve all problems. Therefore, companies can choose the appropriate tool for the characteristics and requirements of the product.
Many companies use a combination of these automated source code scanning tools and manual reviews. Linux Foundation’s FOSSology project is an open source source code scanning tool that companies can use for free.
For instructions on how to install and use FOSSology, refer to Get Started.
Dependency analysis tool
In recent software development, build environments that support Package Manager such as Gradle and Maven are used. In such a build environment, even if there is no source code, the required dependency library at build time is received from the remote to compose the supplied software. At this time, the dependency library is included in the supplied software, but it is not detected by the source code scanning tool. Therefore, it is also important to utilize a tool for dependency analysis.
The OSS Review Toolkit provides a dependency analysis tool called Analyzer.
LG Electronics has released FOSSLight Dependency Scanner as an open source. FOSSLight Dependency Scanner supports various package managers such as Gradle, Maven, NPM, PIP, Pub, and Cocoapods.
Open Source BOM Management Tool
3.3.1.2 of the ISO/IEC 5230 standard requires that the open source BOM list included in the supplied software be documented and kept. The open source BOM can also be managed with a spreadsheet program such as Excel. However, if the number and version of supplied software exceed hundreds, it is not easy to manage them manually. Therefore, it is better to use an automated tool to manage it.
SW360, an open source project hosted by the Eclipse Foundation, provides a function to track the list of open source BOM included in the supplied software.
How to install and use SW360 is SW360 wiki
And FOSSLight, an open source released by LG Electronics mentioned above, also provides a function for open source BOM management.
LG Electronics developed FOSSLight on its own and has been managing the open source BOM for supplied software for all business divisions for the past several years, and in June 2021, it announced that it had been released as an open source for anyone to use.
For detailed installation and usage instructions, refer to the following English guide. : https://fosslight.org/fosslight-guide-en/
If you have the above tools, you can prepare the following evidence required by ISO/IEC 5230.
ISO/IEC 5230
- 3.3.1.2 Open source component records for the supplied software that demonstrates the documented procedure was properly followed.
Self Certify
- 3.b : Do you have open source component records for each Supplied Software release which demonstrates the documented procedure was properly followed?
Create artifacts
It is better to use a tool that automatically generates an open source notice, which is an open source compliance product, rather than writing it manually.
You can automatically generate an open source notice by registering an open source BOM using the FOSSLight tool. The open source disclaimer generated by FOSSLight also includes a Written Offer to provide source code.
In addition, SK Telecom is planning to release the open source automatic notice generation tool used in-house.
Archive open source artifacts
It is recommended that companies create an open source website and register open source compliance artifacts to provide convenience so that external customers can download open source notices and source code packages to be disclosed at any time.
You can refer to SK Telecom’s open source website.
In particular, this website was developed as an open source, and since the source code is open, you can easily build a website by referring to it.
If you build a tool environment like this, you can prepare the following evidence required by ISO/IEC 5230.
ISO/IEC 5230
- 3.4.1.2 A documented procedure for archiving copies of the compliance artifacts of the supplied software - where the archive is planned to exist for a reasonable period of time (determined by domain, legal jurisdiction and/or customer contracts) since the last offer of the supplied software; or as required by the identified licenses (whichever is longer). Records exist that demonstrate the procedure has been properly followed.
Self Certify
- 4.b : Do you archive copies of the Compliance Artifacts of the Supplied Software?
- 4.c : Are the copies of the Compliance Artifacts archived for at least as long as the Supplied Software is offered or as required by the Identified Licenses (whichever is longer)?
If you build the tool environment in this way, you will comply with the ISO/IEC 5230 requirements as follows.
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.