Guide

Hyundai AutoEver, which respects the spirit of openness and sharing, has released open source guide documents for internal members so that anyone can use it. (However, some contents such as the website link of the company system are excluded.)

Using the open source when developing the software has become a must, not an option due to many benefits : shortening development periods and reducing costs. Have you ever wondered if you are using a lot of open source properly when developing in the company?

Organizations that use open source or contribute to the open source community have the necessary activities to protect their intellectual property and mitigate compliance risks. These activities are called open source compliance activities, and there are five essential elements to establish open source compliance.

Organization

OSPO (Open Source Program Office) means a center organization that manages open source and reduce open source compliance risk in the company. It can play a role to build the overall open source strategy of the company such as auditing and constituting other policies on the use and distribution of open source, training for the software developers in the company, spreading an open source culture and activating participation in open source community.

Policy

After the organization has been configured, the next step is to establish a policy. Open source policy is necessary to protect intellectual property and mitigate compliance risk when organizations that distribute software use or contribute to open source. For efficient open source compliance activities, each company needs to establish the policy that matches the software type and business type. The following discloses how Hyundai Autoever has established an open source policy.

1. Purpose

This policy was established to ensure that all organizations using open source conduct open source compliance activities. This policy also provides a way for employees to understand the value of open source and contribute to the open source community. Hyundai AutoEver’s employees contribute to the effectiveness of the policy and the level of compliance of the company by understanding the basis and content of this policy and faithfully performing the necessary activities. It is important to comply with this policy. Non-compliance may result in the following: - Legal claims by the holder of copyrights or other intellectual property rights for the code in use. - Claims from customers - Unintentional disclosure of company’s proprietary code - Fines for breach of license obligations - Loss of reputation/revenue - Violation of contracts with suppliers and customers For this reason, Hyundai AutoEver takes violations of this code seriously, and individuals who violate the code may be subject to disciplinary action by the company.

2. Application

This open source policy applies to “all products provided or distributed externally by the company.” The internal use of open source is not within the scope of this policy. Additionally, this policy applies when Hyundai AutoEver employees contribute to open source projects or disclose Hyundai AutoEver’s code as open source. You can find Hyundai AutoEver’s open source policy through the Open Source Compliance.

3. Terminology

“Open Source” - Software covered by one or more licenses that meet the Open Source Definition published by the Open Source Initiative (OpenSource.org) or the Free Software Definition published by the Free Software Foundation, or similar licenses.

4. Roles, Responsibilities and Competencies

In order to ensure the effective implementation of this policy, the following roles and responsibilities are defined as well as the competencies required of individuals in each role.

The chief officer responsible for developing and distributing Hyundai AutoEver’s software must ensure that a person is designated to be in charge of each role and responsibility, and that appropriate time and funds are allocated to fulfill each role. If the person in charge of each role does not have adequate support for their respective role, the problem must be resolved through the Open Source Manager. If not properly resolved, the issue can be raised through the Open Source Steering Committee.

A) Open Source Manager

The Open Source Manager is responsible for ensuring the compliance of Hyundai AutoEver’s products that utilize open source, and is responsible for the following: - Review, improve and disseminate open source policies. - Review and assign roles and responsibilities within the company for efficient open source policy implementation. - Review and implement training and evaluation on issues related to open source compliance. - Serve as the chair of the Open Source Steering Committee and direct related activities. - Responsible for guiding software development teams to understand and comply with open source policies and processes, and raising issues to management when necessary. - Answer external inquiries regarding the use and compliance of open source. The Open Source Manager must understand the open source-related intellectual property risks and development processes in order to perform their duties, and must have competency in communication skills. As of July 2021, the Open Source Manager is Changhan Ryu, head of the Technical Planning Team.

B) Open Source Center

The Open Source Center specializes in open source compliance and defines the processes for effectively achieving compliance. The Open Source Manager has a leadership role, and the members of the center are responsible for assisting the Open Source Manager carry out the necessary responsibilities in an orderly fashion. The Open Source Center is responsible for the following:

- Develop and provide practical compliance training.
- Select, develop and distribute compliance tools.
- Identify any use of open source in Hyundai AutoEver’s products through code inspection and automatic scanning.
- Review and approve requests for the use of open source.
- Maintain records listing use of open source.
- Develop and maintain a website for notices related to open source and disclosure of source codes.

C) Software Development Team The Software Development Team identifies open source to be used for software development, and submits a request for the approval of open source use to the Open Source Center. The Software Development Team is responsible for fulfilling the obligations of the open source licenses applicable to the open source used for software development. The Software Development Team understands open source policies and processes as well as software architecture.

D) Legal Team The Legal Team interprets open source licenses and obligations. Provides guides and guidance to the software development team for fulfilling these obligations. Furthermore, the Legal Team advises on licensing and intellectual property issues, including conflicts caused by incompatible open source licenses. If necessary, participates in open source use reviews and approval decisions.

Provide opinions on requests for review regarding contributions to open source projects.

5. Training and Evaluation

All Hyundai AutoEver employees involved in software distribution are familiar with open source policies through training and evaluation. All persons implementing this policy are to receive, and be evaluated on, basic training covering the competencies required for their roles. The training and evaluation program covers the goals of Hyundai AutoEver’s open source policy, the role of participants in contributing to improving compliance, and the impact on the company and individuals when compliance is not observed. Evaluation records are to be maintained for a minimum of three years.

6. Open Source Usage Policy

In order to use open source, what an open source license is must first be identified, and the obligations required by the license must be reviewed and confirmed. As such, in the software to be supplied, open source and the respective license obligations are identified, and compliance activities according to the license obligations are conducted when distributing the software. In order to perform effectively, follow the Hyundai AutoEver open source compliance processes. The Open Source Manager should consult with the Legal Team with any questions regarding the processes required for open source license compliance. The results of the decision to use open source and the relevant evidence are to be recorded in the open source issue tracking system (Open Source Compliance).

7. External Inquiry Response Policy

Contact information is to be provided for external inquiries/requests related to open source for software distributed by Hyundai AutoEver. To this end, when distributing software, provide the email address of the Open Source Center, and register contact information with the Linux Foundation’s Open Compliance Directory (https://compliance.linuxfoundation.org/references/open-compliance-directory).

Anyone who receives an inquiry related to open source from an external source should contact the Open Source Manager. The Open Source Manager will process the inquiry and assign it to the appropriate person or organization within the company. The Open Source Manager has overall responsibility for assigning and handling inquiries.

In case of non-compliance issues raised from an external source regarding software distributed by Hyundai AutoEver, the Open Source Manager will handle it as follows:

Confirm the receipt of the inquiry and specify appropriate resolution timelines.

Confirm whether the inquiry is related to an actual issue (if not, respond to the inquiry within three business days).

If there is an actual issue, determine an appropriate response method within three days and respond to the inquirer with a response plan.

Operate according to the chosen response plan, and notify the inquirer that the issue has been resolved within 30 days.

Record the above in the open source issue tracking system (Open Source Compliance).

8. Open Source Contribution Policy

In order to add to the business value of open source, Hyundai Autoever encourages participation in and contribution towards external open source projects. However, caution should be exercised against unintentional disclosures or infringement of intellectual property. In order to contribute to an open source project related to the company’s work, there must be approval from the Software Development Team’s leader. Review the open source license and patent terms of the open source project. In addition, prior to contributing to open source projects, review the signature of documents such as the Developer Certificate of Origin (DCO) and Contributor License Agreement (CLA) required by the projects. If necessary, request a review from the Legal Team.

9. OpenChain Compliance

Hyundai AutoEver supports and actively participates in the spirit of the Linux Foundation’s OpenChain project to improve open source compliance in the software supply chain. Hyundai AutoEver’s open source policy is designed to comply with OpenChain Specification 2.0. Hyundai AutoEver affirms that the open source programs, including Hyundai AutoEver’s open source policy, complies with all requirements of OpenChain Specification 2.0. Hyundai AutoEver affirms that the open source programs, including Hyundai AutoEver’s open source policy, are still carrying out activities to comply with all requirements of OpenChain Specification 2.0 18 months after confirming compliance with all requirements.

Process

In order to use open source based on Hyundai AutoEver’s open source policy, it is necessary to first identify what an open source license is, and review and confirm the obligations required by the license.

As such, it is necessary to identify the license obligations of the open source included in the software to be distributed, and conduct open source compliance activities to comply with the license obligations when distributing the software.

Hyundai AutoEver’s open-source compliance processor defines a series of processes for managing open sources used in the software to be distributed. This process includes the following matters:

Identify all open sources used in the software to be distributed.

Identify and track all obligations arising from the identified open source.

Activities to fulfill all obligations

In order to perform the above effectively, all software supply managers of Hyundai AutoEver will perform the following ten steps.

Step 1. Identification of Open Source

The identification step of open source is a review step for identifying open source components. The open source included in the software to be distributed is monitored, regardless of whether it is AutoEver’s proprietary software or a third-party software. The method for identifying an open source is as follows.

• Receive open source use request: A software developer informs the Open Source Manager or the Open Source Center that the software developer wants to use an open source for a specific product, and provides information on the use of an open source package for review and approval.

• Auditing company-developed software: Since developers can create software by copying and importing the source code of an open source, the company-developed software is also audited.

• Third-party software implementation (Due diligence)

Conditions for starting the identification step	
- Receive request from developers for specific open-source use
- Software auditing step in the development process
- Third-party software acquisition and integration into development software

Identification step results
- Create a compliance record for open source
- Source code scan target selection and request

Step 2. Auditing Source Code

In the source code auditing step, source code analysis tools are used to scan the source code to discover open sources. BlackDuck HUB and FOSSID are used as a source code scanning tools. If an open source is found to have an unusable open source license, whether due to policy reasons such as GPL-3.0 or incompatibility due to a licensing conflict, it is to be marked as an issue and a solution should be requested from the development team.

Conditions for starting the source code auditing step
- Source code scan request

Source code auditing step results
- Generate source code scan results (including information such as the origin of open source, licenses, etc.)
- Request for solution from the development team for the identified issues

Step 3. Resolving Issues

Resolve all issues identified in the source code auditing step. Issues are assigned to the development team, and the Open Source Manager confirms whether that all issues are properly resolved.

Conditions for starting the step for resolving issues
- Complete source code scan and identify result-generating issues

Results of step for resolving issues
- Resolve all identified issues

Step 4. Reviews

Once all identified issues have been resolved, the review step follows. The procedure of the review step is as follows.

Software PL: Submit a request for the approval of use of open source included in the software.
Open Source Manager: Upon receipt of a request for approval of use of open source, confirm whether all information is included without omission and proceed with the review process.
Source code auditor: Confirm whether all issues are resolved by auditing source code.
Legal Team: Review licensing issues.

Conditions for starting the review step
- Resolve all identified issues

Review step results
- Ready for approval after review by the Open Source Manager, a source code auditor, the Legal Team, etc.

Step 5. Approval

The approval step follows once the review is completed. The OSRB either approves or rejects the use of open source. In case of rejection, an explanation of the reason and correction methods are suggested. Once the OSRB approves the use of the open source component, the development team begins preparing to fulfill the licensing obligations.

Conditions for starting the approval step
- Review completed

Approval step results
- OSRB approves or rejects the use of open source
- In case of refusal, an explanation of the reason and correction methods are suggested

Step 6. Registration

Open source components approved for use are added to a software inventory (BOM) that tracks the usage of open sources. The BOM contains information such as the name of an open source component, version, software manager’s name, name of the product that uses it, product version, and product release number.

Conditions for starting the registration step
- OSRB approves use of open source

Registration step results
- Register open source components in the BOM

Step 7. Notice

One of the main duties when using open source is the duty of notice. To this end, the following matters are performed:

• Provide copyright and license notices.

• Provide a copy of the license.

• Inform end users how to obtain copies of the source code (if applicable).

Conditions for starting the notice step
- Register open source in the BOM

Notice step results
- Prepare copyright and license notices and report them to relevant departments for inclusion in products

These matters are reported to the relevant departments so that they can be included at the product’s distribution. If there is a screen on the product, a user can check the content of the open source notice in Menu > Open Source Notice Information. If there is no screen on the product, the contents of the open source notice are to be included in the user manual.

Step 8. Pre-Distributions Verifications

In this step, checks are performed to ensure the following matters:

• Collect the source code to be published as required by the open source license.

• The collected source code should match the binary loaded in the product.

• Remove inappropriate comments from the source code.

• Appropriate notices are included with the product. Herein, a written offer for end users to receive the source code should also be provided.

Conditions for starting the pre-distribution verification step
- All open-source components are registered in the BOM

Pre-distribution verification step results
- Measures to fulfill the duty to notice
- Collect source code to be published
- Decide how to provide source code
- Complete pre-distribution verification

Step 9. Distribution

When the pre-distribution verification is completed, the source code package to be published is uploaded to the open source distribution site. It is possible to register by product and version on the open source distribution site. End users can search and download the source code package corresponding to the version of the product they want from the open source distribution site.

Conditions for starting the distribution step 
- All pre-distribution verifications completed

Distribution step results
- Upload the source code package to be published for a specific product version to the open source distribution site

Step 10. Final Verifications

After uploading the source code package to be published to the open-source distribution site, confirm whether the package has been uploaded correctly and whether it can be downloaded and decoded externally without errors. When building according to the license and guarantee of binary generation is requested, confirm whether the building the source code downloaded externally generates a binary without errors according to the instructions in the README, and whether the generated binary is the same as the binary loaded in the product.

 Conditions for starting the final verification step
 - The source code to be published is posted on an open source distribution site

 Final verification step results
 - Confirm whether the externally downloaded product performs without issues and whether it matches the binary of the same version as the product

Tool

For efficient open source compliance, there are many useful tools that automatically analyze open source license on source codes, as well as tools that help manage open source for each project.

Source Code Scanning Tool : BlackDuck, FOSSID
Open Source Management Tool : Confluence
Repository : Github
OSS Guide : Github.io

Education

We are conducting open source basic education and open source advenced education programs.

Reference

- Linux Foundation resources : [https://www.linuxfoundation.org/resources/open-source-guides]
- OpenChain : [https://www.openchainproject.org/resources]
- sktelecom : [https://sktelecom.github.io/en/guide/]
- LG : [https://oss.lge.com/guide/]