Open Source Guide

• 1: Consume Open Source
• 1.1: Considerations When Choosing Open Source
• 1.2: What Is an Open Source License?
• 1.3: Checking an Open Source License
• 1.4: Obligations by Open Source License
• 1.4.1: AGPL-3.0 Guide
• 1.4.2: Apache-2.0 Guide
• 1.4.3: BigScience RAIL Guide
• 1.4.4: BSD-2-Clause Guide
• 1.4.5: BSD-3-Clause Guide
• 1.4.6: BSD-4-Clause Guide
• 1.4.7: BSL Guide
• 1.4.8: CDDL-1.0 Guide
• 1.4.9: CreativeML Open RAIL-M Guide
• 1.4.10: Elastic License 2.0 Guide
• 1.4.11: EPL-2.0 Guide
• 1.4.12: GPL-2.0 Guide
• 1.4.13: GPL-3.0 Guide
• 1.4.14: LGPL-2.1 Guide
• 1.4.15: LGPL-3.0 Guide
• 1.4.16: Llama 2 Community License Guide
• 1.4.17: MIT Guide
• 1.4.18: MPL-2.0 Guide
• 1.4.19: SSPL Guide
• 2: Contributing to Open Source
• 2.1: Benefits of Open Source Contribution
• 2.2: SK Telecom Open Source Contribution Rules
• 2.3: SK Telecom Open Source Contribution Process
• 2.3.1: Detailed Contribution Submission Process
• 2.4: Background on Open Source Contribution
• 2.4.1: Types of Open Source Contribution
• 2.4.2: Open Source Project Membership
• 2.4.3: Key Documents in an Open Source Project
• 2.4.4: How to Become a Good Contributor
• 2.4.5: How to Identify a Good Project to Contribute To
• 2.4.6: How to Communicate
• 3: Releasing Open Source
• 3.1: Benefits of Releasing Open Source
• 3.2: SK Telecom Open Source Release Rules
• 3.3: SK Telecom Open Source Release Process
• 3.3.1: Deciding the Open Source Project Name
• 3.3.2: Copyright and License Notices in Files
• 4: Supply Chain Security
• 4.1: Software Supply Chain Attacks and the Need for Security
• 4.1.1: Regulatory Trends
• 4.1.2: SK Telecom Supply Chain Security Policy
• 4.2: What Is an SBOM?
• 4.2.1: SBOM Concept and Necessity
• 4.2.2: SBOM Standards
• 4.3: Supplier SBOM Submission Guide
• 4.3.1: SBOM Submission Requirements
• 4.3.2: SKT SBOM Generator
• 4.3.3: Generating an SBOM with Open Source Tools
• 4.3.4: Pre-Submission SBOM Validation Checklist
• 4.3.5: SBOM Submission Process
• 5: Open Source Education Slides

1 - Consume Open Source

Open source has become such a core element of software development that developing a product or service without using open source can be considered virtually impossible. By using open source, you can shorten software development time while also strengthening service stability and security. However, when you use open source, you must check what its license is and comply with the obligations the license requires.

This section explains how to take external open source and use it correctly in SK Telecom’s products or services, along with the points that require attention.

Considerations When Choosing Open Source to Use

If you have decided to use open source to implement a needed feature, which one should you choose among the several open source projects that offer similar functionality? Let’s look at the points to consider from various angles.

• Considerations When Choosing Open Source

Open Source Compliance Activities

To avoid creating legal problems when a company develops products/services using open source, it must check the open source licenses and comply with what each license requires. These activities are called open source compliance. SK Telecom members must carry out appropriate compliance activities while using open source.

What Is an Open Source License?

To use open source correctly, you must first understand copyright and open source licenses.

• Copyright protects software. When software is developed, copyright law prohibits anyone other than the copyright holder from using, copying, modifying, or distributing that software.
• The purpose of open source is to allow many people to freely use, modify, and distribute it. For this, a license that explicitly grants these rights is required. This is called an open source license, and software to which no open source license applies is not open source. If it is not open source, no one other than the copyright holder may use, copy, modify, or distribute that software.

For details about open source licenses, refer to the following page.

• What Is an Open Source License?

Checking the License

An open source license can be checked in several ways, even without using analysis tools.
For how to check the license of the open source you intend to use, refer to the following page.

• Checking an Open Source License

Obligations by License

SK Telecom strongly encourages the use of open source when developing products/services. However, to protect SK Telecom’s intellectual property, the obligations required by each open source license must be observed. SK Telecom members must understand these, check the license when using open source, and comply with the obligations. To learn which open source licenses require caution, see the following page.

• Obligations by Open Source License

License Obligation Compliance Activities

When distributing SK Telecom’s products/services that include open source, you must comply with what each open source license requires. Depending on the open source license, some require only notice obligations, while others go as far as requiring source code disclosure.

• Notice obligation: At a minimum, you must comply with the notice obligations required by most open source licenses, such as “copyright notice” and “license notice.” For example, a mobile application distributed by SK Telecom can provide the required notices through an “About” page.
• Source disclosure obligation: When distributing software that includes open source under a Copyleft license that requires source code disclosure, you must either provide the source code directly to the user or provide a written offer to supply the source code upon the user’s request.

Activities that minimize legal risk by complying with open source license obligations in this way are called open source compliance.

Open Source Security Vulnerability Review Activities

Self-Inspection

Checking CVE

CVE provides a database of known open source security vulnerabilities. You can search for the open source you intend to use in CVE to check whether it has any known security vulnerabilities.

Checking GitHub

GitHub, the representative open source repository, detects vulnerable dependencies in public repositories and generates Dependabot alerts.

Requesting a Security Vulnerability Assessment

SK Telecom operates tools for assessing open source security vulnerabilities. You can request an assessment from the responsible department (Information Security).

• Request an Open Source Security Vulnerability Assessment

SK Telecom Open Source Policy

For the SK Telecom open source policy, departmental R&R, and verification process, refer to the following page.

• Open Source Review Process (internal only)

1.1 - Considerations When Choosing Open Source

If you have decided to use open source to implement a needed feature, which one should you choose among the several open source projects that offer similar functionality? Let’s look at the points to consider from various angles.

Quality

The quality of open source — including functionality, performance, and compatibility — is the most important factor when choosing open source. For a project hosted on GitHub, you can gauge the maturity of the open source by its number of stars and forks. A technical organization that intends to use open source should thoroughly verify its functionality and performance before adopting it into a product/service.

Community

Whether the community is active — how many users the open source has, whether issues are well managed, and whether it is continuously updated — is also a consideration when choosing open source. It is more advantageous to choose open source with a community that is still active today than one whose community activity stopped years ago.

Documentation

To properly adopt and maintain open source, you should also check how thoroughly the project provides documentation. The deliverables of a well-documented project are easier for a company to adopt. It also makes it easier to contribute the company’s improvements back to the project as patches.

Security Vulnerabilities

Open source with known security vulnerabilities should not be used. Versions of open source in which security vulnerabilities have been found are tracked in databases such as CVE. You should check whether the version of the open source you intend to use has security vulnerabilities before using it.

License

An open source license is a permit that grants everyone the right to use the software freely. However, most open source licenses impose obligations that must be observed when redistributing the open source — for example, notice obligations and source code disclosure obligations. GPL-2.0, a representative open source license, requires that even the source code of software combined with it be disclosed. Therefore, when choosing open source, you must check in advance what its license is and whether you can operate in an environment that complies with that license. The open source compliance activities for this are explained below.

1.2 - What Is an Open Source License?

What Is Open Source?

Open source refers to software whose source code, distributed through a licensing scheme, can be freely copied, modified, used, and redistributed. With open source, anyone can fix bugs or adapt the code to add features, and can participate in software development. In this way, open source provides developers with the right to distribute the program, the right to access the source code, and the right to modify the source code.

Open Source Carries Legal Responsibilities Too!

Open source is widely used because, when leveraged well, it can reduce development cost and time. However, quite a few users are not well aware of the legal responsibilities of open source and the risks that come with them.

• Just like commercial software, to use open source you must comply with that open source’s license. If you violate it, your right to use it is revoked, and if you have turned it into a product, you cannot sell that product.
• You may also face claims from the open source community, severely damaging your corporate image as a license-violating company.
• In the worst case, you could become involved in legal litigation, so it is important to know about open source in advance and prepare accordingly. The legal responsibilities of open source differ depending on the type of open source license, so when using open source you must understand the legal responsibilities of each license.

Software Intellectual Property Rights

To understand the legal risks of open source, you need to understand the basic concepts of intellectual property rights in software and of licenses, because an open source license is a type of software license. The legal mechanisms that protect software — that is, the intellectual property rights related to software — include copyright, patent rights, trademark rights, and trade secrets.

Copyright

Copyright is the right that a creator (author) acquires over their creation; it protects the result of the creation and arises at the same time as the creation. Therefore, when a programmer develops software, copyright arises automatically, and that right is granted to the programmer or the company they belong to. A copyrighted work may not be copied, distributed, or modified by anyone without the copyright holder’s permission.

Patent

A patent is an exclusive and exclusionary right that an inventor (patent holder) holds over an invention. Unlike copyright, a patent must be filed in a prescribed manner and only takes effect once it has passed examination and been registered. To use a patented technology, you must obtain the patent holder’s permission. Software that implements a patented method falls within the scope of the patent regardless of the programming language used.

Software License

A rights holder who has an exclusive and exclusionary right over software may permit others to use or distribute that software. Simply put, a license is permission for others to use, copy, modify, distribute, and so on, one’s own work.

• Typical commercial software requires a royalty in return.

Open Source License

Just like ordinary commercial software, open source also has intellectual property rights such as copyright. Therefore, if you use it carelessly without the rights holder’s permission, you may face litigation. However, open source rights holders grant broad licenses so that many people can use the software freely.

For example, they grant users not only the right to use the software but also to copy and distribute it freely, and even provide the source code so that it can be modified freely. For this, an open source license that explicitly expresses these rights is required. Therefore, software to which no open source license applies is not open source, and no one other than the copyright holder may use, copy, modify, or distribute that software.

Open source licenses do not require a royalty like commercial software does; instead, they require a few obligations to be observed, such as providing the source code.

Key Obligations

It is important to understand and comply with the obligations of open source. The general obligations of open source licenses are notice and source code disclosure.

Copyright Notice and License Notice

Most open source licenses require that information about the developers or contributors and about copyright be displayed in or included with the product, and they require the distributor to attach a copy of the relevant license so that users can clearly understand their rights regarding the open source.

e.g.) Apache License 2.0
 
4. a. You must give any other recipients of the Work or Derivative Works a copy of
this License;
 
4. c. You must retain, in the Source form of any Derivative Works that You distribute,
all copyright, patent, trademark, and attribution notices from the Source form of the
Work, excluding those notices that do not pertain to any part of the Derivative Works;

Source Code Disclosure

Representatively, GPL-family licenses allow software to be distributed in binary form but require that the source code corresponding to the binary be disclosed together with it.

e.g.) GPL 2.0
 
3. You may copy and distribute the Program (or a work based on it, under Section 2) in
object code or executable form under the terms of Sections 1 and 2 above provided that
you also do one of the following:
 a) Accompany it with the complete corresponding machine-readable source code,

Applying the Same License Upon Redistribution

The part that differs greatly depending on the license concerns ‘Copyleft’. Copyleft licenses, represented by the GPL, require that when users modify software and wish to distribute it, the modified software also be distributed under the same license.

e.g.) GPL 2.0
 
2. You may modify your copy or copies of the Program or any portion of it, thus forming
a work based on the Program, and copy and distribute such modifications or work under
the terms of Section 1 above, provided that you also meet all of these conditions:
 b) You must cause any work that you distribute or publish, that in whole or in part
contains or is derived from the Program or any part thereof, to be licensed as a whole
at no charge to all third parties under the terms of this License.

1.3 - Checking an Open Source License

An open source license can be checked in several ways. You can check it manually without using analysis tools, or you can check it efficiently using automation tools.

Manual Methods

Method 1. Check the Comments at the Top of the Source Code File

Typical open source displays copyright and license information in the comments at the top of the source code file.

(https://github.com/SKTBrain/KoBERT/blob/master/kobert/pytorch_kobert.py)

You can identify the open source license from this content.

SK Telecom provides a tool called FOSSology so that anyone can easily check the open source license at the top of a source code file.

Method 2. Check the LICENSE (or COPYING) File in the Root Folder

Typical open source displays license information in a LICENSE or COPYING file in the root folder.

(https://github.com/openinfradev/tacoplay)

Method 3. Check the License Information in the README or on the Website

Some open source provides license information in the README that describes the project or in documentation on the website.

(https://github.com/metatron-app/metatron-discovery)

Checking with Automation Tools

For large-scale projects or those with many dependencies, you can use automation tools to check licenses efficiently.

Syft

Syft is a tool that generates an SBOM from container images and file systems and extracts license information.

syft dir:. -o json

Trivy

Trivy is a tool that can check license information alongside vulnerability scanning.

trivy fs --scanners license .

Caution: Trivy was the victim of a supply chain attack in 2025 through release tag tampering. When installing the CLI, use the official release channels, and in GitHub Actions, use a verified pinned version such as @0.35.0 instead of mutable tags (@latest, @master, etc.). For details, refer to the SBOM Generation Guide.

For detailed usage of automation tools, refer to the Automation section.

Priority of License Information

If the information indicated by Methods 1-3 differs from one another, base your judgment on Method 1 — that is, give priority to the license information shown within the file.

1.4 - Obligations by Open Source License

Free to Use If Not Redistributed

First, most open source licenses impose obligations only upon ‘redistribution’. In other words, if you do not ‘redistribute’ the open source, obligations such as notice and source code disclosure do not arise, so you can use it freely.

1. Unrestricted Licenses (Public Domain)

There are licenses, such as CC0 and Public Domain, that can be used for free without any restrictions.

2. Permissive Licenses (Easy to Use)

Open source licenses that can be classified as Permissive Licenses require notice obligations. The notice obligations of open source licenses are relatively easy to comply with.

When distributing software that includes open source under a Permissive license that requires notice obligations in this way, you must comply with obligations such as “copyright notice” and “license notice.” (Reference: Copyright Notice and License Notice)

Through the SK Telecom open source compliance process, you can issue an open source notice and enclose it when distributing software to fulfill the notice obligation.

2-1. Major Permissive Licenses

The following are the Permissive licenses most frequently used in practice, with use-case guides provided.

2-2. Other Permissive Licenses

In addition, there are other Permissive licenses such as those below. These too can be used freely as long as you comply with the notice obligations.

• Academic Free License v2.1 (AFL-2.1)
• Academic Free License v3.0 (AFL-3.0)
• Artistic License 1.0 (Perl) (Artistic-1.0-Perl)
• Artistic License 2.0 (Artistic-2.0)
• Apache Software License 1.1 (Apache-1.1)
• Boost Software License 1.0 (BSL-1.0)
• BSD-2-Clause Plus Patent License (BSD-2-Clause-Patent)
• Creative Commons Attribution 4.0 International (CC-BY-4.0)
• JSON License (JSON)
• The FreeType Project License (FTL)
• Independent JPEG Group License (IJG)
• libtiff License (libtiff)
• Lucent Public License v1.02 (LPL-1.02)
• Microsoft Public License (MS-PL)
• X11 License (X11)
• CMU License (MIT-CMU)
• University of Illinois/NCSA Open Source License (NCSA)
• OpenSSL License (OpenSSL)
• TCP Wrappers License (TCP-wrappers)
• Unicode License v3 (Unicode-3.0)
• X.Net License (Xnet)
• Zend License v2.0 (Zend-2.0)
• Zope Public License 2.1 (ZPL-2.1)

3. Weak Copyleft (Conditionally Usable)

Weak Copyleft type licenses require source code disclosure, but have the characteristic that the scope of disclosure is more limited than that of Copyleft type licenses.

The open source licenses that can be classified as Weak Copyleft type licenses are as follows.

When distributing software that includes open source under a Copyleft license, you must either provide the source code directly to the user or provide a written offer to supply the source code upon the user’s request.

4. Copyleft (Use with Caution)

The GPL (GNU General Public License) requires source code disclosure when redistributing open source. Because it requires that not only the open source’s own source code but also any combined source code be disclosed together under the same license terms, it is also called a Copyleft-type license. Since the Copyleft license type imposes the most obligations among open source licenses, open source distributed under this type of license requires caution when used.

The open source licenses that can be classified as Copyleft type licenses are as follows.

5. Network Copyleft (Caution When Providing SaaS)

The AGPL (GNU Affero General Public License) extends the “distribution” concept of the ordinary GPL to treat the provision of a service over a network as distribution as well.

6. Source Available (Restricted Open Source)

A Source Available license is one whose source code is publicly available but which is not an open source license approved by the OSI (Open Source Initiative). These place restrictions on things like commercial SaaS offerings and have conditions different from ordinary open source.

7. AI Model Licenses

AI Model licenses are licenses applied to AI models (weights) and have characteristics different from ordinary software licenses. They allow use, modification, and distribution of the model but include restrictions on specific uses.

8. Use-Restricted Licenses

8-1. Non-Commercial

Even for research or learning purposes only, use within SK Telecom may be regarded as a commercial activity. Therefore, open source released under a license that restricts use to non-commercial purposes only cannot be used at SK Telecom. Such Non-Commercial licenses are as follows.

8-2. Advertising Clause Included

The BSD-4-Clause license requires that a specific phrase (“This product includes software developed by the .”) be included in all advertising that mentions the features/use of the open source. Because complying with this “advertising clause” requirement is not easy, its use is restricted.

If you absolutely must include open source under such a license, please ask the OSPO how it can be included.

• Support (opensource@sktelecom.com)

9. Document/Content Licenses

Creative Commons licenses are licenses used mainly for content such as documents, images, and datasets. They are licenses better suited to creative works than to software code.

10. Other Licenses Not Mentioned

To use open source under a license not classified above in an SK Telecom product, prior review is required. Please ask the OSPO whether it can be used.

• Support (opensource@sktelecom.com)

1.4.1 - AGPL-3.0 Guide

SPDX Identifier: AGPL-3.0-only or AGPL-3.0-or-later

License Statement in Source Code

Open source under the AGPL-3.0 license generally carries the following statement at the top of the source code.

Copyright (C) <year> <name of author>
 
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU Affero General Public License as
published by the Free Software Foundation, either version 3 of the
License, or (at your option) any later version.
 
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU Affero General Public License for more details.
 
You should have received a copy of the GNU Affero General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.

Obligations by Use Case

Case 1. Redistribution in Source Form

When redistributing open source under the AGPL-3.0 license in source form, observe the following.

1-1 Notice Obligation

• Provide the copyright notice
• Provide the warranty disclaimer
• Provide a copy of the license

In other words, redistribute while keeping the copyright/license information stated in the source code intact.

Case 2. Redistribution in Binary Form

When building open source under the AGPL-3.0 license and redistributing it in binary form only, observe the following.

2-1 Notice Obligation

• Provide the copyright notice
• Provide the warranty disclaimer
• Provide a copy of the license

Generate an open source notice containing the above and enclose it when redistributing the binary.

2-2 Source Code Provision Obligation

Provide the source code corresponding to the binary. In doing so, observe the following.

1. AGPL-3.0 requires that derivative works also be licensed under AGPL-3.0 and have their source code disclosed. Referring to the content below, disclose the source code of the AGPL-3.0 open source and its derivative works.

2. Provide a build environment that allows binary users to build an identical binary from the disclosed source code. This includes the following.
   • Tool chain information
   • Build scripts
   • Build instructions (README)

Instead of the source code, you may provide a Written Offer. It must include the following statements.

1. The Written Offer is valid for three years after the product is sold.
2. It is offered to anyone.
3. No fee is charged. (excluding the cost incurred for delivering the source)

2-3 Installation Information Obligation

If the binary is distributed together with a User Product, provide the Installation Information.

• User Product: An embedded device such as an electronic device
• Installation Information: All information and methods the user needs to build the source code and reinstall it on the product

Case 3. Remote Network Interaction

If you (1) modify open source under the AGPL-3.0 license and (2) the modified version interacts with remote users over a network:

• You must provide a network server from which remote users can download the source code of the modified version.
• The source code here is the same in scope as that required in “2-2. Source Code Provision Obligation” above.

Differences from GPL-3.0

AGPL-3.0 is a license that adds a network use clause to GPL-3.0.

• GPL-3.0: Source code disclosure obligation only when distributing binaries
• AGPL-3.0: Source code disclosure obligation when distributing binaries AND when providing a service over a network

This clause is intended to prevent circumvention of GPL’s source code disclosure obligation by providing software as SaaS or a cloud service.

License Compatibility

Compatibility with Major Licenses

References

• AGPL-3.0 License Full Text
• SPDX License List - AGPL-3.0
• GNU AGPL FAQ
• OSADL License Checklist

1.4.2 - Apache-2.0 Guide

SPDX Identifier: Apache-2.0

License Statement in Source Code

Open source under the Apache-2.0 license generally carries the following statement at the top of the source code.

Copyright [yyyy] [name of copyright owner]
 
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
 
http://www.apache.org/licenses/LICENSE-2.0
 
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

Obligations by Use Case

Case 1. Redistribution in Source Form

When redistributing open source under the Apache-2.0 license in source form, observe the following.

1-1 Notice Obligation

• Provide a copy of the license
• Retain information such as copyright, patent, and trademark notices.
• If a NOTICE file is included, retain it.

In other words, redistribute while keeping the copyright/license information stated in the source code intact.

Case 2. Redistribution in Binary Form

When building open source under the Apache-2.0 license and redistributing it in binary form only, observe the following.

2-1 Notice Obligation

• Provide a copy of the license
• Retain information such as copyright, patent, and trademark notices.
• If a NOTICE file is included, retain it.

Generate an open source notice containing the above and enclose it when redistributing the binary.

License Compatibility

The Apache-2.0 license includes an explicit patent grant clause, making it compatible with most licenses.

Compatibility with Major Licenses

References

• Apache License 2.0 Full Text
• SPDX License List - Apache-2.0
• OSADL License Checklist

1.4.3 - BigScience RAIL Guide

SPDX Identifier: BigScience-RAIL-1.0

What Is BigScience RAIL?

BigScience RAIL (Responsible AI License) is a license that the BigScience project released in 2022 together with the BLOOM language model.

The BigScience Project

• BLOOM: A 176B-parameter multilingual language model
• More than 1,000 researchers participated
• Set responsible AI development as a core value

Two Versions of RAIL

BigScience uses RAIL-M (applied only to the model)

Major Projects Using It

The BLOOM Family

• BLOOM: BigScience’s 176B model
• BLOOMZ: An instruction-following version
• mT0: A multilingual zero-shot model

Other Models Adopting RAIL

• Some open LLM fine-tuned models
• Research language models

Permitted Items

What You Can Do Freely

1. Model use

   • Text generation
   • Translation, summarization, question answering
   • Building chatbots
   • Providing commercial services

2. Model modification

   • Fine-tuning
   • Additional training
   • Lightweighting such as LoRA, QLoRA

3. Model distribution

   • Releasing modified models
   • Distributing derivative models
   • Commercial API services

4. Use of generated outputs

   • Commercial use of AI-generated text
   • Creating secondary works

Prohibited Items (Restrictions)

BigScience RAIL cannot be used for the following purposes:

1. Illegal Activities

• Supporting the planning or execution of crimes
• Generating illegal content
• Supporting terrorist activities

2. Child Protection

• Generating child sexual exploitation material
• Harmful content targeting children
• Supporting child grooming

3. Discrimination and Hate

• Discrimination based on race, ethnicity, or religion
• Discrimination based on gender or sexual orientation
• Discrimination based on disability or age
• Generating hate speech

4. Disinformation and Manipulation

• Intentionally generating fake news
• Generating deepfake text (for identity theft)
• Content for election manipulation
• Content for fraud

5. Privacy Violations

• Unauthorized collection of personal information
• Supporting stalking and harassment
• Use for surveillance purposes

6. Medical and Legal

• Replacing professional medical diagnosis
• Replacing legal advice
• Replacing financial advice

7. Self-Harm and Violence

• Encouraging suicide or self-harm
• Inciting violence
• Weapons manufacturing information

8. High-Risk Decision-Making

• Automated credit scoring (sole decision-making)
• Automated hiring decisions (sole decision-making)
• Criminal justice decisions (sole decision-making)

Use Scenarios

Permitted Uses

1. Chatbot Service

Scenario: A customer consultation chatbot
Method of use: Fine-tuning BLOOM to build a consultation bot
Judgment: Allowed (commercial use is OK, not a prohibited use)

2. Translation Service

Scenario: Multilingual automatic translation
Method of use: Leveraging BLOOM’s multilingual capability
Judgment: Allowed

3. Content Generation Tool

Scenario: A marketing copy generation tool
Method of use: BLOOM-based text generation
Judgment: Allowed (when not discriminatory/false content)

Prohibited Uses

1. Fake News Generator

Scenario: An automatic fake news generation tool
Method of use: Mass generation of disinformation
Judgment: Prohibited (generating disinformation)

2. Generating Discriminatory Content

Scenario: Generating text that demeans a specific group
Method of use: Generating hate speech
Judgment: Prohibited (discrimination and hate)

3. Automated Credit Scoring

Scenario: Automatically determining credit scores with an LLM
Method of use: Automatic approval/denial of loans
Judgment: Prohibited (high-risk decision-making)

Requires Review

1. Educational Chatbot

Scenario: A student counseling chatbot
Method of use: Career counseling, psychological counseling
Judgment: At the boundary of medical/psychological advice, expert review required

2. Hiring Assistance Tool

Scenario: Resume screening assistance
Method of use: A human makes the final decision, but the AI recommends
Judgment: Depends on the method of use, OSPO review

Model Card Obligation

BigScience RAIL recommends providing a Model Card.

Content to Include in the Model Card

1. Model information

   • Model architecture, number of parameters
   • Source of training data
   • Training method

2. Limitations

   • The model’s limitations
   • Known bias
   • Inappropriate use cases

3. Usage guide

   • Recommended use cases
   • Prohibited items
   • Ethical considerations

Example: BLOOM Model Card

Licensing of Derivative Models

When distributing a derivative model:

Mandatory Items

• Apply the same use restrictions
• State the license information
• Provide a model card (recommended)

License Propagation

If you create a custom model by fine-tuning BLOOM, you must apply BigScience RAIL or equivalent restrictions to the custom model as well.

Responsibility for AI-Generated Outputs

Important: Responsibility for Generated Text

• Model provider: Obligation to state model use restrictions
• Model user: Obligation to verify the legality of generated outputs
• Service provider: Obligation to take measures to prevent users’ misuse

References

• BigScience RAIL-1.0 Full Text
• SPDX License List - BigScience-RAIL-1.0
• BLOOM Model Card
• Responsible AI Licenses Initiative

1.4.4 - BSD-2-Clause Guide

SPDX Identifier: BSD-2-Clause

License Statement in Source Code

Open source under the BSD-2-Clause license generally carries the following statement at the top of the source code.

Copyright (c) <YEAR>, <OWNER>
All rights reserved.
 
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
 
1. Redistributions of source code must retain the above copyright notice, this
list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
 
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR
ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Obligations by Use Case

Case 1. Redistribution in Source Form

When redistributing open source under the BSD-2-Clause license in source form, observe the following.

1-1 Notice Obligation

• Copyright notice
• Provide a copy of the license
• Warranty disclaimer notice

In other words, keep the copyright, license, and so on within the source code intact.

Case 2. Redistribution in Binary Form

When building open source under the BSD-2-Clause license and redistributing it in binary form only, observe the following.

2-1 Notice Obligation

• Copyright notice
• Provide a copy of the license
• Warranty disclaimer notice

Generate an open source notice containing the above and enclose it when redistributing the binary.

License Compatibility

The BSD-2-Clause license is the most concise among the BSD licenses and is compatible with most licenses.

Compatibility with Major Licenses

References

• BSD-2-Clause License Full Text
• SPDX License List - BSD-2-Clause
• OSADL License Checklist

1.4.5 - BSD-3-Clause Guide

SPDX Identifier: BSD-3-Clause

License Statement in Source Code

Open source under the BSD-3-Clause license generally carries the following statement at the top of the source code.

Copyright (c) <year>, <copyright holder>
All rights reserved.
 
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
 
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
* Neither the name of the <organization> nor the
names of its contributors may be used to endorse or promote products
derived from this software without specific prior written permission.
 
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL <COPYRIGHT HOLDER> BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Obligations by Use Case

Case 1. Redistribution in Source Form

When redistributing open source under the BSD-3-Clause license in source form, observe the following.

1-1 Notice Obligation

• Copyright notice
• Provide a copy of the license
• Warranty disclaimer notice

In other words, keep the copyright, license, and so on within the source code intact.

Case 2. Redistribution in Binary Form

When building open source under the BSD-3-Clause license and redistributing it in binary form only, observe the following.

2-1 Notice Obligation

• Copyright notice
• Provide a copy of the license
• Warranty disclaimer notice

Generate an open source notice containing the above and enclose it when redistributing the binary.

License Compatibility

The BSD-3-Clause license includes a clause prohibiting unauthorized use of the organization’s name and is compatible with most licenses.

Compatibility with Major Licenses

References

• BSD-3-Clause License Full Text
• SPDX License List - BSD-3-Clause
• OSADL License Checklist

1.4.6 - BSD-4-Clause Guide

SPDX Identifier: BSD-4-Clause

License Statement in Source Code

Open source under the BSD-4-Clause license generally carries the following statement at the top of the source code.

Copyright (c) <year>, <copyright holder>
All rights reserved.
 
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
 
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
3. All advertising materials mentioning features or use of this software
must display the following acknowledgement:
This product includes software developed by the <organization>.
4. Neither the name of the <organization> nor the
names of its contributors may be used to endorse or promote products
derived from this software without specific prior written permission.
 
THIS SOFTWARE IS PROVIDED BY <COPYRIGHT HOLDER> ''AS IS'' AND ANY
EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL <COPYRIGHT HOLDER> BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Obligations by Use Case

Case 1. Redistribution in Source Form

When redistributing open source under the BSD-4-Clause license in source form, observe the following.

1-1 Notice Obligation

• Copyright notice
• Provide a copy of the license
• Warranty disclaimer notice
• Include the following statement in all advertising that mentions features or use of the BSD-4-Clause open source
  “This product includes software developed by the <organization>."

In other words, keep the copyright, license, and so on within the source code intact.

Case 2. Redistribution in Binary Form

When building open source under the BSD-4-Clause license and redistributing it in binary form only, observe the following.

2-1 Notice Obligation

• Copyright notice
• Provide a copy of the license
• Warranty disclaimer notice
• Include the following statement in all advertising that mentions features or use of the BSD-4-Clause open source
  “This product includes software developed by the <organization>."

Generate an open source notice containing the above and enclose it when redistributing the binary.

License Compatibility

Due to the advertising clause, BSD-4-Clause has compatibility issues with other licenses.

Compatibility with Major Licenses

References

• BSD-4-Clause License Full Text
• SPDX License List - BSD-4-Clause
• OSADL License Checklist

1.4.7 - BSL Guide

SPDX Identifier: BUSL-1.1 (also referred to as BSL-1.1)

What Is BSL?

BSL (Business Source License) is a license created by MariaDB Corporation in 2013. Its core characteristic is that it is a time-limited license.

How It Works

1. Initial period (before the Change Date)

   • Certain commercial uses are restricted
   • The source code is publicly available
   • Non-commercial/internal use is generally permitted

2. Conversion period (after the Change Date)

   • Automatically converts to a true open source license
   • Usually converts to Apache-2.0, GPL-2.0, MIT, etc.
   • All restrictions are lifted

The Three Main Parameters of BSL

1. Additional Use Grant

Specifies the particular uses that are permitted.

Examples:

• “Services with 1,000 or fewer annual users are permitted”
• “Free use is allowed in non-production environments”
• “Use for the purpose of providing a competing service is prohibited”

2. Change Date

The date on which it converts to open source. Typically set to 3-4 years after release.

Example: If released on January 1, 2024, the Change Date is January 1, 2028.

3. Change License

The open source license it will convert to.

Typically:

• Apache-2.0 (most common)
• GPL-2.0
• MIT

Major Projects Adopting BSL

Databases

• MariaDB (some features): Change License GPL-2.0, Change Date 4 years after release
• CockroachDB: Change License Apache-2.0 or MIT, Change Date 3 years after release

Others

• Ceph (some features)
• MinIO (some editions)
• Sentry (some features)
• Akka (since 2.7)

Determining Whether Use Is Permitted

Cases Generally Permitted

1. Internal development/testing

   • In-house development environments
   • Test servers
   • Prototype development

2. Non-production uses

   • Learning/research
   • Benchmarking
   • Proof of Concept (PoC)

3. Cases specified in the Additional Use Grant

Cases That Are Restricted

1. Commercial production use

   • Services provided to customers
   • Inclusion in and sale of a product
   • Provision as SaaS

2. Providing a competing service

   • Providing a service that competes with the BSL software

Cases Requiring Verification

Because the Additional Use Grant differs for each project, checking the LICENSE file of each project is essential.

Use After the Change Date

Once the Change Date passes, it automatically converts to the Change License.

Example: CockroachDB v20.1 (released May 2020)

• Change Date: May 19, 2023
• Change License: Apache-2.0
• From May 19, 2023, it can be used freely under Apache-2.0

References

• BSL 1.1 Full Text
• SPDX License List - BUSL-1.1
• MariaDB BSL FAQ
• CockroachDB Licensing FAQs

1.4.8 - CDDL-1.0 Guide

SPDX Identifier: CDDL-1.0

Obligations by Use Case

Case 1. Redistribution in Source Form

When redistributing open source under the CDDL-1.0 license in source form, observe the following.

1-1 Notice Obligation

• A copy of the license
• Retain legal notices such as copyright, patent, and trademark notices

In other words, redistribute while keeping the copyright/license information stated in the source code intact.

Case 2. Redistribution in Binary Form

When building open source under the CDDL-1.0 license and redistributing it in binary form only, observe the following.

2-1 Notice Obligation

• Provide a copy of the license
• Retain legal notices such as copyright, patent, and trademark notices

Generate an open source notice containing the above and enclose it when redistributing the binary.

2-2 Source Code Provision Obligation

Provide the source code files that fall under CDDL-1.0 within the binary. In doing so, observe the following.

• CDDL-1.0 requires that content added within a file also be licensed under CDDL-1.0 and have its source code disclosed. Therefore, disclose the modified files as well as the original files under CDDL-1.0.

You can fulfill the source code provision obligation by informing users in the open source notice of how they can obtain the source code.

MPL-Based License

CDDL-1.0 is a license created by Sun Microsystems (now Oracle) based on the Mozilla Public License (MPL).

• MPL similarity: Per-file Copyleft applies
• Main usage: Sun/Oracle projects (OpenSolaris, GlassFish, etc.)
• Current status: The use of CDDL is currently in decline

License Compatibility

Compatibility with Major Licenses

References

• CDDL-1.0 License Full Text
• SPDX License List - CDDL-1.0
• OSADL License Checklist

1.4.9 - CreativeML Open RAIL-M Guide

SPDX Identifier: CreativeML-OpenRAIL-M

What Is CreativeML Open RAIL-M?

CreativeML Open RAIL-M (Responsible AI License - Model) is an AI model license released in 2022 together with Stable Diffusion.

Characteristics of RAIL (Responsible AI License)

1. Open: Anyone can use it freely
2. Responsible: Restrictions for responsible use
3. Permissive: Allows commercial use, like Apache-2.0
4. Use-Based Restrictions: Restrictions based on use

Differences from General Open Source Licenses

Major Projects Using It

Stable Diffusion

• Stable Diffusion v1.x: CreativeML Open RAIL-M
• Stable Diffusion v2.x: CreativeML Open RAIL++-M (improved version)
• Stable Diffusion XL: CreativeML Open RAIL++-M

Other Image Generation Models

• Waifu Diffusion
• DreamBooth fine-tuned models

What Is Permitted

What You Can Do Freely

1. Using the model

   • Generating images
   • Generating images for commercial purposes
   • Providing API services

2. Modifying the model

   • Fine-tuning
   • Additional training
   • Model optimization

3. Distributing the model

   • Redistributing the modified model
   • Releasing derivative models
   • Integrating into commercial services

4. Using the output

   • Commercial use of generated images
   • Selling generated images
   • Creating derivative works from generated images

Prohibitions (Use-Based Restrictions)

CreativeML Open RAIL-M may not be used for the following purposes:

1. Violence and Crime

• Generating content that promotes or glorifies violence
• Assisting in planning or carrying out crimes
• Supporting terrorist activities

2. Child Exploitation

• Generating child sexual abuse material (CSAM)
• Content that sexualizes minors

3. Invasion of Personal Privacy

• Generating deepfakes without the consent of the individual
• Generating images for the purpose of identity theft
• For the purpose of spreading disinformation

4. Discrimination and Hate

• Discriminatory content regarding race, gender, religion, etc.
• Images that promote hate speech

5. Medical and Legal Advice

• For the purpose of professional medical diagnosis
• For the purpose of replacing legal advice

6. Other Harmful Uses

• Promoting suicide or self-harm
• Promoting illegal drugs
• Promoting gambling addiction

Use Scenarios

Permitted Uses

1. Generating Marketing Images

Scenario: An image generation service for advertising
Method of use: Generating product images with Stable Diffusion
Determination: Permitted (commercial use OK, not a prohibited use)

2. Generating Game Art

Scenario: Creating background images for an indie game
Method of use: Fine-tuning to generate a consistent style
Determination: Permitted

3. Educational Content

Scenario: Generating thumbnails for online lectures
Method of use: Providing an AI image generation API
Determination: Permitted

Prohibited Uses

1. Deepfake Service

Scenario: A service that generates images using another person’s face
Method of use: Compositing celebrities’ faces
Determination: Prohibited (invasion of privacy)

2. Generating Fake News

Scenario: Generating fake photos of politicians
Method of use: For the purpose of spreading disinformation
Determination: Prohibited (invasion of personal privacy, disinformation)

Requiring Review

1. Generating Social Media Profiles

Scenario: Profiles of virtual characters generated by AI
Method of use: Profile photos of non-existent people
Determination: Depends on the purpose; review the potential for misuse

Licensing of Derivative Models

An important characteristic of CreativeML Open RAIL-M is the propagation of the RAIL clauses.

When distributing a derivative model:

• The same use restrictions must be retained
• The license may be changed, but the Use-Based Restrictions are retained
• In other words, the “responsible use” clauses continue to apply

Example: When fine-tuning Stable Diffusion and distributing a custom model, the same prohibited uses apply to the custom model as well.

Copyright of AI Output

Important: Generated images are separate from the model license

• Model license: CreativeML Open RAIL-M (the model itself)
• Output: Separate copyright (owned by the user)

Generated images:

• The user owns the copyright (not the model provider)
• Can be used freely for commercial purposes
• However, the generation process must not violate the prohibited uses

References

• CreativeML Open RAIL-M Full Text
• SPDX License List - CreativeML-OpenRAIL-M
• RAIL Initiative
• Stable Diffusion License Explanation

1.4.10 - Elastic License 2.0 Guide

SPDX Identifier: Elastic-2.0

What Is Elastic License 2.0?

Elastic License 2.0 (ELv2) is the license that Elastic introduced in 2021 when it changed the license of Elasticsearch and Kibana from Apache-2.0.

Background of the License Change

Before January 2021: Apache-2.0

• AWS provided Elasticsearch as a managed service (Amazon Elasticsearch Service)
• This infringed on Elastic’s revenue model

After January 2021: Elastic License 2.0 + SSPL dual license

• Restricted AWS from providing the managed service
• Result: AWS forked it as OpenSearch

The Three Limitations

1. Prohibition on Providing a Managed Service

Prohibited: Providing the substantial functionality of the software as a service to third parties

Specific examples:

Prohibited cases:

• Providing “Elasticsearch as a Service”
• Providing “Managed Kibana”
• Providing Elasticsearch clusters to customers as a managed offering

Permitted cases:

• Using Elasticsearch as the backend of your own service
• Implementing internal search functionality
• Building a log analysis system

2. Prohibition on Use as a Core Feature of a Competing Product

Prohibited: Circumventing the software’s functionality or creating a competing product

Specific examples:

Prohibited cases:

• Circumventing the restrictions on Elasticsearch’s paid features
• Removing the license check of X-Pack features
• Developing a product that provides Elastic’s commercial features for free

Permitted cases:

• A general application that uses Elasticsearch as a search engine
• Developing log collection and analysis tools

3. Trademark Use Restriction

Prohibited: Using the Elastic trademark in a misleading way

Specific examples:

Prohibited cases:

• “Powered by Elasticsearch” (without official approval)
• “Elasticsearch Compatible” (potentially misleading)

Permitted cases:

• “Works with Elasticsearch” (a factual statement)
• “Built on Elasticsearch technology” (a clear factual statement)

References

• Elastic License 2.0 Full Text
• SPDX License List - Elastic-2.0
• Elastic License 2.0 FAQ
• Elastic vs AWS: Background of the License Change

1.4.11 - EPL-2.0 Guide

SPDX Identifier: EPL-2.0

License Statement in Source Code

Open source under the EPL-2.0 license generally carries the following statement at the top of the source code.

This program and the accompanying materials are made available under the
terms of the Eclipse Public License v. 2.0 which is available at
http://www.eclipse.org/legal/epl-2.0, or the Eclipse Distribution License
v. 1.0 which is available at
http://www.eclipse.org/org/documents/edl-v10.php.

Obligations by Use Case

Case 1. Redistribution in Source Form

When redistributing open source under the EPL-2.0 license in source form, observe the following.

1-1 Notice Obligation

• Provide a copy of the license
• Do not modify legal notices such as copyright, patent, trademark, warranty disclaimer, and indemnification notices

In other words, redistribute while keeping the license information stated in the source code intact.

Case 2. Redistribution in Binary Form

When building open source under the EPL-2.0 license and redistributing it in binary form only, observe the following.

2-1 Notice Obligation

• Provide a copy of the license
• Do not modify legal notices such as copyright, patent, trademark, warranty disclaimer, and indemnification notices

Generate an open source notice containing the above and enclose it when redistributing the binary.

2-2 Source Code Provision Obligation

Provide the source code files of the modules that fall under EPL-2.0 within the binary. In doing so, observe the following.

• EPL-2.0 requires that content added within a module also be licensed under EPL-2.0 and have its source code disclosed. Therefore, disclose the original module as well as the content added/modified within the module under EPL-2.0.

You can fulfill the source code provision obligation by informing users in the open source notice of how they can obtain the source code.

Per-Module Copyleft

The key characteristic of EPL-2.0 is that Copyleft applies on a per-module basis.

• When modifying an EPL-2.0 module: Disclose only that module under EPL-2.0
• When adding a separate module: The added module does not need to be disclosed
• When combining with another license: Combination is possible if the modules are separated

Because of these characteristics, Eclipse Foundation projects and commercial software can be developed together.

License Compatibility

Compatibility with Major Licenses

References

• EPL-2.0 License Full Text
• SPDX License List - EPL-2.0
• Eclipse Foundation FAQ
• OSADL License Checklist

1.4.12 - GPL-2.0 Guide

SPDX Identifier: GPL-2.0-only or GPL-2.0-or-later

License Text in the Source Code

Open source under the GPL-2.0 license generally includes the following text at the top of the source code.

Copyright (C) yyyy name of author
 
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
 
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
 
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.

Obligations by Use Case

Case 1. Redistribution in Source Form

When redistributing open source under the GPL-2.0 license in source form, observe the following.

1-1 Notice Obligation

• Provide a copyright notice
• Provide a warranty disclaimer
• Provide a copy of the license

That is, redistribute while keeping the copyright/license information stated in the source code intact.

Case 2. Redistribution in Binary Form

When building open source under the GPL-2.0 license and redistributing it only in binary form, observe the following.

2-1 Notice Obligation

• Provide a copyright notice
• Provide a warranty disclaimer
• Provide a copy of the license

Generate an open source notice that includes the above and include it when redistributing the binary.

2-2 Obligation to Provide Source Code

Provide the source code corresponding to the binary. In doing so, observe the following.

1. GPL-2.0 requires that derivative works also apply GPL-2.0 and disclose their source code. Referring to the content below, disclose the source code of both the GPL-2.0 open source and the derivative work.

2. Provide a build environment that allows binary users to build an identical binary from the disclosed source code. This includes the following.
   • Tool chain information
   • Build scripts
   • Build instructions (README)

Instead of the source code, you may provide a Written Offer. It must include the following statements.

1. The written offer is valid for 3 years after the product is sold.
2. It is provided to anyone.
3. No charge is made. (excluding costs incurred for delivering the source)

License Compatibility

Compatibility with Major Licenses

References

• GPL-2.0 License Full Text
• SPDX License List - GPL-2.0
• GNU GPL FAQ
• OSADL License Checklist

1.4.13 - GPL-3.0 Guide

SPDX Identifier: GPL-3.0-only or GPL-3.0-or-later

License Text in the Source Code

Open source under the GPL-3.0 license generally includes the following text at the top of the source code.

Copyright (C) <year> <name of author>
 
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
 
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
 
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>

Obligations by Use Case

Case 1. Redistribution in Source Form

When redistributing open source under the GPL-3.0 license in source form, observe the following.

1-1 Notice Obligation

• Provide a copyright notice
• Provide a warranty disclaimer
• Provide a copy of the license

That is, redistribute while keeping the copyright/license information stated in the source code intact.

Case 2. Redistribution in Binary Form

When building open source under the GPL-3.0 license and redistributing it only in binary form, observe the following.

2-1 Notice Obligation

• Provide a copyright notice
• Provide a warranty disclaimer
• Provide a copy of the license

Generate an open source notice that includes the above and include it when redistributing the binary.

2-2 Obligation to Provide Source Code

Provide the source code corresponding to the binary. In doing so, observe the following.

1. GPL-3.0 requires that derivative works also apply GPL-3.0 and disclose their source code. Referring to the content below, disclose the source code of both the GPL-3.0 open source and the derivative work.

2. Provide a build environment that allows binary users to build an identical binary from the disclosed source code. This includes the following.
   • Tool chain information
   • Build scripts
   • Build instructions (README)

Instead of the source code, you may provide a Written Offer. It must include the following statements.

1. The written offer is valid for 3 years after the product is sold.
2. It is provided to anyone.
3. No charge is made. (excluding costs incurred for delivering the source)

2-3 Obligation to Provide Installation Information

If you distribute the binary with a User Product, provide Installation Information.

• User Product: An embedded device such as an electronic appliance
• Installation Information: All the information and methods that a user needs to build the source code and reinstall it on the product

Major Improvements over GPL-2.0

GPL-3.0 retains the core principles of GPL-2.0 while improving the following.

• Explicit patent grant: Explicitly stipulates the grant of contributors’ patent licenses
• Anti-Tivoization: Adds the obligation to provide Installation Information for User Products
• Internationalization: Improves legal terminology so it can be applied worldwide

License Compatibility

Compatibility with Major Licenses

References

• GPL-3.0 License Full Text
• SPDX License List - GPL-3.0
• GNU GPL FAQ
• OSADL License Checklist

1.4.14 - LGPL-2.1 Guide

SPDX Identifier: LGPL-2.1-only or LGPL-2.1-or-later

License Text in the Source Code

Open source under the LGPL-2.1 license generally includes the following text at the top of the source code.

Copyright (C) year name of author
 
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
 
This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
 
You should have received a copy of the GNU Lesser General Public
License along with this library; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA

Obligations by Use Case

Case 1. Redistribution in Source Form

When redistributing open source under the LGPL-2.1 license in source form, observe the following.

1-1 Notice Obligation

• Provide a copyright notice
• Provide a warranty disclaimer
• Provide a copy of the license

That is, redistribute while keeping the copyright/license information stated in the source code intact.

Case 2. Redistribution in Binary (Library) Form

When building open source under the LGPL-2.1 license and redistributing it only in binary form, observe the following.

2-1 Notice Obligation

• Provide a copyright notice
• Provide a warranty disclaimer
• Provide a copy of the license

Generate an open source notice that includes the above and include it when redistributing the library.

2-2 Obligation to Provide Source Code

Provide the source code corresponding to the binary (library). In doing so, observe the following.

1. LGPL-2.1 requires that derivative works also apply LGPL-2.1 and disclose their source code. Referring to the content below, disclose the source code of both the LGPL-2.1 open source and the derivative work.

2. Provide a build environment that allows users to build an identical library from the disclosed source code of the LGPL library. This includes the following.

   • Tool chain information
   • Build scripts
   • Build instructions (README)

3. When distributing an Executable created by Static Linking the LGPL library, provide the object code that makes up the executable so that users can modify the LGPL library and regenerate the executable. (#LGPLStaticVsDynamic)

Instead of the source code, you may provide a Written Offer. It must include the following statements.

1. The written offer is valid for 3 years after the product is sold.
2. It is provided to anyone.
3. No charge is made. (excluding costs incurred for delivering the source)

Dynamic Linking vs Static Linking

The key point of LGPL-2.1 is that the scope of source code disclosure differs depending on the linking method.

• Dynamic Link: Only the LGPL library is disclosed; the application code does not need to be disclosed
• Static Link: The LGPL library + object code must be provided

For commercial software development, the use of dynamic linking is recommended.

License Compatibility

Compatibility with Major Licenses

References

• LGPL-2.1 License Full Text
• SPDX License List - LGPL-2.1
• GNU LGPL FAQ
• OSADL License Checklist

1.4.15 - LGPL-3.0 Guide

SPDX Identifier: LGPL-3.0-only or LGPL-3.0-or-later

License Text in the Source Code

Open source under the LGPL-3.0 license generally includes the following text at the top of the source code.

Copyright (C) <year> <name of author>
 
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU Lesser General Public License as
published by the Free Software Foundation, either version 3 of the
License, or (at your option) any later version.
 
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU Lesser General Public License for more details.
 
You should have received a copy of the GNU Lesser General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.

Obligations by Use Case

Case 1. Redistribution in Source Form

When redistributing open source under the LGPL-3.0 license in source form, observe the following.

1-1 Notice Obligation

• Provide a copyright notice
• Provide a warranty disclaimer
• Provide a copy of the license

That is, redistribute while keeping the copyright/license information stated in the source code intact.

Case 2. Redistribution in Binary (Library) Form

When building open source under the LGPL-3.0 license and redistributing it only in binary form, observe the following.

2-1 Notice Obligation

• Provide a copyright notice
• Provide a warranty disclaimer
• Provide a copy of the license

Generate an open source notice that includes the above and include it when redistributing the library.

2-2 Obligation to Provide Source Code

Provide the source code corresponding to the binary (library). In doing so, observe the following.

1. LGPL-3.0 requires that derivative works also apply LGPL-3.0 and disclose their source code. Referring to the content below, disclose the source code of both the LGPL-3.0 open source and the derivative work.

2. Provide a build environment that allows users to build an identical library from the disclosed source code of the LGPL library. This includes the following.

   • Tool chain information
   • Build scripts
   • Build instructions (README)

3. When distributing an Executable created by Static Linking the LGPL library, provide the object code that makes up the executable so that users can modify the LGPL library and regenerate the executable. (#LGPLStaticVsDynamic)

Instead of the source code, you may provide a Written Offer. It must include the following statements.

1. The written offer is valid for 3 years after the product is sold.
2. It is provided to anyone.
3. No charge is made. (excluding costs incurred for delivering the source)

2-3 Obligation to Provide Installation Information

If you distribute the library with a User Product, provide Installation Information.

• User Product: An embedded device such as an electronic appliance
• Installation Information: All the information and methods that a user needs to build the source code and reinstall it on the product

Major Improvements over LGPL-2.1

LGPL-3.0 retains the core principles of LGPL-2.1 while improving the following.

• Explicit patent grant: Explicitly stipulates the grant of contributors’ patent licenses
• Apache-2.0 compatibility: Resolves the compatibility issue with Apache-2.0
• Anti-Tivoization: Adds the obligation to provide Installation Information for User Products

License Compatibility

Compatibility with Major Licenses

References

• LGPL-3.0 License Full Text
• SPDX License List - LGPL-3.0
• GNU LGPL FAQ
• OSADL License Checklist

1.4.16 - Llama 2 Community License Guide

SPDX Identifier: Llama-2 (unofficial)

What Is the Llama 2 Community License?

The Llama 2 Community License is a proprietary license that Meta released in 2023 together with the Llama 2 language model.

Llama Model Lineage

Why a “Community License”?

Meta describes this license as follows:

• Encouraging community innovation: Most developers and companies can use it freely
• Checking large corporations: Restricting exclusive use by Big Tech
• Responsible AI: Preventing harmful use

700 Million Scale Restriction

Definition of MAU (Monthly Active Users)

Monthly active users: the number of unique users who used the product/service in the previous calendar month

Examples:

Scenario 1: T phone app (MAU 5 million)
Since the MAU is fewer than 700 million, it can be used freely.

Scenario 2: Facebook (MAU 3 billion)
Since the MAU is 700 million or more, a separate license must be requested from Meta.

Services Exceeding the 700 Million Threshold

Services with 700 million or more MAU worldwide:

• Facebook, Instagram, WhatsApp (Meta)
• YouTube (Google)
• TikTok
• WeChat

Most companies are not affected

When the Scale Restriction Applies

It applies continuously from the time of license agreement and after use begins.

Important: What happens if you start below 700 million but later exceed it? At the point of exceeding it, you must notify Meta and negotiate a separate license.

Permitted Items (MAU Fewer Than 700 Million)

What You Can Do Freely

1. Commercial use

   • Providing paid services
   • Selling APIs
   • Integrating into products

2. Model modification

   • Fine-tuning
   • Quantization (4-bit, 8-bit)
   • Model merging

3. Model distribution

   • Releasing derivative models
   • Uploading to Hugging Face, etc.
   • Including in open source projects

4. Use of generated outputs

   • Commercial use of AI-generated text

Prohibited Items (Acceptable Use Policy)

Llama 2 cannot be used for the following purposes:

1. Illegal Activities

• Supporting criminal acts
• Trading illegal goods
• Terrorist activities

2. Child Protection

• Child abuse content
• Child grooming

3. Discrimination and Hate

• Generating discriminatory content
• Hate speech
• Harassment

4. Violence and Danger

• Inciting violence
• Encouraging self-harm or suicide
• Weapons manufacturing

5. Privacy Violations

• Unauthorized collection of personal information
• Stalking, surveillance

6. Disinformation

• Intentional fake news
• Fraudulent content

7. High-Risk Domains (Sole Decision-Making)

• Medical diagnosis
• Legal advice
• Financial advice
• Emergency services

Prohibition on Training Competing LLMs with Llama 2

As a distinctive clause, you cannot use Llama 2 to train an LLM that competes with Meta.

Prohibited examples:

• Training a new LLM with the outputs of Llama 2
• Distillation using Llama 2 as a teacher model

Permitted examples:

• Fine-tuning Llama 2 itself
• Using the outputs of Llama 2 as a dataset (for a specific task)

Use Scenarios

Permitted Uses

1. Customer Service Chatbot

Scenario: A telecom customer consultation chatbot
MAU: 10 million
Judgment: Allowed (fewer than 700 million)

2. B2B AI Solution

Scenario: An enterprise document summarization solution
MAU: 100 thousand
Judgment: Allowed

3. Mobile App AI Feature

Scenario: A photo caption generation app
MAU: 5 million
Judgment: Allowed

Restricted Uses

1. Large-Scale Social Media

Scenario: Integration into social media with 1 billion MAU
Judgment: A Meta license is required

2. Training a Competing LLM

Scenario: Training a new LLM with Llama 2 outputs
Judgment: Prohibited

Requires Review

1. Global Service Expansion

Scenario: Currently 50 million MAU, with a future target of 1 billion
Judgment: Consultation with Meta is required before reaching 700 million

Licensing of Derivative Models

Mandatory Requirements

1. Attribution

   • Indicate “Based on Llama 2”
   • State it in the model card

2. License propagation

   • Apply the same Acceptable Use Policy
   • Maintain the 700 million scale restriction

3. Restriction on Meta trademark use

   • Unauthorized use of the “Llama” trademark is prohibited
   • The expression “Built with Llama 2” is OK

Derivative Model Examples

Permitted names:

• “MyModel (based on Llama 2)”
• “CustomLLM-Llama2-7B”

Prohibited names:

• “Llama 2 Pro”
• “Meta Llama Custom”

Llama 3 Update

Llama 3, released in April 2024, uses an updated license:

• Similar basic structure
• Some improvements to the use restriction clauses
• The 700 million scale restriction is maintained

The same guide applies when using Llama 3.

References

• Llama 2 Community License Full Text
• Llama 2 Acceptable Use Policy
• Llama 2 Model Card
• Meta AI Official Blog

1.4.17 - MIT Guide

SPDX Identifier: MIT

License Text in the Source Code

Open source under the MIT license generally includes the following text at the top of the source code.

Copyright (c) <year> <copyright holders>
 
Permission is hereby granted, free of charge, to any person
obtaining a copy of this software and associated documentation
files (the "Software"), to deal in the Software without
restriction, including without limitation the rights to use,
copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the
Software is furnished to do so, subject to the following
conditions:
 
The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.
 
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
OTHER DEALINGS IN THE SOFTWARE.

Obligations by Use Case

Case 1. Redistribution in Source Form

When redistributing open source under the MIT license in source form, observe the following.

1-1 Notice Obligation

• Copyright notice
• Provide a copy of the license

That is, keep the copyright, license, and so on within the source code intact.

Case 2. Redistribution in Binary Form

When building open source under the MIT license and redistributing it only in binary form, observe the following.

2-1 Notice Obligation

• Copyright notice
• Provide a copy of the license

Generate an open source notice that includes these items and include it when redistributing the binary.

License Compatibility

The MIT license is compatible with most other licenses.

Compatibility with Major Licenses

References

• MIT License Full Text
• SPDX License List - MIT
• OSADL License Checklist

1.4.18 - MPL-2.0 Guide

SPDX Identifier: MPL-2.0

License Text in the Source Code

Open source under the MPL-2.0 license generally includes the following text at the top of the source code.

This Source Code Form is subject to the terms of the Mozilla Public
License, v.2.0. If a copy of the MPL was not distributed with this file,
You can obtain one at https://mozilla.org/MPL/2.0/.

Obligations by Use Case

Case 1. Redistribution in Source Form

When redistributing open source under the MPL-2.0 license in source form, observe the following.

1-1 Notice Obligation

• Provide or reference a copy of the license
• Do not modify legal notices

That is, redistribute while keeping the license information stated in the source code intact.

Case 2. Redistribution in Binary Form

When building open source under the MPL-2.0 license and redistributing it only in binary form, observe the following.

2-1 Notice Obligation

• Provide a copy of the license

Generate an open source notice that includes the above and include it when redistributing the binary.

2-2 Obligation to Provide Source Code

Provide the source code files under MPL-2.0 within the binary. In doing so, observe the following.

• MPL-2.0 requires that content added within a file also apply MPL-2.0 and disclose its source code. Therefore, disclose both the original file and the modified file by applying MPL-2.0.

You can fulfill the obligation to provide source code by indicating in the open source notice how users can obtain the source code.

Per-File Copyleft

The key characteristic of MPL-2.0 is that Copyleft is applied on a per-file basis.

• When modifying an MPL-2.0 file: Disclose only that file under MPL-2.0
• When adding a separate file: The added file does not need to be disclosed
• When combining with other licenses: Combination is possible if the files are separated

Because of these characteristics, it can be used flexibly in commercial software development.

License Compatibility

Compatibility with Major Licenses

References

• MPL-2.0 License Full Text
• SPDX License List - MPL-2.0
• Mozilla MPL FAQ
• OSADL License Checklist

1.4.19 - SSPL Guide

SPDX Identifier: SSPL-1.0

What Is SSPL?

SSPL (Server Side Public License) is a license that MongoDB created in 2018 to prevent cloud providers such as AWS from offering MongoDB as a commercial service.

Differences from AGPL-3.0

SSPL modifies AGPL-3.0 Section 13 to require, when providing a service, the disclosure of all of the following:

• The SSPL software itself
• All software that interacts with the service
• The management software needed to operate the service
• Infrastructure provisioning, monitoring, backup tools, etc.

Major Use Cases

MongoDB’s License Change

• Before October 2018: AGPL-3.0
• After October 2018: SSPL-1.0

Other Projects Adopting SSPL

• Graylog
• Some NoSQL databases

Why Did the OSI Not Approve It?

In 2019, the OSI decided not to recognize SSPL as open source:

1. Overly broad disclosure requirement: The scope of “everything needed to operate the service” is unclear
2. Violation of non-discrimination: It effectively prohibits a specific business model (SaaS)
3. Restriction on free use: Providing a commercial cloud service is practically impossible

Reasons for the Usage Restriction

If you provide a service using SSPL software, you must disclose all of the following:

1. The source code of the SSPL software
2. The service application code
3. Kubernetes configurations
4. Terraform scripts
5. Monitoring tools (Prometheus, Grafana, etc.)
6. CI/CD pipelines
7. Backup and recovery systems

Since this would require disclosing all of SK Telecom’s core infrastructure information, its use is not possible.

Alternatives

If you need to use SSPL software, please consider the following alternatives.

MongoDB

• MongoDB Community Edition: SSPL
• Alternative 1: MongoDB Atlas (MongoDB’s official cloud service)
• Alternative 2: PostgreSQL + JSON features
• Alternative 3: FerretDB (a MongoDB-compatible AGPL project)

Graylog

• Graylog Open Source: SSPL
• Alternative 1: Elasticsearch + Kibana (Elastic License 2.0, separate review required)
• Alternative 2: Grafana Loki (AGPL-3.0)

References

• SSPL License Full Text
• SPDX License List - SSPL-1.0
• OSI’s Decision to Reject SSPL
• MongoDB License Change Announcement

2 - Contributing to Open Source

SK Telecom actively encourages its members to contribute to external open source projects, for example by submitting patches. If you find a bug or improve some code, contribute it back to the open source project. Doing so benefits not only individuals but the company as well.

• Benefits of Open Source Contribution

That said, there are a few things to keep in mind. Although it is not common, jumping in without an understanding of, and a strategy for, the open source project and its community can lead to disappointment. In particular, it can not only damage the company’s reputation within the community but also create legal risk. This guide was written to help prevent such legal issues and to enable effective collaboration with the open source community. It explains several requirements that SK Telecom members must follow before contributing to an open source project, along with the right way to contribute.

Useful Knowledge for Open Source Contribution

First, here is some information that may help with open source contribution. (If you are already familiar with general open source contribution, feel free to skip this section.)

• Types of Open Source Contribution
• Open Source Project Membership
• Key Documents in an Open Source Project
• How to Become a Good Contributor
• How to Identify a Good Project to Contribute To
• How to Communicate

SK Telecom Open Source Contribution Rules

SK Telecom respects the value of collaborating with the open source community and, to that end, encourages its members to contribute to external open source projects. However, there are several rules that must be followed to protect SK Telecom’s intellectual property and to prevent unintentional copyright infringement.

• Open Source Contribution Rules

SK Telecom Open Source Contribution Process

In accordance with SK Telecom’s open source contribution rules, members follow the contribution process below when contributing to external open source projects.

• Open Source Contribution Process

2.1 - Benefits of Open Source Contribution

Today, any company that develops software naturally uses open source. And many companies do not stop at using open source; they also contribute back to the open source community. Why do they choose to contribute back to open source? Companies that encourage contribution to open source projects do so because they expect the following effects.

Why Should a Company Contribute to Open Source?

What are the purposes and benefits for a company contributing to open source? Why should a company encourage its members to contribute to open source? From a business perspective as well, the reasons a company should contribute to open source are as follows.

1. It Can Reduce Maintenance Costs.

A company uses open source to build products, fixing bugs and adding new features along the way. But what happens if it does not contribute these back to the open source project?

The open source project will keep releasing new versions, including important security patches. Each time, before applying a new version, the company must reapply its own modifications to the new version and then test every time whether the features work without problems and whether there is any impact on performance. If this effort is repeated, the management cost, including the personnel and time required, increases significantly. If the modifications had been contributed to the open source project, they would already be included when a new version is released, so there would be no need for additional maintenance.

Therefore, companies that use open source must educate their developers on the importance of contribution. Of course, contributing to an open source project can take considerable effort and time. Because of tight development schedules, developers may want to apply a patch only to the product right away and not contribute it to the open source project. However, it must be repeatedly emphasized that if the patch is not contributed, the developer will have to reapply their own patch every time a new version is released. The more this work is repeated, the more it becomes a vicious cycle of pouring in more time and effort.

2. It Can Influence the Direction of the Open Source Project.

Do you want an open source project that is important to your product development to add a feature that your company needs? If so, we recommend being active: propose the desired feature to that open source project and, in some cases, directly develop and contribute part of it. After the company contributes in this way, the participation of many people stabilizes and advances the feature, and as a result the project grows in the direction the company wants.

3. It Can Help Recruit Excellent Developers.

The best place to find excellent open source developers is the open source community itself. A company that actively contributes to open source builds a good reputation in the open source community. Excellent developers in the open source community know which companies actively contribute to open source, and they want to work at such companies. It is not easy for a company that does no open source contribution at all to recruit excellent open source developers.

Why Should a Developer Contribute to Open Source?

1. You Can Contribute to the Public Good

When you directly fix a bug or add a new feature to open source you are using, the software is improved and, moreover, everyone who uses the software benefits. With a small contribution, you contribute to the global community.

2. You Can Build Your Skills

Through contributing to open source, you can learn new technologies. Beyond that, you can improve your capabilities through repeated practice and training. Version control, unit testing, integration testing, CI/CD, and the like were born out of open source project development and are now used in almost all software development. You can learn these in open source projects. Furthermore, unlike company work, open source projects are relatively tolerant of beginners’ mistakes, so as long as your will is firm, they are the best space to build your technical capabilities. In open source projects, you can learn not only coding but also practical skills such as UI, graphic design, and writing documentation.

3. You Can Understand Open Source at a Deeper Level and Acquire the Technology

When you go beyond simply using open source and, for the sake of contribution, understand issues and solve problems, you acquire open source technology at a deeper level. Such activity makes it easy to identify and flexibly respond to future changes in the open source, and it can also help you expand your use of open source.

4. You Can Learn Collaboration

The open source community is a space where people from various regions and different time zones around the world come together. Under such constraints, a high level of collaboration ability is needed to carry out a common task. In open source projects, true collaboration that takes into account division of labor and risk management takes place. In addition, you can become familiar with the various tools that support collaboration. Issue trackers, version control systems, and mailing lists are representative examples.

5. You Can Meet New People

Open source has community. People with common interests participate and meet, and through this they can build relationships. Whom you meet can have a major impact on the direction of your career. Once you have a trusting relationship, you can lead each other to new work or jobs. This is possible because in the open source community you always collaborate professionally and can deeply understand each other’s work styles and personalities. The relationships formed while contributing to open source projects are one clear answer to why you should contribute.

6. You Can Build Your Reputation and Career

Open source work is open to everyone. Work done in open source can be shown to anyone, anywhere, which greatly helps raise an individual’s reputation.

7. You Can Learn Leadership

In open source, you can learn leadership and management skills such as team building, conflict resolution, and priority adjustment. To collaborate on an open source project, you have to explain to someone how to do a task, and there are times when you have to ask others for help. Through this process of learning and teaching, you experience leadership and taste a sense of achievement.

2.2 - SK Telecom Open Source Contribution Rules

SK Telecom respects the value of collaborating with the open source community and, to that end, encourages its members to contribute to external open source projects. However, there are several rules that must be followed to protect SK Telecom’s intellectual property and to prevent unintentional copyright infringement.

Obtain Approval

From a copyright perspective, open source contribution grants the open source project the right to modify, use, and distribute the author’s work. In some cases, you may even have to assign your copyright to the open source project. Generally, however, the copyright of works created during employment is owned by the employer. That is, works created by SK Telecom members are owned by SK Telecom. A member contributing a work to open source at their own discretion can create unnecessary copyright infringement issues.

Therefore, if there is an open source project you want to contribute to, follow the review request and approval process before your first contribution, in accordance with SK Telecom’s open source contribution policy.

• Open Source Contribution Process

Contribute Only Code You Have the Right to Contribute

Contribute only code you have the right to contribute. That is, contribute code you wrote yourself. You must not contribute third-party code at your own discretion.

Be Careful About Disclosing Intellectual Property

Do not contribute code or documents where there is a concern about disclosing the company’s intellectual property, such as sensitive information or patents.

If the code you want to contribute contains a company patent, confirm whether it is permissible to contribute this patent to the project under an open source license. If anything is unclear, contact the OSPO.

Do Not Contribute Substandard Code

Do not contribute substandard code. This can affect the company’s reputation.

Be Careful When Signing a CLA

Some open source projects require all contributors to sign a CLA (Contributor License Agreement). This is an agreement that seeks contributors’ consent in order to reduce copyright disputes that may arise as the project manages works from many contributors. Projects led by large companies typically require signing a CLA.

CLAs differ from project to project, but they mainly contain agreement to the following.

- I (or my company) have the right to contribute the contribution I am about to contribute to the project. (That is, I am the author of this contribution.)
- I (or my company) grant the project the authority to modify, distribute, and manage my contribution.
- I (or my company) will not revoke the authority I have granted.
- I (or my company) grant the project the authority to change the license in the future as needed.

In addition, although it is rare, some CLAs require agreement to the following condition.

- I (or my company), upon contributing my contribution, assign my copyright to the project or the project's managing organization.

To protect its intellectual property, SK Telecom does not permit contributions to open source projects that require copyright assignment. To make this determination, if an open source project you want to contribute to requires signing a CLA, you must request an OSPO review before signing: Open Source Contribution Process.

Most CLAs are not problematic to sign, so the approval process does not take long.

Indicate Copyright

The intellectual property of works created by a member during their employment is, by default, owned by the company. Therefore, when contributing code to an external open source project, members must indicate SK Telecom’s copyright.

When contributing one or more files, indicate the copyright and license at the top of the file as follows.

Copyright 2021 SK TELECOM CO., LTD.
SPDX-License-Identifier: {$SPDX_license_name}

• Here, $SPDX_license_name is written according to the license policy of the relevant open source project.
• However, if you are merely modifying existing code for purposes such as bug fixes, there is no need to indicate copyright for that code modification.
• For detailed copyright and license notation rules, refer to the following page: Copyright and License Notice Within Files

Use Your Company Email

When contributing to open source projects, do not use your personal email; use your SK Telecom email. Through this, (1) members gain a sense of responsibility that they are communicating with the community on behalf of the company, and (2) SK Telecom can improve its recognition as a company that actively contributes to the open source community.

• For how to set up your email on GitHub, refer to the following Link.

2.3 - SK Telecom Open Source Contribution Process

In accordance with SK Telecom’s open source contribution rules, members follow the contribution process below when contributing to external open source projects.

1. Internal Approval Within Your Organization

Before starting to contribute to an open source project, obtain approval from the responsible executive or leader of your organization.

2. Request an OSPO Review

After obtaining approval within your organization, request a review from the OSPO_{Open Source Program Office}: Support (opensource@sktelecom.com)

• When requesting a review, include the following: [Template]
  • Open source project name
  • Repository
  • License
  • Purpose of contribution
  • Details of contribution
• The OSPO reviews the open source project’s License / CLA and approves it if there are no issues.
• The OSPO compiles the status of open source projects to which SK Telecom members are contributing. The compiled data is used as an expert pool for each open source project.

3. Review the Project’s Contribution Documents

The required process differs slightly from one open source project to another.

• Each project has various guidelines on coding style, language, formatting, bug/ticket management, release timing, and so on.
• Some projects require signing a CLA, while others require a DCO Signed-off-by.
• As for how patches are accepted, most projects now use GitHub Pull Requests, but some still use a mailing list.

For this reason, to properly understand the process of the project you want to contribute to, you must first carefully review the documents the project provides. Most projects provide these documents as a CONTRIBUTING or README file. For example, Kubernetes provides a detailed guide for contributors. (contributing.md: a guide for contributing to Kubernetes) The better you comply with the requirements in the documents, the more likely your contribution is to be accepted.

4. Comply with the Open Source Contribution Rules

Review the SK Telecom Open Source Contribution Rules and improve the code you will contribute accordingly.

5. Submit Your Contribution

Now submit your contribution according to the process required by the project’s documentation. For how to contribute to a typical open source project, refer to the following pages.

• Detailed Contribution Submission Process
• How to Communicate

2.3.1 - Detailed Contribution Submission Process

Now let’s look at how to submit a contribution. The methods and steps for submitting a contribution to a typical open source project are as follows.

1. Check Prior History

Check whether the contribution you are about to submit has been addressed before. Look through the project’s README, issues, and mailing list. You don’t need to check every document; searching for a few keywords makes it easy to verify.

If you cannot find related content in prior materials, it is time to open an issue or start communicating through a Pull Request. GitHub provides Issues and Pull Request features.

• Issues: You can start a conversation or discussion.
• Pull Request: You contribute a solution to a problem.

Before opening an Issue or Pull Request, check the documents the project provides (typically CONTRIBUTING or README) to confirm the contribution process and method. For example, they may require following a specific template or require pre-testing.

Before starting work on a contribution, it is also a good idea to open an Issue first to let community members know what you intend to work on. In some cases, this can help you avoid doing unnecessary work.

2. Create an Issue

Generally, create an Issue in the following situations.

• Reporting an error you cannot resolve on your own
• Proposing a new feature or idea
• Discussing the community vision or policy

3. Create a Pull Request

Once all the files for your contribution are ready, submit your contribution as a Pull Request.

When to Create a Pull Request

Generally, create a Pull Request in the following situations.

• Submitting minor fixes (e.g., typos, broken links, etc.)
• Starting work on something already discussed in an Issue

A Pull Request does not have to be made only after the work is complete. Generally, it is good to open a Pull Request early to get feedback from others. Mark “WIP” (Work in Progress) in the title line to indicate that it is still in progress, and you can add more commits at any time later.

The Pull Request Process on GitHub

If the project is on GitHub, you can refer to the following when submitting a Pull Request.

Step 1. Fork

Fork the upstream repository to your own GitHub account.

Step 2. Clone

Clone the forked repository to your own local working directory.

$ mkdir -p $working_dir
$ cd $working_dir
$ git clone https://github.com/$user/[repository]

Add the upstream repository as a remote.

$ cd [repository]
$ git remote add upstream https://github.com/[upstream]/[repository]
 
# Confirm that your remotes make sense:
$ git remote -v

Step 3. Create a branch

First, fetch and rebase the main branch to keep it up to date.

$ cd $working_dir/[repository]
$ git fetch upstream
$ git checkout main
$ git rebase upstream/main

Then create a development branch (myfeature).

$ git checkout -b myfeature

Step 4. Keep your branch in sync

Fetch and rebase the branch to keep it up to date.

# While on your myfeature branch
$ git fetch upstream
$ git rebase upstream/main

Then do your code work in that state.

Step 5. Commit

Commit your changes.

$ git commit -a -m '[commit message]'

Step 6. Push

Push the changes on the myfeature branch to your own GitHub repository.

git push -f origin myfeature

Step 7. Create a pull request

When you go to your repository on GitHub, you will see that the Compare & pull request button is enabled. Click it to create a Pull Request.

After that, the maintainer of the upstream repository reviews the requested Pull Request and decides whether to merge it.

4. Receive Feedback

Once you submit your contribution, you will receive feedback from the project. Feedback generally asks for an explanation of how the improvement or change works and why you adopted that approach. This feedback can sometimes be difficult to respond to, but it is best to accept it as a process that raises the level of your contribution.

Feedback usually falls into one of the following four categories.

(1) No Response?

Before contributing, it is good to first check whether the project is active. Even in a fairly active project, you may not receive a response to your contribution.

If you have not received a response for more than a week, it is good to politely ask someone in the same thread to review it. If you know the name of the appropriate person, use the @-mention feature.

Even so, for various reasons, no one may respond. It is not a great feeling, but there is no need to be discouraged. This can happen to anyone. Look for another way to contribute or another project.

(2) A Request for Changes?

It is common to be asked to explain your idea or to revise your code. If someone requests changes like this, respond promptly. They took their own time to review your contribution.

Leaving a PR open without responding is impolite. If you are no longer in a position to solve the problem, let the Maintainer know that you cannot proceed further. Then they can close the PR or someone else can take it over and continue.

(3) Rejected?

Your contribution may ultimately be accepted, or it may not. If you do not clearly understand the reason it was not accepted, it is reasonable to ask the Maintainer for an explanation. However, you must respect that this is their decision. Do not argue or act with hostility. If differences are never reconciled, you can always fork and work on your own project.

(4) Accepted!

Congratulations! You have finally succeeded in contributing to open source.

2.4 - Background on Open Source Contribution

2.4.1 - Types of Open Source Contribution

In open source projects, software developers mainly contribute by modifying source code to fix bugs or improve features. However, developers are not the only ones who can contribute to open source projects. Open source projects need various types of contributions, such as documentation and design, as described below.

Writing Documentation / Translation

• Write project documentation and tutorials. (e.g., PyPA’s contributors did)
• Write the project’s newsletter or summarize key points from the mailing list.
• Translate the project’s documentation into your own language.

Testing / Creating Issues

• Test whether the software works correctly.
• Test whether it builds / installs as described in the documentation.
• Check whether the documentation and API are written consistently.

Design

• Improve the layout, menus, and so on of the project’s website. (e.g., Drupal suggest)
• Create a style guide so the project can have a consistent design.
• Contribute to creating a new logo or T-shirt. (e.g., hapi.js’s contributors did)

Writing / Reviewing Code

• Find an open issue you can resolve. (e.g., @dianjin did for Leaflet)
• Add new features.
• Improve tools and testing for automation.
• Review code submitted by others.
• Become a mentor to other contributors. (e.g., @ereichert did for @bronzdoc on Rust)

Marketing

• Promote the project’s purpose and usefulness in various ways, such as on social media and through seminar presentations.

Events

• Plan and host various gatherings such as the project’s conferences, workshops, and meetups. (e.g., fzamperin did for NodeSchool)

2.4.2 - Open Source Project Membership

How can an open source project continue to develop high-quality software through collaborative work? How can many people who do not know each other write code together and produce stable software? Open source projects achieve this through clearly defined roles.

Leader

Every project has a leader, and the founder usually takes on this role. The leader determines the direction of the project and is responsible for the final decision when a decision is needed. The leader may be an individual, but for large projects, a Steering Committee is organized to perform the leader’s role.

• For example, Linus Torvalds, as the original author of the Linux Kernel, has the final say on every matter of its progress.
• In the case of the Node.js project, the Technical Steering Committee performs the leader’s role.

Maintainer

Maintainers are core contributors who possess the most trusted technical capabilities in the project. They are delegated specific areas by the leader and take on the role of managing them proactively.

Committer

Committers are those who sufficiently understand the code of specific modules in the project and contribute regularly. They have the authority to review and approve contributors’ contributions, and for certain modules they can merge without the maintainer’s approval.

Contributor

Anyone who has contributed, even in a small way, is a contributor. Contributors contribute to open source projects through methods such as simple bug fixes and documentation. Such contributions are reviewed and supplemented by experienced committers and maintainers, and then merged into the repository.

User

Users play the role that determines the success or failure of an open source project. No matter how well prepared a project is, it cannot succeed if no one uses it. By using the project and providing ideas such as bug reports and new feature suggestions, users give the project its reason for existing.

• If a project’s leader and contributors do not carefully listen to users’ requests, it is difficult for the project to grow healthily over the long term.
• A project can only be sustained if it grows in a direction that meets users’ needs.

2.4.3 - Key Documents in an Open Source Project

To contribute properly, it is important to understand how each open source project works and to act as the project expects. Most open source projects communicate these requirements through documents such as the README and CONTRIBUTING. Open source projects commonly include several such documents, usually located at the top level of the repository. Before contributing, you should use these documents to familiarize yourself with the project’s culture, code of conduct, and contribution methods.

README

The README is the file you see when you first approach a project. It introduces the project, explains why you should use it, how to use it, and more. It is a must-read document for understanding what the project is.

LICENSE (or COPYING)

The LICENSE is the file containing the open source license, which states that anyone may use the project. Every open source project must have an open source license. Without an open source license, it is not open source. In that case, the source code has been disclosed, but the right to use or distribute it has not been granted. Be aware that including such source code in a product or service carries the risk of copyright infringement.

CONTRIBUTING

If the README is a document for people who use the project, CONTRIBUTING is a document for people who contribute to the project. Because it explains what types of contributions are needed and how to contribute, you should examine this document carefully when you want to contribute to open source. Contributors must follow the contribution methods described in this document.

If the project you want to contribute to has no CONTRIBUTING file, ask the community how to contribute. If you do not receive an appropriate response, you may regard it as a project not worth contributing to and look for another project.

CODE OF CONDUCT

The CODE OF CONDUCT, also called a code of conduct or behavioral guidelines, defines the rules of conduct for participants so that the project stays healthy. For example, it emphasizes that there must be no discrimination based on gender, race, religion, age, and so on, that everyone is warmly welcomed, and that participants must act to ensure safe activity. It also explains how to report someone who breaks those rules.

Other Documents

(For large open source projects) documents such as tutorials and governance policies may also be provided.

2.4.4 - How to Become a Good Contributor

Before getting into how to submit contributions in earnest, let’s briefly look at how to become a good contributor. Of course, since every project operates differently, there is no single right answer. Each time you join a new project, you need to invest time in learning how it operates. Even so, the following points are commonly helpful in becoming a good contributor.

1. Join the Community

Open source projects have a community of users and developers. Each community participates in slightly different ways. Read the documentation the community provides, and join its main communication channels such as the mailing list, forums, IRC, Slack, and bug tracker.

2. Observe for a While

After joining the community, take some time to get familiar with its culture before contributing. Reviewing past communications is a good approach. The more you go through this process, the more likely your first contribution is to be accepted.

3. Understand the Governance

Before contributing, use the project’s management and governance documents to understand how the project is governed. You can learn who makes decisions and how.

4. Start Small

Start with a simple bug fix or documentation change. It is good to learn the process and correct mistakes by making small, low-stakes contributions. Building on this experience, you can contribute more substantially and gradually have an impact on the project.

5. Attend Events

Building lasting relationships with other participants in the open source community is important. The best way to do this is to attend events such as conferences. Nothing builds relationships like meeting in person.

6. Contribute from the Early Stages of the Code

Some people finish developing until the amount of code becomes quite large and then try to contribute it all at once. Such contributions are not easily accepted by open source projects. It is difficult for a project to review a large amount of code at once, and the contributed code may differ from the direction the project wants. Discuss with the community starting from the idea stage, and contribute early in development and often.

2.4.5 - How to Identify a Good Project to Contribute To

Naturally, you should contribute to open source projects that are related to your work or in an area of technical interest. If there are several such projects, it is also worth considering which one is worth contributing to. Otherwise, your hard-earned contribution may be buried without any response.

The following is a checklist for determining whether an open source project you are interested in is suitable for contribution activity.

1. Is There an Open Source License File?

• Is there a LICENSE file? Typically, there is a file named LICENSE in the root directory of the repository.

A project to which no open source license applies is not open source. Only when the software’s copyright holder grants, through an open source license, the right for anyone to use and distribute it can a company use that software freely. Using software without an open source license at will can create legal risks such as copyright infringement.

2. Is the Project Actively Receiving Contributions?

• When was the most recent commit?
• How many contributors are there?
• How frequent are the commits?

If there are few contributors or there have been no commits for several years, the project can be considered unmaintained.

On GitHub, you can check the commit status under “Commits” at the top of the screen.

3. Check the Project’s Issues

• How many issues are open?
• When an issue is opened, do maintainers respond quickly?
• Is there active discussion on the issues?
• Are the issues recent?
• Are issues being closed?

If issues are not being opened, or if they are opened but not responded to, the project can be considered unmaintained.

On GitHub, you can check the status of closed issues by looking at the “closed” tab on the Issues page.

4. Check the Project’s Pull Requests

• How many Pull Requests are open?
• When a Pull Request is opened, do maintainers respond quickly?
• Is there active discussion on the Pull Requests?
• Are the Pull Requests recent?
• How recently have Pull Requests been merged?

On GitHub, you can see closed Pull Requests by clicking the “closed” tab on the Pull Request page.

5. Does the Project Have a Welcoming Atmosphere for Contributions?

• Do maintainers give helpful answers to questions about issues?
• Are people friendly in issues, forums, and chat (such as Slack)?
• When you submit a Pull Request, does a review take place?
• Do maintainers show appreciation for people’s contributions?

A project that does not have a welcoming atmosphere for contributions is unlikely to develop well over the long term. This can also be a criterion for judging whether a project is worth contributing to.

2.4.6 - How to Communicate

Every part of the open source contribution process is a continuous series of communications with community members. First, keep the following points in mind for effective communication.

Communicate Your Intent Precisely

If you are reporting an error, explain precisely what task it occurred during and how to reproduce it. If you are proposing a new idea, explain why you think it would be useful to the project.

Do Not Just Ask; First Try What You Can Do Yourself

Before asking for help, look for the answer in the project’s documentation such as the README, in issues, in the mailing list, or through a search. It is good to show this kind of effort.

Keep Conversations as Concise as Possible

Every contribution you submit has to be reviewed by someone. Some projects accumulate so many contributions and requests that they are difficult to review. Therefore, the more concise your request, the more likely it is to be accepted.

Make All Communication Public

Contacting maintainers privately is not a good practice. Keep all conversations public. This allows more people to learn and benefit.

Once You’ve Asked, Be Patient

Even maintainers cannot handle everything perfectly. They also need time to review.

Respect the Community’s Decisions

Your ideas may differ from the project’s priorities or vision. The community may decide not to adopt your idea. You must accept this. If you cannot find a compromise, or can never agree, you should consider forking and starting your own new project.

Above All, Maintain Your Dignity

In open source projects, you collaborate with members from all over the world. Depending on language, culture, region, and time zone, there are differences in communication styles. Also, because you communicate through writing rather than face to face, it can be difficult to convey tone and mood accurately. A good way to overcome these difficulties is to always interpret others’ writing in good faith. When declining someone’s proposal, be polite, and express your own position clearly. Conduct yourself with dignity in the online space that is open source.

3 - Releasing Open Source

SK Telecom not only participates in open source communities but also actively supports collaborating with them by releasing its own software as open source. This is because we recognize how valuable collaboration with open source communities truly is.

• Benefits of Releasing Open Source

This document provides a guide for making the most of the advantages of open source collaboration when releasing SK Telecom’s software as open source, while avoiding legal, ethical, and technical problems.

SK Telecom Open Source Release Rules

SK Telecom respects the value of collaboration with open source communities and encourages releasing internal software as open source projects.

However, there are several rules that must be observed in order to protect SK Telecom’s intellectual property and to prevent unintended copyright infringement.

• Open Source Release Rules

SK Telecom Open Source Release Process

In accordance with SK Telecom’s Open Source Release Rules, the main steps for releasing open source are as follows.

• Open Source Release Process

3.1 - Benefits of Releasing Open Source

Companies release their software as open source for the following purposes.

It Can Be Economically Beneficial

Open source is not an act of charity. When a company releases its software as open source or contributes to open source, it does so because it expects a higher return on investment.

John Nash, a renowned mathematician who won the Nobel Prize in Economics for his “cooperative game” theory, proved that cooperation is not a zero-sum game and that, by cooperating, all participants can earn a higher return than what they invested. Open source is the most practical example of this theory.

For instance, Google released Angular (a web application framework), which it had used only internally, as open source, and Angular quickly spread among web developers. Developers used Angular to build many extensions and tools, and Google in turn was able to benefit from those extensions and tools. Although it is not easy to quantify the direct revenue Angular brought to Google, according to LinkedIn’s Job Tag analysis more than 700,000 jobs were created. Considering this job market, we can expect that the product market built on Angular is also quite large.

Can your project expect such a high return on investment as well? If so, start preparing to release it as open source.

It Can Become a Standard

Releasing a project as open source increases the likelihood that it will be adopted as a standard.

When a project becomes the de facto standard in its technical field, more external contributors participate, and the project and its surrounding ecosystem evolve more quickly. This accelerates innovation across the industry and makes it easier to adopt the services and products built using the project.

Take GNU and Linux as an example. GNU and Linux spread rapidly as they were released as open source modeled on the Unix operating system. Linux is now the de facto standard for servers, routers, and connected devices, and its use in consumer electronics is also steadily increasing. As a result, software vendors support Linux and provide tools that are familiar to Linux users (for example, Bash support on Microsoft Windows).

If you release your project as open source, can you expect it to become an industry standard and attract many external contributors? If so, start preparing to release it as open source.

It Can Grow an Ecosystem

When you release a project as open source, others adopt the project and use it to develop their own programs. As a result, they invest not only in their own programs but also in the success of the project. Open source communities include excellent developers who collaborate with one another within a project regardless of the company they belong to. Such developers not only bring diverse perspectives to the project but also allow the ecosystem to grow.

This is an especially effective strategy for projects with an extension mechanism, such as WordPress. WordPress opened up its plugin and theme APIs, forming an ecosystem in which contributors such as developers, designers, and consultants provide a wide variety of add-on features. Because the community provides plugins and themes free of charge or for a fee, WordPress does not have to handle every plugin or design itself. This kind of ecosystem benefits not only WordPress but also community members and end users.

As another example, in 2008 JavaScript was so slow that websites that relied heavily on it were almost unusable. When Google released Chromium as open source, it also released the V8 JavaScript engine. V8 is an engine that compiles JavaScript into machine code before execution and uses a variety of optimization techniques. This greatly improved browser performance, enhancing the user experience of websites, opening the door to web application development, and enabling JavaScript to be used together with server software such as Node.js. Because V8 was released as open source, not only Chrome but the entire ecosystem was able to advance together.

When you release your project as open source, can you expect similar growth of the project and its ecosystem? If so, start preparing to release it as open source.

It Can Help Recruit Excellent Developers

Recruiting is not the primary purpose of open source. However, it is one of the effects that often appears when a company releases software that is widely used internally as open source.

For example, when Google released Bazel, its internal build system, as open source, external developers began to use it as well. As the tool became open source, external people became familiar with it, and the company gained the advantage of being able to choose hires from among external contributors who already know the tool well. Because such people are already familiar with the technology, community building, support, and so on, the training process for putting them to work can be greatly simplified.

Through such open source activities, a company builds a stronger reputation in the community and becomes an attractive workplace for open source developers, enabling it to secure talent.

3.2 - SK Telecom Open Source Release Rules

SK Telecom respects the value of collaboration with open source communities and encourages releasing internal software as open source projects. However, there are several rules that must be observed in order to protect SK Telecom’s intellectual property and to prevent unintended copyright infringement.

• Obtain Approval
• Release Only Code You Have the Right to Release
• Be Careful About Exposing Intellectual Property
• Do Not Release Substandard Code
• Release Useful Code
• Secure Resources
• Use Your Company Email

Obtain Approval

From a copyright perspective, an open source release is the granting, through an open source license, of the right for anyone to modify/use/distribute the author’s work. Generally, the copyright of a work created during employment is owned by the employer. That is, a work created by an SK Telecom member is owned by SK Telecom. If a member releases a work as open source arbitrarily, it can cause unnecessary copyright infringement issues.

Therefore, if you want to release software as open source, follow the review request and approval process in accordance with SK Telecom’s open source release policy. Open Source Release Process

If anything seems undesirable during the release process, do not hesitate to contact the OSPO.

Release Only Code You Have the Right to Release

You do not have the right to release code that you did not write.

One of the worst situations that can occur in an open source project is the inclusion of legally problematic code in the project. Code that the company does not have the right to distribute, or code that infringes IP such as another company’s patents, can cause legal problems. Therefore, when preparing the code to be released, verify the origin of all code and remove any code that could be problematic.

Be Careful About Exposing Intellectual Property

Do not release code or documents that raise concerns about exposing the company’s intellectual property, such as sensitive information or patents.

If the code you want to release contains a company patent, verify whether it is acceptable to release that patent under an open source license. If anything is ambiguous, contact the OSPO.

Do Not Release Substandard Code

The readability and maturity of code serve as a measure of whether it is ready to be released as open source. Immature code causes the project to lose the community’s trust.

That said, the code does not have to be perfect. If you try to prepare the code to be perfect, you may never be able to start at all. Prepare it to the best level possible in the given environment and release it. Once the community becomes active, external contributors will participate in improving the code.

Release Useful Code

To become a successful project, it must also be useful to others. If a similar project already exists, it is better to participate in the existing project than to create a new one. Even if it is a project driven by a competitor, collaboration is important in open source. By participating and collaborating together, everyone can have excellent code.

You should not assume that the community will manage code unconditionally just because you release it, even if it is no longer useful. The open source community is not an organization that manages old code on your behalf. In fact, if a company repeatedly releases unattractive code, it will lose trust in the open source world, and later, even if it releases other code as open source, developers will pay no attention.

You should be able to expect that the open source you release will be a project that (1) provides differentiated value to the open source community, (2) solves problems the community has not been able to solve, and (3) can attract positive attention by showcasing our technical capabilities.

• If it is code that you were unable to use in an actual product or service, it is best not to release it as open source either. If you cannot persuade people to use it even in our own products, it is not easy to persuade others to use it.
• Do not release code that addresses a problem the open source community has already solved. In such a case, it is better to contribute to an existing open source project.

If you determine that the code you want to release can be useful externally as well, continue with the release process.

Secure Resources

You must secure the resources, including developers, that need to be allocated to the project.

• In the early stages, you need developers at a level similar to a typical in-house project.
• You also need developers who can quickly review external contributions.
• In addition, the roles of the legal and marketing teams are needed.
• You must also secure a budget for the infrastructure required to maintain and manage the project. This includes tools for project hosting such as GitHub.

If you cannot create an environment with sufficient resources, it is best not to release the project as open source.

Use Your Company Email

When engaging in open source release activities, do not use a personal email; use your SK Telecom email. Through this, (1) members gain a sense of responsibility that they are communicating with the community on behalf of the company, and (2) SK Telecom can improve its recognition as a company that actively engages in open source community release activities.

For how to set up your email on GitHub, refer to the following Link.

3.3 - SK Telecom Open Source Release Process

• 1. Internal Approval from Your Organization
• 2. Request OSPO Support
• 3. Key Decisions
  • Deciding the Project Name
  • Deciding the License
  • Deciding on a CLA
• 4. Preparing and Reviewing the Code to Be Released
  • Cleaning Up 3rd Party Code
  • Copyright and License Notices in Files
  • Removing Unnecessary Comments
  • Including a License File
  • Open Source License Inspection
  • Open Source Security Vulnerability Inspection
• 5. Building the Development Environment / Infrastructure
  • Repository / Issue Tracker
  • Test Automation
  • CI/CD
  • Website
  • Communication Channels
• 6. Establishing a Governance Structure
  • Membership
  • CODE OF CONDUCT
• 7. Documentation
  • README File
  • Development Guide
  • CONTRIBUTING File
• 8. Request OSPO Review
• 9. Release
• 10. Marketing
• 11. Growing the Community

1. Internal Approval from Your Organization

To release software as open source, obtain approval from the executive or leader in charge of your organization.

2. Request OSPO Support

After deciding to release open source and obtaining approval from your organization, request support from the OSPO: Support (opensource@sktelecom.com)

The OSPO explains the open source release rules and process based mainly on the contents of this guide and provides the support you need.

3. Key Decisions

Deciding the Project Name

It is best to choose a name that sounds good, is easy to remember, and conveys what the project is. Avoid names that could cause problems. For details, refer to the following page.

• Deciding the Open Source Project Name

Deciding the License

To release software as open source, you must grant a license. Only then can others use, copy, modify, and distribute the software. A license also protects contributors from legal issues. Therefore, when starting an open source project, you must choose an appropriate open source license and apply it to the project.

By default, SK Telecom applies Apache-2.0 when releasing software as open source. Apache-2.0 provides users with broad freedom while also being a well-drafted license from a legal standpoint, including an explicit patent grant clause.

However, in exceptional cases such as the following, a license other than Apache-2.0 may be applied.

• Some communities have a designated license that they primarily use. For example, the Node.JS project uses the MIT license. In such cases, you can apply that license.

• Some projects have a dependency on a library under the GPL license and therefore must be released under the GPL. In such cases, you can apply the GPL.

For reference, GitHub provides a guide on choosing a license when releasing open source: https://choosealicense.com

Deciding on a CLA

While operating a project released as open source, a situation may arise in which, for whatever reason, the existing open source license must be changed to a different license. In such a case, even the project Leader cannot change the license arbitrarily; it is only possible with the consent of all copyright holders who contributed works to the project. For a project that has received contributions from many contributors over a long period, obtaining consent from all copyright holders is in practice nearly impossible, and therefore changing the open source license is also impossible.

To reduce such disputes that can arise while managing the works of many contributors, a CLA (Contributor License Agreement) is an agreement that obtains contributors’ consent in advance, and it typically contains content seeking the contributor’s consent to the following.

- I (or the company I belong to) have the right to contribute the contribution I intend to make to the project. (That is, I am the author of this contribution.)
- I (or the company I belong to) grant the project the right to modify, distribute, and manage my contribution.
- I (or the company I belong to) will not revoke the rights granted.
- I (or the company I belong to) grant the project the right to change the license in the future as needed.

Requiring contributors to sign a CLA has the advantage of making it easier for the project to manage contributors’ works, but it has the disadvantage that contributions cannot be accepted from contributors who refuse to sign the CLA.

SK Telecom uses the attached CLA. SK Telecom template

• Whether to use a CLA for a project is decided by the releasing organization, depending on the project’s purpose and environment.
• If (1) there is no plan to change the open source license in the future, or (2) multiple companies participate and the likelihood of a copyright dispute is not high, you do not have to use a CLA.

4. Preparing and Reviewing the Code to Be Released

Before releasing code as open source, clean it up in advance—for example, by removing parts that could unnecessarily become issues.

Cleaning Up 3rd Party Code

If you need to include 3rd party code in the project—that is, if you need to include code to which SK Telecom does not hold the copyright—first verify whether SK Telecom has the right to redistribute it. If the code is already under an open source license, it can be redistributed on the condition that the license obligations are met.

• If you need help verifying redistribution rights, contact the OSPO (_{Open Source Program Office}): Support (opensource@sktelecom.com)

In the case of 3rd party code that SK Telecom can redistribute, place it in a directory separate from the existing code (for example, third_party). This increases the transparency of the project from a licensing standpoint and allows future users to easily find the 3rd party code and comply with the exact license requirements.

Every directory within the 3rd party directory must include its own LICENSE file (a text file containing the copyright information and the full text of the license). For example, the structure of the third_party directory in a Repository is as follows.

[Root Directory]
|-- SKT source code
|-- ....
`-- third_party
    `-- [external library A]
    |   |-- `LICENSE`
    |   `-- ...
    `-- [external library B]
        |-- `LICENSE`
        `-- ...

Copyright and License Notices in Files

Include a copyright and license notice in every file that contains source code. This helps users who want to copy and use only a few files comply with the license obligations as well. For details, refer to the following page.

• Copyright and License Notices

Removing Unnecessary Comments

Make sure that the code you are about to release does not contain the company’s trade secrets or unnecessary comments that could cause problems.

• Remove the names and email addresses of SK Telecom members (which do not need to be exposed externally).
• Remove internal information (internal code file names / paths, internal host / IP information, etc.).

For reference, the commands below make it easy to find unnecessary comments.

### Search for company website, email, and IP addresses
$ egrep -r '\.sktelecom\.com|@sk\.com|@sktelecom\.com|([0-9]+\.){3}[0-9]+' <path-to-source-directory>

### Search for Java/C/C++/Go/Objective-C/Objective-C++/Swift/Kotlin comments
$ find <path-to-source-dir> -type f | egrep '\.(c|cc|h|cpp|go|java|kt|m|mm|swift)' | \
  while read f; do echo "------------ $f ------------------"; sed -n -e '/\/\*.*\*\// {p; b}' \
  -e '/\/\*/,/\*\//p' -e '/\/\//p' "$f"; done

### Search for Python/Bash comments
$ find <path-to-source-dir> -type f | egrep '\.(py|sh)' | while read f; \
  do echo "------------ $f ------------------"; grep -o "#.*" "$f"; done

Including a License File

Include a text file named LICENSE containing a copy of the license in the top-level directory.

Open Source License Inspection

Use an open source license inspection tool to examine the source code to be released and confirm the following.

• Whether it includes other open source under a license that requires notice / source code disclosure obligations
• Whether it includes 3rd party source code that you do not have the right to release
• Whether it includes code under a license that conflicts with the open source license you will apply

Open Source Security Vulnerability Inspection

Use an open source security vulnerability inspection tool to check whether the source code to be released includes any open source with security vulnerability issues.

5. Building the Development Environment / Infrastructure

Repository / Issue Tracker

Prepare a repository for the project. Many projects use a GitHub or GitLab repository, or provide their own repository using a tool such as Gerrit. Features for bug, issue, and feature tracking should also be included as part of the infrastructure plan.

We recommend using SK Telecom’s GitHub Repository: https://github.com/sktelecom

• Request GitHub member registration from the OSRB: Support (opensource@sktelecom.com)

Test Automation

Open source development has the characteristic that many people in remote locations must collaborate asynchronously. To maintain excellent quality nonetheless, test automation is essential. Provide and automate the following tests.

• Unit Test
• Integration Test
• End-to-End Test

CI/CD

Build an environment that provides continuous automation and monitoring across the entire development life cycle—not only testing but also building and deployment. Again, an automated development, build, test, and deployment environment is essential for the success and continuity of an open source project.

Website

Build a website to provide a user guide and promote the project. It can also provide information such as the project’s leadership and governance details.

GitHub Pages provides an easy way to create and host a website.

Communication Channels

It is important to provide channels that enable smooth communication within the community. You also need tools that can be integrated into the entire development work flow, such as providing notifications for code check-ins, error logs, and other tasks. These become an important means of advancing the project in real time.

• One excellent tool is Slack. Slack is an online project management and communication platform that lets users share messages and files, configure work flows, search for information, and perform other tasks. However, Slack is a commercial tool and incurs maintenance costs.

• Tools released as open source include IRC, Gitter.im, and Rocket.Chat. Rocket.Chat is open source and provides functionality similar to Slack.

However, you must not discuss the company’s confidential information on third-party services such as Slack. These communication channels should be used only for public discussion and not as discussion tools for internal company organizations.

6. Establishing a Governance Structure

Membership

An open source project brings together diverse people from various regions to collaborate. For effective collaboration, the roles of the participants must be clearly distinguished. To this end, decide what membership to set up.

• For the membership of a typical open source project, refer to the following page: Open Source Project Membership
• In addition, as an example of membership, you can refer to the membership of the HANU open source project.

CODE OF CONDUCT

A CODE OF CONDUCT, also called a behavior code or code of conduct, is a document that defines the rules of conduct for participants so that the project remains healthy. For example, it emphasizes that there must be no discrimination based on gender, race, religion, age, and so on, and that everyone must act to ensure that all are warmly welcomed and able to participate safely. It also explains how to report someone who breaks those rules.

The following is a CODE OF CONDUCT template that can be used in SK Telecom’s open source projects:

7. Documentation

The most important part of attracting many users and contributors to an open source project is documentation. How detailed and accurate the documentation is perceived as the quality of the project. No matter how excellent the software’s features are, if they are not faithfully expressed in documentation, users will turn away.

README File

Do you want many users to use the open source you have released? Then provide a README file so that people can easily get started. The README file is the most important document for explaining the project to newcomers.

The README should include content that can answer the following questions.

• What does this project do?
• Why is this project useful?
• How do I get started?
• Where can I get help if I need it?

The background knowledge of project users varies widely. It is best to provide detailed documentation so that even people who are just starting out and have no experience can easily understand it. Remember that the more thorough the documentation, the more users and contributors you can attract.

Development Guide

Provide a development guide for prospective contributors who are willing to participate in the project. This document includes the following.

• How to build
• Testing Guide
• Coding Convention
• CI/CD
• Release

For an example of a development guide, refer to the HANU project Developing documentation.

CONTRIBUTING File

This is a file that provides content about “How to Contribute” for contributors to refer to. If the CONTRIBUTING file is not thorough, even users who were interested in contributing to the project will lose their enthusiasm.

The CONTRIBUTING file includes the following.

• How to submit a bug report (how to create an Issue / submit a Pull Request)
• How to propose a new feature
• How to set up the development environment and run tests

In addition, you can provide guidance on what kinds of contributions you would like to receive from contributors, such as the following.

• The types of contributions you want
• The project’s vision and roadmap
• How contributors can reach the project maintainers

In the early stages of a project, the CONTRIBUTING file can be simple. However, you must explain the essential conditions for contributing, such as how to submit bug reports and raise issues, and how to run preliminary tests.

Also, provide documentation with a warm and friendly tone. Such documentation makes potential contributors feel like participating in the project. For example, the Contributing guide of a project called Active Admin begins as follows.

“First of all, thank you for considering contributing to Active Admin. It’s people like you who make Active Admin such a great tool!”

Like the README, the CONTRIBUTING file is placed in the top-level folder within the project Repository. And to make it easy for users to access, provide a link to it within the README file.

8. Request OSPO Review

Once you are ready to release through the procedures above, provide the following information to the OSPO and request a review. The OSPO provides support to correctly release SK Telecom’s software as open source and to grow the community: Support (opensource@sktelecom.com)

Once you release something, it is not easy to reverse it. For that reason, review and prepare the code with as much time as possible. Of course, perfect code is not required. You should minimize mistakes so that there is nothing you regret after the release.

If there are no problems during the review, approval proceeds simply and quickly. The OSPO provides a service to encourage and help open source releases, not to block them.

After OSPO approval, proceed with releasing the project.

9. Release

After completing all preparation and review steps, finally confirm the following.

• Confirm that all code and documentation exist in the Repository to be released.
• Confirm that all project infrastructure is running, secure, and scalable.
• Confirm that developers can join and monitor the communication channels (IRC, Mailing List, etc.).

Then, launch the open source project. Following the OSPO’s guidance, publicly release the source code repository at https://github.com/sktelecom. (Depending on the development team’s needs, you may release it using a different repository.)

10. Marketing

Marketing is essential to keep a project going. Marketing includes promoting the project, establishing a successful operating strategy, providing a realistic budget and project branding, activating social media accounts, and other activities for long-term success. Here are a few methods for releasing a project and making it known.

1. Announce that the project has been released on the mailing lists or forums of communities related to the project.
2. Introduce the project on the SK Telecom tech blog (https://sktelecom.github.io/).
3. Promote it through the project’s social media (Twitter, Facebook, LinkedIn, etc.). You may also leverage SK Telecom’s social media accounts.
4. Give a topic presentation at an open source conference related to the project.

11. Growing the Community

Now it is your mission to promote the project and let people know they can use it. You can judge the project’s success by how many people participate in the project, use the code, fix bugs, and report problems.

• Community building does not happen on its own. For detailed activities for community building, refer to the following page: (The community growth guide is in preparation: haksung@sk.com)
• In addition, to do this, you must be able to measure the project. For details on metrics and measurement methods, refer to the following page: (The open source measurement guide is in preparation: haksung@sk.com)

3.3.1 - Deciding the Open Source Project Name

It is best to choose a name that sounds good, is easy to remember, and conveys what the project is. Avoid names that could cause problems.

Choose a Name That Is Easy to Remember

Choose a name that is easy to remember and that conveys what the project does. For example:

• Sentry (a sentinel, a guard): an app that monitors crash reporting.
• Thin (thin, simple): a fast and simple Ruby web server.

If your project is based on an existing project, you can also prefix its name with that project’s name. For example, node-fetch is a module that provides window.fetch to Node.js.

Above all, consider clarity. A name with humor in it may be fun, but it may not be understood by people from other cultures or language backgrounds.

Avoid SK Telecom Brand Names

Unless it is a product or service that SK Telecom promotes, do not use SK Telecom’s brand. Also, unless absolutely necessary, do not use names in the “T-name” form (e.g., T world).

Avoid Duplicate Names

First check whether there is an open source project with a similar name. In particular, if there is a project with the same name in the same ecosystem, you should avoid that name. If the name overlaps with an existing popular project, it can confuse users.

Considering promotion through a website, Twitter, and so on, check in advance whether you can secure the desired domain name or SNS accounts. Even if you do not need them right away, it is best to secure them in advance.

Do Not Use Other Companies’ Brands

That is, “Test Library for Java” is better than “Java Test Library.”

Do Not Infringe Trademarks

It is also important to verify that the project name does not infringe a trademark. A company that holds the trademark could later request that the project be discontinued or take legal action. There is no need to create a situation where you have to take on such a risk. You can check for trademark conflicts using Kipris’s trademark search (or, for overseas, the WIPO Global Brand Database).

3.3.2 - Copyright and License Notices in Files

Copyright is created automatically when an author creates a work (since the Berne Convention). Every work is protected by copyright, and the copyright holder has exclusive rights to the work. Therefore, to allow others to use our works (source code, text, images, other media, etc.), we must grant them a license. The dictionary definition of a license is “permission obtained from a qualified authority to exercise a particular right,” and exercising such a right without that permission becomes an illegal act, such as copyright infringement.

Although a copyright notice is not required by law, it makes sense to include a copyright notice in source code files, considering that (1) most open source licenses require a copyright notice, and (2) users may want to contact the copyright holder for legal or technical reasons.

For every source code file that SK Telecom writes and releases as open source, give notice of the copyright and license in the following way.

Copyright Notice

Add a copyright notice containing the following information to the header at the top of the source code.

• Copyright (or the © symbol)
• The year first written
• The name of the copyright holder
  • The copyright of a work authored by an SK Telecom member is held by SK Telecom. Therefore, write the company name. (SK TELECOM CO., LTD.)
  • If you plan to actively accept external contributions rather than developing solely within SK Telecom, you can also consider indicating the copyright information as “The [Project] Authors” and managing author information in an AUTHORS file.
• Contact (Optional)
  • Users may want to contact the author for technical or legal inquiries. You can provide the author’s email information to respond to this. This is not required.
  • Alternatively, write contact information such as the URL of the project’s website where users can obtain information.

Indicate the copyright notice using the SPDX Tag (“SPDX-FileCopyrightText”), which is the method recommended by REUSE.software. An example is shown below.

SPDX-FileCopyrightText: Copyright 2021 SK TELECOM CO., LTD. <{$project-website-url}>

License Notice

It is also important to indicate what the license is for each source code file. To reduce confusion, indicate the license using the SPDX ID provided by the Linux Foundation’s SPDX project. Using an SPDX ID is simple.

First, check the SPDX Identifier of the open source license you want to apply on the SPDX License List page. For example, the SPDX Identifier of Apache License version 2 is Apache-2.0.

Then, at the top of the source code file, indicate the license Identifier using a tag called SPDX-License-Identifier. An example is shown below.

SPDX-License-Identifier: Apache-2.0

Automation Tools

(The guide needs to be improved after the tools are enhanced to add the SPDX tag together: haksung@sk.com)

addlicense

• addlicense: Automatically recognizes source files and adds copyright/license notices.

addlicense -c "SK TELECOM CO., LTD." -l apache [filename]

autogen

• autogen: Automatically adds comments and code to new files.

autogen --no-code --no-tlc -c "SK TELECOM CO., LTD." -l apache [filename]

You can also apply this as a batch. The example below is a batch applied to Java files.

find . -type f -name \*.java -exec autogen -i --no-code --no-tlc -c \
  "SK TELECOM CO., LTD." -l apache {} \;

4 - Supply Chain Security

Software Supply Chain Security

In recent years, alongside license compliance, security vulnerability management and software supply chain security have emerged as critical challenges in the open source ecosystem. As regulations tighten in the United States and Europe, SBOM (Software Bill of Materials) management and systematic vulnerability response have become essential.

To strengthen the transparency and security of its software supply chain, SK Telecom has established a systematic management process and provides guidelines that both internal members and suppliers must comply with.

Guide Structure

Supply Chain Security Overview

Explains why supply chain security matters, the global regulatory landscape, and SK Telecom’s supply chain security policy.

SBOM Management

Provides a technical guide for both internal members and suppliers on what an SBOM is and how to generate and manage one.

Supplier Guide

Provides SBOM submission requirements and a generation guide for suppliers that deliver software to SK Telecom.

Key Standards and Specifications

• ISO/IEC 18974: OpenChain Security Assurance Specification
• SPDX (ISO/IEC 5962): Software package data exchange standard
• CycloneDX: Security-focused SBOM standard
• NIST SSDF: Software supply chain security framework

For related regulatory trends (U.S. EO 14028, the EU Cyber Resilience Act, etc.), see the Regulatory Trends page.

Contact

If you have any questions regarding supply chain security, please refer to the following.

• Supply chain security policy inquiries: opensource@sktelecom.com
• SBOM submission: Contact your business unit and security team representatives (see Submission Process)

4.1 - Software Supply Chain Attacks and the Need for Security

1. What Is a Software Supply Chain Attack?

A software supply chain attack is a cyberattack technique in which an attacker infiltrates the systems of a software developer or supplier, or the development process itself, to plant malicious code or exploit vulnerabilities.

Whereas traditional attacks directly target end users, supply chain attacks contaminate trusted software updates or development tools, thereby simultaneously infecting the many downstream companies and users that rely on them.

graph LR
    A[Attacker] -->|Infiltrate| B[Supplier Build Server]
    B -->|Inject Malware| C[Compromised Software Update]
    C -->|Distribute| D[Customer A]
    C -->|Distribute| E[Customer B]
    C -->|Distribute| F[Customer C]
    style B fill:#f9f,stroke:#333,stroke-width:2px
    style C fill:#f96,stroke:#333,stroke-width:2px

2. Notable Attack Cases

The major security incidents of recent years have impressed the importance of supply chain security on the entire world.

The SolarWinds Incident (2020)

• Overview: The build system of SolarWinds Orion, a network monitoring solution, was hacked, and a backdoor was planted in legitimate update files.
• Impact: Some 18,000 organizations worldwide were affected, including U.S. government agencies and Fortune 500 companies.
• Lesson: It demonstrated that even officially signed software from a trusted vendor may not be safe.

The Log4j Vulnerability (2021)

• Overview: A critical vulnerability enabling remote code execution (RCE), known as Log4Shell, was discovered in Log4j, a Java-based logging library.
• Impact: Hundreds of millions of devices and servers worldwide that use this library directly or indirectly were exposed to risk.
• Lesson: It became a turning point that made organizations realize how important it is to understand which open source components their systems use, through an SBOM (Software Bill of Materials).

The 3CX Supply Chain Attack (2023)

• Overview: The desktop app of the VoIP software 3CX was distributed while infected with a trojan.
• Characteristics: The attackers first hacked the PC of a 3CX employee and then moved laterally into the development environment to tamper with the binaries.

3. Why Supply Chain Security?

Modern software development environments are built on top of complex, interwoven dependencies.

1. Growing open source dependencies: 70-90% of modern application code consists of open source components.
2. Ripple effect: When a single common component is compromised, the damage spreads worldwide.
3. Difficulty of detection: Code that is compromised during the development and build stages can easily bypass traditional security checks (firewalls, antivirus, etc.).

Accordingly, SK Telecom has established and enforces SBOM adoption and a rigorous supply chain security policy in order to ensure transparency across the supply chain and to manage risk.

Related Documents

• Global Regulatory Trends: Key regulatory developments such as U.S. EO 14028 and the EU CRA
• SK Telecom Supply Chain Security Policy: SK Telecom’s specific requirements
• Supplier Guide: Guidance on SBOM generation and submission for suppliers

4.1.1 - Regulatory Trends

1. United States: Executive Order 14028 (EO 14028)

In May 2021, the Biden administration issued the “Executive Order on Improving the Nation’s Cybersecurity (Executive Order 14028).” This was a decisive turning point at which supply chain security began to be addressed at the level of national security in the aftermath of the SolarWinds incident.

Key Provisions

• Mandatory SBOM submission: Companies that supply software to the federal government must submit an SBOM.
• NIST guideline compliance: Companies must comply with the Secure Software Development Framework (SSDF) defined by NIST (the U.S. National Institute of Standards and Technology).
• Minimum standards: The U.S. administration led standardization by defining the minimum elements of an SBOM (data fields, automation support, etc.).

2. European Union (EU): Cyber Resilience Act (CRA)

Through the Cyber Resilience Act (CRA), the EU has enacted into law security requirements spanning the entire lifecycle of digital products.

Key Provisions

• CE marking certification: All products with digital elements can only be sold within the EU if they meet the cybersecurity requirements and bear the CE mark.
• Defined security support period: Manufacturers must provide security updates throughout the expected product use period (up to 5 years).
• Vulnerability reporting obligation: Critical vulnerabilities must be reported to ENISA (the European Union Agency for Cybersecurity) within 24 hours of discovery.
• SBOM management: Manufacturers must identify and document (via an SBOM) the software components of their products.

3. South Korea: SW Supply Chain Security Guidelines

In step with the global trend, the South Korean government (the Ministry of Science and ICT, KISA, and the National Intelligence Service) has also released the “SW Supply Chain Security Guidelines” and is pursuing proof-of-concept initiatives.

Key Contents (based on v1.0)

• Recommendation to adopt SBOM: It is recommended that an SBOM be generated and utilized when developing and delivering software in both the public and private sectors.
• Definition of security activities by role:
  • Supplier (developer): Build a secure development environment, generate and provide an SBOM, and inspect for security vulnerabilities.
  • Consumer (operator): Require and verify the SBOM of delivered software, and continuously monitor for vulnerabilities.

SK Telecom’s Response

To proactively respond to these domestic and international regulatory trends, SK Telecom has established its own supply chain security policy and requires all partners to submit SBOMs that conform to global standards (SPDX, CycloneDX).

Related Documents

• Supply Chain Security Overview: Concepts and notable cases of software supply chain attacks
• SK Telecom Supply Chain Security Policy: The specific policy that SK Telecom requires of suppliers
• Supplier Guide: Guidance on SBOM generation and submission for suppliers

4.1.2 - SK Telecom Supply Chain Security Policy

---

NOTICE.

In accordance with internal security and document management policies, this document is a summary that excludes confidential content. Please note that it is written around high-level key points rather than the full content.

---

1. Purpose of the Policy

The purpose of this policy is to ensure the transparency of all software that SK Telecom adopts, and to identify and eliminate, in advance, the risks of known vulnerabilities and license violations.

2. Scope of Application

All suppliers that enter into a software supply contract with SK Telecom are subject to this policy.

3. Key Requirements

Suppliers must comply with the following three principles.

Principle 1: Mandatory SBOM Submission

• For every software delivery, the supplier must submit an SBOM (Software Bill of Materials) corresponding to that version.
• Accepted formats: CycloneDX (v1.3 or later) or SPDX (v2.2 or later)
• Required information: supplier name, component name, version, dependency relationships, and Package URL (PURL)

Principle 2: Vulnerability Inspection and Remediation

• Before delivery, the supplier must independently check for the latest security vulnerabilities (CVEs).
• If Critical/High severity vulnerabilities are found, the supplier must patch them or apply mitigation measures before delivery.
• If patching is not possible, the supplier must prove, through a “vulnerability justification statement,” that the vulnerability has no actual impact on the service.

Principle 3: Transparent Change Management

• If the components of the software change during the contract period (updates, patches, etc.), the supplier must immediately submit an updated SBOM.
• The supplier must warrant that it has complied with open source license obligations (notice obligations, source code disclosure obligations, etc.).

Related Documents

• Supply Chain Security Overview: Concepts and notable cases of software supply chain attacks
• Global Regulatory Trends: Domestic and international regulatory developments related to SBOM
• Supplier Guide: Detailed guidance on how to generate and submit an SBOM
• Submission Requirements: SBOM format and required data field definitions

4.2 - What Is an SBOM?

Overview

This section is a practical SBOM (Software Bill of Materials) guide for members of the organization. Beyond simply complying with policy, it covers how to use SBOMs to improve the security of projects and the efficiency of dependency management.

Guide Structure

This guide is organized step by step, from the adoption of SBOMs to their operation.

1. Concept and Necessity: Explains what an SBOM is and the fundamental reasons why we need it now.
2. Standards Comparison (SPDX vs CycloneDX): Understand the differences between the industry-standard formats so you can choose the format that fits the nature of your project.
3. Generating a Project SBOM: Guides you through the practical methods for extracting an SBOM directly from a project under development.
4. CI/CD Integration: Covers how to automate SBOM generation in CI/CD pipelines such as Jenkins and GitHub Actions.
5. SBOM Management: Introduces strategies for storing generated SBOMs in a central repository and managing them by version.

graph TD
    A[Start Development] --> B[Add Dependencies]
    B --> C{Build/Deploy}
    C -->|Automation| D[Generate SBOM]
    D --> E[Upload to Repository]
    E --> F[Vulnerability Analysis]
    F --> G[Security Remediation]

SBOM Generation

For detailed SBOM generation methods and technical guidance, please refer to the following documents.

• Supplier Guide (For Suppliers)
• How to Generate an SBOM

4.2.1 - SBOM Concept and Necessity

Definition of an SBOM

An SBOM (Software Bill of Materials) is a formalized specification that describes the list of all components, libraries, modules, and so on that make up a piece of software, along with the dependency relationships among them. It applies the manufacturing concept of a BOM (Bill of Materials), used to manage a product’s parts list, to software engineering.

graph TD
    A[Software Product] --> B[Direct Dependencies]
    B --> C[Library A v1.2.3]
    B --> D[Library B v2.0.1]
    B --> E[Library C v3.1.0]
    C --> F[Transitive Dependencies]
    F --> G[Library D v1.0.0]
    F --> H[Library E v2.5.0]
    D --> F

Key Components of an SBOM

Component Information

Includes basic information about each software component.

• Name: The official name of the component
• Version: The exact version number
• Supplier: The organization or individual that provided the component
• License: The applicable open source license

Unique Identifiers

Standardized identifiers are used to clearly identify components.

Package URL (purl)

This is the most commonly used identifier format.

pkg:maven/org.springframework/spring-core@5.3.20
pkg:npm/express@4.18.2
pkg:pypi/django@4.1.0

CPE (Common Platform Enumeration)

Used to integrate with security vulnerability databases.

cpe:2.3:a:apache:log4j:2.14.1:*:*:*:*:*:*:*

Dependency Relationships

Specifies the dependency relationships among components.

• Direct Dependencies: Libraries that the project uses directly
• Transitive Dependencies: Libraries that the direct dependencies, in turn, depend on

Metadata

Includes information about the SBOM itself.

• Generation tool: The name and version of the tool that generated the SBOM
• Generation time: The date and time the SBOM was generated
• Author: The organization or individual that generated the SBOM

Why Is It Needed?

An SBOM is not merely a document; it is core data for software transparency.

1. Rapid Identification of Security Vulnerabilities

When a new vulnerability is disclosed (e.g., the Log4j incident), you can immediately determine where in your services the affected library is being used. Without an SBOM, you would have to conduct an exhaustive inspection of every server and codebase one by one, and you would miss the golden window for response.

2. License Risk Management

Open source license violations can lead to legal disputes. Through an SBOM, you can identify all licenses included in a project and block, in advance, the use of incompatible licenses (e.g., combining GPL with commercial code).

3. Software Quality and Obsolescence Management

By identifying old and unsupported (EOL, End-of-Life) components, you can manage technical debt and maintain the health of your software.

4. Regulatory Compliance

Various organizations, including the U.S. federal government, are mandating SBOM submission.

• U.S. Executive Order 14028 (federal government suppliers)
• EU Cyber Resilience Act
• FDA approval for medical devices

Related Documents

• SBOM Standards Comparison (SPDX vs CycloneDX)
• Supplier Guide: How to generate and submit an SBOM

References

• NTIA SBOM Minimum Elements
• CISA SBOM Sharing Lifecycle
• Linux Foundation: SBOM Guide

4.2.2 - SBOM Standards

Major SBOM Standards

There are currently two major standard formats that split the market between them. Both formats are widely used, but they differ in their origins and primary focus areas.

• SPDX: Software Package Data Exchange
• CycloneDX: A security-focused SBOM standard led by OWASP

SPDX (Software Package Data Exchange)

Overview

SPDX is an open source project led by the Linux Foundation, developed to represent the license and copyright information of software packages in a standardized way. (ISO/IEC 5962:2021)

Key Characteristics

1. SPDX was originally developed to exchange open source license information, so it expresses license-related information in detail.

• Standardized license identifiers (SPDX License List)
• License expressions (e.g., Apache-2.0 OR MIT)
• Copyright information and per-file licenses

2. It can include not only package-level information but also individual file-level information.

• Per-file hash values
• Per-file licenses
• Per-file copyright information

SPDX Document Structure

{
  "SPDXID": "SPDXRef-DOCUMENT",
  "spdxVersion": "SPDX-2.3",
  "name": "Example-SBOM",
  "documentNamespace": "https://example.com/sbom-2023-001",
  "creationInfo": {
    "created": "2023-01-15T10:30:00Z",
    "creators": ["Tool: SPDX-Tools-2.3"]
  },
  "packages": [
    {
      "SPDXID": "SPDXRef-Package-1",
      "name": "spring-core",
      "versionInfo": "5.3.20",
      "licenseDeclared": "Apache-2.0",
      "externalRefs": [
        {
          "referenceType": "purl",
          "referenceLocator": "pkg:maven/org.springframework/spring-core@5.3.20"
        }
      ]
    }
  ]
}

Advantages

• Officially recognized as an ISO international standard
• Detailed license information
• Traceable down to the file level
• A mature tooling ecosystem

Disadvantages

• Security vulnerability information is optional
• The structure is somewhat complex
• May be insufficient for security-focused projects

CycloneDX

Overview

CycloneDX is an SBOM standard developed by OWASP (Open Web Application Security Project), with a focus on application security.

Key Characteristics

1. It was designed from the ground up for security vulnerability management.

• Vulnerabilities
• Security Analysis results
• Threats

2. Compared to SPDX, its structure is concise and easy to understand.

• Focus on essential information
• JSON and XML format support
• Small file size

3. It provides extensions that support a variety of use cases.

• SaaS BOM
• Hardware BOM
• AI/ML BOM
• Cryptography BOM

CycloneDX Document Structure

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2023-01-15T10:30:00Z",
    "tools": [
      {
        "name": "cyclonedx-maven-plugin",
        "version": "2.7.9"
      }
    ],
    "component": {
      "type": "application",
      "name": "MyApp",
      "version": "1.0.0"
    }
  },
  "components": [
    {
      "type": "library",
      "name": "spring-core",
      "version": "5.3.20",
      "purl": "pkg:maven/org.springframework/spring-core@5.3.20",
      "licenses": [
        {
          "license": {
            "id": "Apache-2.0"
          }
        }
      ]
    }
  ]
}

Advantages

• Includes security vulnerability information by default
• A concise structure that is easy to understand
• Excellent integration with security tools
• An active community and ongoing tool development

Disadvantages

• Not an ISO standard (a de facto standard)
• File-level information is limited
• License expression is simpler than in SPDX

SPDX vs CycloneDX Comparison

Selection Guide

When CycloneDX Is the Right Choice

CycloneDX is recommended in the following cases.

• Security first: Vulnerability management is the primary goal
• Quick start: Rapid adoption thanks to a concise structure
• DevSecOps: Automation through integration into CI/CD
• Modern applications: Cloud and container environments

When SPDX Is the Right Choice

SPDX is recommended in the following cases.

• Emphasis on license compliance: Detailed license information is required
• File-level tracking: Per-source-file information is required
• ISO standard compliance: Official standard certification is required
• Legacy systems: Existing SPDX tools are already in use

SK Telecom Recommendation

For SK Telecom’s internal projects, the CycloneDX (JSON) format is recommended by default. This is because CycloneDX offers better interoperability with the internal vulnerability management system. That said, compatibility is also supported when an external partner submits SPDX.

Interconversion

Conversion tools are available between SPDX and CycloneDX.

Converting from SPDX to CycloneDX

# Using cyclonedx-cli
cyclonedx convert --input-file sbom.spdx.json \
  --output-file sbom.cdx.json --input-format spdx \
  --output-format json

Converting from CycloneDX to SPDX

# Using spdx-tools
java -jar tools-java-1.1.0-jar-with-dependencies.jar \
  Convert bom.cdx.json bom.spdx.json

Related Documents

• What Is an SBOM?: The concept and necessity of an SBOM
• Supplier Submission Requirements: Formats and versions accepted by SK Telecom

References

• SPDX Specification
• CycloneDX Specification
• NTIA SBOM Formats Comparison

4.3 - Supplier SBOM Submission Guide

To strengthen the transparency and security of its software supply chain, SK Telecom asks suppliers to submit an SBOM (Software Bill of Materials) for all software components and dependencies they deliver. This guide explains how suppliers can generate and submit an SBOM in a format that meets SK Telecom’s security policy.

Scope of Application

All suppliers (including developers and resellers) that deliver the following types of software are subject to these guidelines.

• Source code: Applications written in Java, Python, JavaScript, Go, C/C++, etc.
• Container images: Docker images or OCI-compliant containers
• Executables: Compiled binaries (.jar, .dll, .so) and libraries
• Embedded systems: Firmware images, RootFS, device drivers

SBOM Submission Process

We ask suppliers to follow the procedure below, from the time of contract through final delivery.

flowchart TD
    A[Contract Review] --> B["Software Development/Build"]
    B --> C{Generate SBOM}
    C -->|Use SKT-provided tool| D[Use SKT SBOM Generator]
    C -->|Use your own tool| E["Use open source tools<br>(cdxgen, Syft, etc.)"]
    D --> F["Data Validation (PURL Check)"]
    E --> F
    F --> G["Submit SBOM (Email/Portal)"]
    G --> H[SKT Security Review]
    H -->|Approved| I[Delivery Complete]
    H -->|Rejected| J[Remediate and Resubmit]
    J --> F

Guide Structure

This section is organized as follows.

1. Submission Requirements: Defines the required formats (CycloneDX, SPDX) and data fields that SK Telecom requires.
2. SKT SBOM Generator: Explains how to use SK Telecom’s SBOM generation tool.
3. Using Open Source Tools: Explains how to generate an SBOM using general-purpose open source tools (cdxgen, Syft, etc.).
4. Validation Checklist: Provides a checklist of essential items to verify before submission.
5. Submission Process: Explains the naming conventions and submission channels for the generated SBOM file.

Related Documents

• SK Telecom Supply Chain Security Policy: Background and principles of the mandatory SBOM submission policy
• Global Regulatory Trends: Domestic and international regulatory landscape related to SBOM

4.3.1 - SBOM Submission Requirements

1. Standard Data Formats

SK Telecom supports both formats that have become established as global standards. Suppliers may choose and submit the format supported by the tool they use.

Note: Both formats are recognized equally, but CycloneDX (JSON) format is recommended for internal system interoperability.

2. Required Information

The SBOM document you submit must include the following information. Missing information may result in rejection.

2.1 Metadata

Information about the document itself and the generation tool.

• Timestamp: Generation date and time (ISO 8601 format)
• Tool Info: Vendor, name, and version of the generation tool (e.g., CycloneDX-Maven-Plugin v2.7.9)
• Component Info: Name and version of the top-level software being delivered

Generation Tool Specification Format

Generation tool information must be recorded in the following fields depending on the format.

• SPDX: Record the tool name and version in the creationInfo.creators field with the Tool: prefix
• CycloneDX: Record vendor, name, and version in the metadata.tools array

// SPDX creationInfo example
"creationInfo": {
  "created": "2026-04-06T03:22:00Z",
  "creators": ["Tool: Syft-0.98.0", "Organization: VendorName"]
}

2.2 Components

Information about the individual libraries that make up the software.

• Name: Component name (e.g., commons-lang3)
• Version: Component version (e.g., 3.12.0) — Required: Vulnerability mapping is impossible without the version
• PURL (Package URL): [Required] Package identifier

Version information must be included. Each package/component must record its exact version in SPDX’s versionInfo field or CycloneDX’s version field. Without a version, mapping to the vulnerability database is impossible, so security analysis cannot be performed.

2.3 Dependency Scope

Important: Transitive dependencies must be included.

SK Telecom analyzes vulnerabilities based on the submitted SBOM. An SBOM that includes only direct dependencies may miss hidden vulnerabilities and may therefore be rejected.

What are transitive dependencies?

For example, if a project uses library-A directly, and library-A internally uses library-B, then library-B is a transitive dependency. Even if library-B has a vulnerability, it cannot be detected unless it is included in the SBOM.

MyApp
  └─ library-A v1.0 (direct dependency)  ← explicitly declared by the supplier
       └─ library-B v2.3 (transitive dependency)  ← must be included in the SBOM
            └─ library-C v0.9 (transitive dependency)  ← must be included in the SBOM

Prerequisites for generating a correct SBOM

For transitive dependencies to be included accurately, the SBOM must be generated with the build (or package installation) completed. When only source code is present, transitive dependencies may be omitted.

• Java (Maven): Generate after running mvn package or mvn dependency:resolve
• Java (Gradle): Generate after running ./gradlew dependencies
• Python: Generate after pip install -r requirements.txt (with the virtual environment activated)
• Node.js: Generate after running npm install or yarn install
• Go: Generate after running go mod download

For how to include transitive dependencies with each tool, refer to the Using Open Source Tools guide.

3. Package URL (PURL) Compliance

PURL (Package URL) is a standard URL format for uniquely identifying a software package. SK Telecom’s vulnerability analysis system operates based on PURL, so a valid PURL must be included for every component.

A PURL must be in the standard format beginning with the pkg: prefix. Free text such as name:version or org/repo:tag is not allowed; in such cases vulnerability mapping is impossible and the SBOM will be rejected.

PURL Examples by Language

PURL Type Restrictions

The purl must be of a type that can identify the ecosystem.

Correct / Incorrect PURL Examples

For detailed PURL specifications, refer to the official Package URL spec.

4. Sample Document

CycloneDX Sample

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "version": 1,
  "metadata": {
    "timestamp": "2023-10-15T10:30:00Z",
    "tools": [{
      "vendor": "Example Corp",
      "name": "cyclonedx-maven-plugin",
      "version": "2.7.9"
    }],
    "component": {
      "type": "application",
      "name": "PaymentModule",
      "version": "2.1.0",
      "purl": "pkg:maven/com.example/payment-module@2.1.0"
    }
  },
  "components": [{
    "type": "library",
    "name": "spring-core",
    "version": "5.3.20",
    "purl": "pkg:maven/org.springframework/spring-core@5.3.20",
    "licenses": [{
      "license": {
        "id": "Apache-2.0"
      }
    }]
  }]
}
...

References

• CycloneDX Specification
• SPDX Specification
• Package URL Specification

Related Documents

• Supplier Guide Home
• SKT SBOM Generator: SK Telecom’s SBOM generation tool
• Using Open Source Tools: Guidance on open source tools such as cdxgen and Syft
• Validation Checklist: Items to verify before submission
• Submission Process: Submission method and email template

4.3.2 - SKT SBOM Generator

SKT SBOM Generator

The SKT SBOM Generator is an open source tool that lets suppliers generate deliverables that meet SK Telecom policy in a Docker environment. You do not need to install per-language tools locally; it analyzes multiple languages and produces a CycloneDX (JSON) deliverable.

This page covers only the quick start. For installation, the full set of options, language-specific guides, input scenarios, the web UI, and other details, see the official repository documentation.

github.com/sktelecom/sbom-tools

Bug reports, feature suggestions, and Pull Request contributions are welcome.

Deliverables Generated

A single run generates the following three deliverables together (the --all option).

Prerequisites

The SBOM Generator runs on Docker. Install and run Docker Engine 20.10 or later. On Windows without Docker, we recommend Rancher Desktop, which is free. The first run downloads a scanner image (about 3–4 GB), so it takes roughly 5–15 minutes.

Getting Started on Windows (No Command Line)

If you are not comfortable with the command line, you can generate an SBOM in one of two ways. For the full procedure, see the Windows quick start guide.

• Executable: Download SBOM-Generator-*.exe from the latest release and double-click it. The file is not yet code-signed, so if Windows SmartScreen warns, click “More info” and then “Run anyway”.
• Repository ZIP: From the repository’s Code button, choose Download ZIP, unzip it, and double-click scripts\sbom-ui.bat; the browser opens http://localhost:8080.

In the web UI, the progress log is shown in real time on the right, and you can download the deliverables when it finishes.

Quick Start (CLI)

On macOS and Linux, download and run the script from a shell.

curl -O https://raw.githubusercontent.com/sktelecom/sbom-tools/main/scripts/scan-sbom.sh
chmod +x scan-sbom.sh
cd /path/to/my-project
/path/to/scan-sbom.sh --project "MyApp" --version "1.0.0" --all --generate-only

• --generate-only creates files only locally, without uploading them to the portal (recommended until submission).
• For the web UI, run ./scan-sbom.sh --ui (the browser opens http://localhost:8080).
• On Windows, run the same commands through scripts\scan-sbom.bat (it forwards them via Git Bash, so Git for Windows is required).
• For other input forms such as a GitHub URL, source ZIP, Docker image, firmware, or binary, and the full set of options, see the Usage Guide.

Learn More

The authoritative source for using the tool is the repository documentation.

Next Steps

After generating the SBOM, verify the file with the Validation Checklist and submit it following the Submission Process. For the required data fields, see the Submission Requirements; to use tools such as cdxgen or Syft directly instead of the SKT tool, see Using Open Source Tools.

4.3.3 - Generating an SBOM with Open Source Tools

If you cannot use the SKT-provided tool, or you already have your own build pipeline, you can use open source tools directly. Below is a list of the major open source tools validated by SK Telecom, along with links to their official documentation.

If you are not comfortable setting up a tool environment and you have Docker installed, consider reviewing the SKT SBOM Generator first.

Tool Selection Guide

graph TD
    A[Identify analysis target] --> B{Is it source code?}
    B -- Yes --> C[cdxgen recommended]
    B -- No --> D{Is it a Docker image?}
    D -- Yes --> E[Syft or Trivy recommended]
    D -- No --> F[Binary/Firmware]
    F --> G[Syft recommended]

Major Tools

cdxgen (recommended for source code analysis)

Automatically analyzes projects in various languages such as Java, Python, Node.js, and Go, and generates an SBOM in CycloneDX format.

• Official documentation: https://cdxgen.github.io/cdxgen
• GitHub: https://github.com/CycloneDX/cdxgen
• Supported languages: Java (Maven/Gradle), Python, Node.js, Go, Ruby, PHP, Rust, .NET, C/C++, etc.

Syft (recommended for container image and binary analysis)

Analyzes built container images and build artifacts that include package manager metadata to identify both OS packages and application libraries. Supports CycloneDX and SPDX formats.

• Official documentation: https://github.com/anchore/syft
• Recommended analysis targets: built Docker images, OCI images, tar files

# Recommended: scan a built image (PURL and ecosystem identified automatically)
syft <image-name>:<tag> -o cyclonedx-json=sbom.json

# Not recommended: scan an installation directory or raw files (rejected due to missing PURL)
syft dir:/root/nag_pkg   # without package manager metadata, PURL count becomes 0

Trivy (container image analysis)

An all-in-one tool that can perform container image analysis and vulnerability scanning together.

• Official documentation: https://aquasecurity.github.io/trivy/
• GitHub: https://github.com/aquasecurity/trivy

Language-Specific Dedicated Plugins

Using a build tool plugin lets you extract more accurate dependency information.

Verifying Transitive Dependency Inclusion

An SBOM submitted to SK Telecom must include transitive dependencies.

Transitive dependencies are libraries that the project does not declare directly, but on which the libraries it uses depend internally. If these are omitted, hidden vulnerabilities cannot be detected and the SBOM may be rejected.

Key principle: Generate the SBOM after the build (package installation) is complete.

When only source code is present, transitive dependencies may be omitted. Refer to the table below and complete the prerequisite steps before generating the SBOM.

Transitive Dependency Support by Tool

Recommendation: When delivering as a Docker image, scanning the built image with Syft can include more complete transitive dependencies than source code analysis.

Common Precautions

Verify the following before using a tool.

• Transitive dependency inclusion: Refer to the table above and complete the prerequisite steps before generating the SBOM. Missing dependencies are grounds for rejection.
• PURL inclusion: Verify that the generated SBOM includes a purl field for every component. SK Telecom’s system maps vulnerabilities based on PURL. Before submission, count the components that have a PURL with jq '[.components[] | select(.purl)] | length' sbom.json and confirm it matches the total component count; if it is 0 or significantly lower, regenerate following the procedure in the Validation Checklist.
• Output format: CycloneDX JSON format is recommended. (Use -o cyclonedx-json or an equivalent option)
• Project information: Verify that the metadata accurately records the name and version of the delivered project.

Related Documents

• Submission Requirements: The required data fields that must be included in the SBOM
• Validation Checklist: Items to verify before submission
• SKT SBOM Generator: SK Telecom’s SBOM generation tool

4.3.4 - Pre-Submission SBOM Validation Checklist

Essential Checklist Items

An SBOM that does not pass the checklist below may be automatically rejected by the system.

1. File Integrity

• Is the file extension .json or .xml? (Not an archive file)
• Is the file size at least 1KB, and the content not empty?
• Are there any JSON syntax errors? (Verification with jq or similar is recommended)

2. Required Data Fields

• bomFormat: Is CycloneDX or SPDX specified?
• Metadata: Are the name and version of the top-level component (the delivered project) accurate?
• Components: Does the list of included libraries match the actual ones?

3. Dependency Completeness Check

Missing transitive dependencies are the most common reason for rejection. Be sure to verify the items below.

• Are all direct dependencies (libraries explicitly declared by the project) included?
• Are transitive dependencies (libraries that the direct dependencies use internally) included?
• Did you complete the build (or package installation) before generating the SBOM? (e.g., npm install, mvn package, pip install)
• Is the number of components reasonable? (If a project with only a few direct dependencies has fewer than 10 total components, transitive dependencies have likely been omitted)

Dependency count guideline: A typical web application, including transitive dependencies, contains dozens to hundreds of components. If the component count in your SBOM is significantly lower than expected, treat it with suspicion.

4. Identifier (PURL) Check

SK Telecom’s system maps vulnerabilities by PURL. This is the most important item.

• Does every component (components) object contain a purl field?
• Does the number of components with a PURL match (or come close to) the total component count?
• Does the PURL format follow the standard (pkg:type/namespace/name@version)?
• Are special characters within the PURL correctly encoded?

Use the commands below to check the PURL count directly. The total component count and the PURL-bearing count should be equal.

# CycloneDX — the two values should be equal
jq '.components | length' sbom.json                      # total component count
jq '[.components[] | select(.purl)] | length' sbom.json  # count with a PURL

# SPDX — number of packages that have a PURL (externalRef)
jq '[.packages[] | select(.externalRefs[]?.referenceType == "purl")] | length' sbom.json

If the PURL-bearing count is 0 or significantly lower than the total component count, do not submit. This usually happens when you scan an installation directory or raw files that have no package manager metadata. Change the scan target to a built image or a location with a package manager context, or switch tools and regenerate. For details, see How to Generate an SBOM.

Online Validation Tool

• CycloneDX Validator: https://cyclonedx.github.io/cyclonedx-web-tool/validate

Related Documents

• Submission Requirements: Detailed guidance on required data fields and PURL format
• Submission Process: How to submit after passing the checklist
• SKT SBOM Generator: A tool that generates an SBOM meeting the checklist items

4.3.5 - SBOM Submission Process

1. When to Submit

• At initial delivery after concluding a software contract
• When a major or minor version of the software is updated
• When a regular submission schedule specified in the contract arrives

2. How to Submit

The SBOM file is submitted to SK Telecom’s business unit and security team representatives via email or a designated system.

Submission Method

• Deliver the SBOM file to the business unit and security team representatives via email or a channel designated by the representative.
• Email subject: [SBOM Submission] SupplierName_ProjectName_Version
• Attachment: The generated SBOM file (password-protected archive files are not allowed)

Required information in the body:

1. Delivery contract number
2. Representative information (name, department, contact)
3. Project information (system name, detailed version)
4. Tool used (e.g., SKT SBOM Generator v1.0)

TOSCA Registration Obligation of the Business Unit Representative

The SK Telecom business unit representative who receives an SBOM from a supplier must register that SBOM in TOSCA, the internal open source and SBOM management system.

TOSCA (SK Telecom Open Source & SBOM Management System) https://tosca.sktelecom.com

• TOSCA is an SK Telecom internal system, accessible only to company employees.
• [For SKT Members] Supplier SBOM registration and report output guide: https://confluence.tde.sktelecom.com/x/bYNULw

3. Post-Submission Validation and Actions

After being registered in TOSCA, the submitted SBOM is validated according to the procedure below.

The validation results and action requests are communicated to the supplier and the security team representative through the business unit representative.

Related Documents

• Validation Checklist: Essential items to verify before submission
• Submission Requirements: SBOM format and required data fields
• Supplier Guide Home: View the full process flow

5 - Open Source Education Slides

Open source education material for enterprise developers.
It covers license compliance, contributing to and releasing open source, and SBOM and software supply chain security.

View in full screen

Slide Structure

Slide source (Marp Markdown): slides/oss-education.md