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: SK Telecom Open Source Contribution Rules
• 2.2: SK Telecom Open Source Contribution Process
• 2.3: Submitting Contributions
• 2.4: Background on Open Source Contribution
• 2.4.1: Benefits of Open Source Contribution
• 2.4.2: Types of Open Source Contribution
• 2.4.3: Open Source Project Membership
• 2.4.4: Key Documents in an Open Source Project
• 2.4.5: How to Become a Good Contributor
• 2.4.6: How to Identify a Good Project to Contribute To
• 2.4.7: How to Communicate
• 3: Releasing Open Source
• 3.1: SK Telecom Open Source Release Rules
• 3.2: SK Telecom Open Source Release Process
• 3.2.1: Copyright and License Notices in Files
• 3.2.2: Deciding the Open Source Project Name
• 3.2.3: Code Scrubbing Checklist
• 3.2.4: License Selection
• 3.3: Background on Open Source Release
• 3.3.1: Benefits of Releasing Open Source
• 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: BomLens
• 4.3.3: Generating an SBOM with Open Source Tools
• 4.3.4: Generating a Server (OS + Application) SBOM
• 4.3.5: Pre-Submission SBOM Validation Checklist
• 4.3.6: 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

Avoid versions of open source that have known, unpatched vulnerabilities. Versions in which security vulnerabilities have been found are tracked in databases such as CVE. Check whether the version you intend to use has known vulnerabilities, and if so, use a patched, newer version.

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: Tools such as Trivy can be exposed to supply chain attacks through release tag tampering. When installing the CLI, use the official release channels, and in GitHub Actions, use a verified pinned version or a commit SHA instead of mutable tags (@latest, @master, etc.). For reported cases and safe usage, refer to the SBOM Generation Guide.

For automated SBOM generation, refer to the SBOM Generation Guide.

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 OSRB 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 OSRB 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, OSRB 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

Here, “Compatible” means the files can be combined or distributed together while the MPL files keep their source-disclosure obligation. It does not mean MPL is a permissive license.

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 project. Contributing benefits not only individuals but the company as well.

This page is the starting point. Before you begin, use it to decide what you need to do.

Summary

1. First, check whether your contribution needs approval (see the decision flow below).
2. If approval is needed, get internal approval from your organization and then request a review (Contribution Process).
3. Prepare your code following the SK Telecom Contribution Rules.
4. Submit your contribution in the way the project requires.

Decision Flow

Find where your contribution fits and choose the process accordingly.

When You Can Contribute Without Approval

The following carry little risk of copyright infringement, so members may contribute at their own discretion.

• Small code snippets of 10 lines or fewer
• Questions and answers on Stack Overflow
• Management activities on GitHub (creating issues, reviewing and approving Pull Requests, etc.)

The Full Process at a Glance

• Contribution Rules: the rules to follow when contributing
• Contribution Process: how to get approval and proceed
• Submitting Contributions: how to submit a contribution to a project
• Background: learning material to understand contribution

Inquiries

For inquiries or requests regarding open source contribution, contact OSRB: Support (opensource@sktelecom.com)

2.1 - SK Telecom Open Source Contribution Rules

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

Obtain Approval

From a copyright perspective, an open source contribution grants the 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 project. Generally, the copyright of works created during employment is owned by the employer, so works created by SK Telecom members are owned by SK Telecom. Contributing at your own discretion can create unnecessary copyright-infringement issues.

Therefore, if there is a project you want to contribute to, follow the review request and approval steps in the Contribution Process before your first contribution.

Contribute Only Code You Have the Right to Contribute

Contribute only code you wrote yourself. Do not contribute third-party code at your own discretion.

Be Careful About Disclosing Intellectual Property

Do not contribute code or documents that risk disclosing the company’s intellectual property, such as sensitive information or patents. If the code contains a company patent, confirm whether the patent may be contributed under the project’s open source license. If anything is unclear, contact OSRB.

Note that when you contribute under a license with an explicit patent grant, such as Apache-2.0 or GPL-3.0, you may also grant a license to the company patents needed to implement the contributed code. If patents are involved, request an OSRB review before contributing.

Do Not Contribute Substandard Code

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

Be Careful When Signing a CLA

Some projects require all contributors to sign a CLA (Contributor License Agreement). This agreement reduces copyright disputes that may arise as a project manages works from many contributors. Projects led by large companies typically require one.

CLAs differ from project to project, but they mainly ask you to agree to the following.

• I (or my company) have the right to contribute this contribution (that is, I am its author).
• 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.
• I (or my company) grant the project and its users a license to any patents embodied in the contribution.

In rare cases, some CLAs also require agreement to the following.

• I (or my company) assign my copyright to the project or its managing organization upon contributing.

To protect its intellectual property, SK Telecom does not permit contributions to projects that require copyright assignment. Therefore, if a project requires a CLA, request an OSRB review before signing. Most CLAs are fine to sign, so approval does not take long.

Many projects require a DCO (Developer Certificate of Origin) instead of a CLA. A DCO does not assign or separately grant copyright or patent rights; it certifies, through a Signed-off-by line in the commit, that the contribution is yours and that you have the right to contribute it. See Submitting Contributions for how to sign off.

Indicate Copyright

The intellectual property of works a member creates during employment is, by default, owned by the company. So when contributing code to an external project, indicate SK Telecom’s copyright. When contributing one or more files, add the copyright and license at the top of the file as follows.

SPDX-FileCopyrightText: Copyright {year} SK TELECOM CO., LTD.
SPDX-License-Identifier: {SPDX_license_id}

• Use the file’s creation year for {year}.
• Set {SPDX_license_id} according to the project’s license policy.
• If you are only modifying existing code (for example, a bug fix), you do not need to add a copyright notice for that change.

This notation follows the REUSE standard and matches the format used in Copyright and License Notice.

Use Your Company Email

When contributing, use your SK Telecom email rather than a personal one. This gives members a sense of responsibility for representing the company in the community, and it improves SK Telecom’s recognition as an active open source contributor.

2.2 - SK Telecom Open Source Contribution Process

In accordance with the SK Telecom Contribution Rules, members follow the process below when contributing to external open source projects. If your contribution falls under the cases that need no approval (see the overview decision flow), you may skip this process.

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 a Review

After internal approval, request a review from OSRB (opensource@sktelecom.com). Filling in the checklist below speeds up the review.

Submission Checklist

• Open source project name
• Repository URL
• Project license
• Purpose of the contribution
• Summary of the contribution
• Internal approval status
• Whether the project requires a CLA or DCO

GitHub Issue Template

Accepting requests through an internal issue tracker or GitHub organization with the template below lets contributors provide everything just by filling in the blanks.

### Open Source Contribution Review Request

- Project name:
- Repository:
- License:
- Purpose:
- Summary of contribution:
- Internal approval (executive/leader):
- CLA/DCO required:

Expected Turnaround

The review covers the license and any CLA. Simple checks finish quickly; cases that need further review take longer.

OSRB reviews the project’s license and CLA and approves the request if there are no issues.

3. Scope After Approval

Once a project is approved, members may contribute to it at their own discretion thereafter. Request a new review when contributing to a different project.

4. Review the Project’s Contribution Documents

The required process differs slightly between projects. Before contributing, check the project’s CONTRIBUTING or README to understand the following.

• Guidelines on coding style, language, formatting, issue/ticket management, release timing, and so on
• Whether a CLA signature or a DCO Signed-off-by is required
• How patches are submitted (GitHub Pull Request or mailing list)

5. Submit Your Contribution

After improving your code per the Contribution Rules, submit it in the way the project requires.

2.3 - Submitting Contributions

Once you have approval and your code is ready, submit your contribution in the way the project requires. The following is the typical flow for a GitHub-based project.

Check Prior History

Check whether your contribution has been addressed before. Search the project’s README, issues, and mailing list for a few keywords. If you find nothing related, open an issue or start a conversation through a Pull Request.

Before you start, it is best to open an issue describing what you intend to do. This helps you avoid duplicate or unnecessary work.

Create an Issue

Typically, create an issue when:

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

Communication tips:

• If an open issue already covers your topic, comment first so others do not work on it in parallel.
• An old issue may already be resolved; check with a comment before starting.
• If you opened an issue and later found the answer yourself, post the answer and close it. That documentation is itself a contribution.

Create a Pull Request

When your files are ready, submit the contribution as a Pull Request. Opening it early to get feedback is good practice; mark “WIP” (Work in Progress) in the title and add more commits later.

The Pull Request flow on GitHub is as follows.

Fork

Fork the upstream repository to your own GitHub account.

Clone

Clone your fork to a local working directory and add the upstream as a remote.

$ git clone https://github.com/$user/[repository]
$ cd [repository]
$ git remote add upstream https://github.com/[upstream]/[repository]
$ git remote -v

Create a branch

Bring the main branch up to date, then create a working branch.

$ git fetch upstream
$ git checkout main
$ git rebase upstream/main
$ git checkout -b myfeature

Work and commit

Make your changes and commit. If the project requires a DCO, add a Signed-off-by line with -s.

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

Push

Push your branch to your own repository.

$ git push origin myfeature

Use the force option only in the rare case where you must re-push a branch you rewrote (for example, after a rebase), and never on a shared branch.

Create a pull request

On GitHub, use the Compare & pull request button on your repository to create the Pull Request. The upstream maintainer then reviews it and decides whether to merge.

DCO and CLA

Projects certify the origin of contributions with a DCO or a CLA. Check which one the project requires beforehand.

• A DCO is a lightweight Signed-off-by line in the commit, added automatically with git commit -s.
• A CLA is a separate agreement. If a CLA requires copyright assignment, request an OSRB review before signing, per the Contribution Rules.

Receive Feedback

After you submit, the project gives feedback. Treat it as a way to raise the quality of your contribution. Feedback usually falls into one of four kinds.

No response

Before contributing, check that the project is active. If you get no response for more than a week, politely ask for a review in the same thread, using an @-mention if you know the right person. Do not contact anyone privately; keep communication public. If there is still no response, look for another way to contribute or another project.

A request for changes

Being asked to explain your idea or revise your code is common. Respond promptly, since someone took time to review. If you can no longer proceed, tell the maintainer so someone else can take it over.

Rejected

A contribution may not be accepted. If the reason is unclear, ask the maintainer for an explanation, but respect their decision. If differences are never reconciled, you can fork and continue on your own project. Treat a rejection as a chance to improve your next contribution.

Accepted

Congratulations. You have contributed to open source.

References

• Make a Pull Request
• First Contributions
• Kubernetes GitHub Workflow

2.4 - Background on Open Source Contribution

This section is learning material that answers “why.” It is kept separate from the action pages (Contribution Rules, Contribution Process, Submitting Contributions).

Pages

• Benefits of Open Source Contribution: what contribution gives individuals and the company
• Types of Open Source Contribution: what kinds of contribution exist
• Open Source Project Membership: who is in an open source project
• Key Documents in an Open Source Project: what documents a project has
• How to Become a Good Contributor: how to become a good contributor
• How to Identify a Good Project: which projects are worth contributing to
• How to Communicate: how to communicate in the community

2.4.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.4.2 - 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.3 - 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.4 - 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.5 - 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.6 - 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.7 - 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 the open source community but also actively supports releasing its own software as open source to collaborate with the community. This guide helps you capture the benefits of open source collaboration without creating legal, ethical, or technical problems.

This page is the starting point. Before you begin, use it to decide whether to release and what you will need.

Summary

1. Decide whether the project is worth releasing (see Benefits of Releasing).
2. Get internal approval and request a review (stage A of the Release Process).
3. Prepare your code following the SK Telecom Release Rules (stage B).
4. Set up the project (stage C), then release and operate it (stage D).

Decision Flow

The Full Process at a Glance

The Release Process runs in four stages.

• A. Release Approval
• B. Release Preparation
• C. Project Setup
• D. Release and Operation

Inquiries

For inquiries or requests regarding open source release, contact OSRB: Support (opensource@sktelecom.com)

3.1 - SK Telecom Open Source Release Rules

SK Telecom encourages releasing internal software as open source. However, there are several rules to follow in order to protect its intellectual property and to prevent unintentional copyright infringement.

Obtain Approval

The copyright of works created during employment is owned by the employer. Releasing at your own discretion can create copyright-infringement issues, so follow the review request and approval steps in the Release Process.

Release Only Code You Have the Right to Release

You cannot release code you did not write. Verify the origin of all code and remove anything that could create legal problems.

Be Careful About Disclosing Intellectual Property

Do not release code or documents that would disclose the company’s intellectual property, such as sensitive information or patents.

Do Not Release Substandard Code

Code must be readable and mature enough. Substandard code erodes the community’s trust.

Release Useful Code

Release code that is actually used in a product or service. If the code addresses a problem the community has already solved, it is better to contribute to an existing project than to release something new.

Secure Resources

Releasing and operating a project requires initial developers, developers to review external contributions, legal and marketing support, and infrastructure budget. Plan for these before releasing.

Use Your Company Email

Communicate with the community using your SK Telecom email rather than a personal one.

3.2 - SK Telecom Open Source Release Process

The release process runs in four stages: get approval (A), prepare the code (B), set up the project (C), then release and operate it (D).

A. Release Approval

Internal Approval Within Your Organization

To release software, obtain approval from the responsible executive or leader of your organization.

Request a Review

After internal approval, request a review from OSRB (opensource@sktelecom.com). Fill in the checklist below.

• Link to the current source repository
• Link to the planned public repository
• Open source license to apply
• Expected business value of releasing
• Description of code not written by SK Telecom members
• Development team executive approval
• Product or service the code is used in
• Whether support staff are assigned after release
• Whether the release is ready
• Promotion plan (blog, conference, etc.)
• Related patents
• Security vulnerability review and remediation
• Export control classification (ECCN) check

Expected turnaround depends on the review scope.

B. Release Preparation

Decide the License

SK Telecom applies Apache-2.0 by default. A different license may apply, for example when the ecosystem favors a specific license or when there is a dependency on a GPL library. See License Selection for the criteria.

Separate Third-Party Code

Confirm SK Telecom has the right to redistribute, and move external libraries into a third_party directory with a LICENSE file in each.

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

Copyright and License Notices

Add copyright and license notices to every source file, following the REUSE standard. See Copyright and License Notice. Include a LICENSE file in the project root: use the official copy for Apache-2.0, and obtain others from the SPDX License List.

Code Scrubbing

Before releasing, remove author names and emails from comments, internal information (file paths, hosts, IPs), and secrets such as credentials. See the Code Scrubbing Checklist for the items and automation.

License and Security Review Request

Check for licenses with notice or source-disclosure obligations, third-party code you have no right to redistribute, and license conflicts. Also confirm whether any vulnerable open source is included. Request the review from OSRB.

Export Control Classification (ECCN)

Because controlled technology such as cryptography may be included, check the export control classification before releasing. For a Korean company, the Foreign Trade Act strategic-item determination is the primary basis; if U.S.-origin technology is included, also check the ECCN under the U.S. Export Administration Regulations (EAR). If classification or review is needed, have the responsible department confirm it through OSRB.

C. Project Setup

Decide the Name

Choose a memorable name that conveys the project. See Naming the Project for the criteria, including trademark checks.

Repository and Infrastructure

A GitHub or GitLab repository is recommended. Request membership in the SK Telecom GitHub organization (https://github.com/sktelecom) through OSRB. Provide the following.

• Issue tracker
• Test automation: unit, integration, and end-to-end tests
• CI/CD: continuous build, deployment, and monitoring
• Website: for user guides and promotion (GitHub Pages recommended)
• Communication channels: do not discuss company confidential information in public channels

Governance and CODE_OF_CONDUCT

Clearly define member roles. Add a CODE_OF_CONDUCT defining participant conduct, including non-discrimination, a safe environment, and how to report violations. Adopt the de facto standard Contributor Covenant, and set the reporting contact and enforcement procedure.

Contributor Licensing Policy (CLA/DCO)

If you plan to accept external contributions, decide the contributor licensing policy. Adopt either a CLA (Contributor License Agreement) or a DCO (Developer Certificate of Origin) to clarify copyright and license rights. A DCO is a lightweight Signed-off-by certification; a CLA is a separate agreement. CLAs that require copyright assignment are restricted by company policy, so keep this consistent with the CLA section of the Contribution Rules.

Vulnerability Reporting (SECURITY.md)

A public project receives vulnerability reports from outside. Define the reporting path and response procedure in SECURITY.md.

# Security Policy

## Reporting a Vulnerability
Do not open a public issue. Report privately to <security contact>.
We will respond within <response time>.

## Supported Versions
List the version ranges that receive security fixes.

Enable GitHub Private Vulnerability Reporting as the intake channel. Set the response time, the principle of coordinated disclosure, and the procedure for CVE assignment and security advisories.

Documentation

Provide the following.

• README: what the project does, why it is useful, how to start, where to get help
• Development guide: how to build, test, coding conventions, CI/CD, release
• CONTRIBUTING: how to report bugs and propose features, dev setup, desired contributions, vision and roadmap, maintainer contact

D. Release and Operation

Final Checks Before Release

• Confirm all code and documents are in the repository
• Confirm the infrastructure is running, secure, and scalable
• Confirm developers can join the communication channels

Release

Release publicly at https://github.com/sktelecom.

Releasing is hard to reverse. Once public, code can be copied and kept by others, so confirm that all pre-release checks are complete.

Marketing and Community

Announce on relevant community mailing lists and forums, and promote through the tech blog, social media, and conferences. A project’s success is gauged by participation and contributions, and building a community takes ongoing effort.

Lifecycle Operation After Release

Releasing is not the end. Keep up the following.

• Regular health checks: respond to issues and PRs, maintain a release cadence
• Ongoing security and bug fixes: address reported vulnerabilities
• End of life (EOL): when no longer maintained, state the status clearly and archive the repository

3.2.1 - Copyright and License Notices in Files

Copyright arises automatically when a work is created. To let others use it, you must grant a license. Because most open source licenses require a copyright notice, include a copyright notice and license identifier in every source file SK Telecom releases. The notation follows the REUSE standard.

Copyright Notice

Add the following to the top of each source file.

SPDX-FileCopyrightText: Copyright {year} SK TELECOM CO., LTD.

• Use the first year of authorship for {year}.
• A contact or website is optional. This format matches the copyright notation in the Contribution Rules.

License Identifier

Find the identifier in the SPDX License List and add it at the top of the file.

SPDX-License-Identifier: Apache-2.0

Automation Tools

For many files, apply notices in bulk. To generate REUSE-standard SPDX tags (SPDX-FileCopyrightText, SPDX-License-Identifier), use reuse annotate from the REUSE tools.

$ reuse annotate --copyright "SK TELECOM CO., LTD." --license Apache-2.0 [filename]

addlicense inserts a license header by default; use the -s option for the SPDX short form.

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

Example for applying to Java files in bulk:

$ find . -type f -name \*.java -exec addlicense -s -c "SK TELECOM CO., LTD." -l apache {} \;

3.2.2 - 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.2.3 - Code Scrubbing Checklist

Before releasing, remove sensitive information from the code and the commit history. Check the items below.

Checklist

• Remove author names and emails from comments
• Remove internal information: file paths, hostnames, IP addresses
• Remove secrets: passwords, tokens, API keys, certificates
• Remove internal URLs and references to internal systems
• Run an automated secret scan
• Remove sensitive information left in the commit history

Secret Scanning

Manual review misses things. Run an automated secret scanner such as gitleaks, and include it in the pre-release pipeline where possible.

$ gitleaks detect --source . --redact

Cleaning the Commit History

If a secret was ever committed, deleting it from the current file does not remove it from history. Remove it from history with git filter-repo.

$ git filter-repo --invert-paths --path secrets.env

Rewriting history changes every commit hash and affects existing clones and shared history, so do it only in a fresh repository prepared for release.

Search Examples

To quickly scan for leftover keywords:

$ grep -rIn -e "password" -e "token" -e "BEGIN PRIVATE KEY" .

3.2.4 - License Selection

Default: Apache-2.0

SK Telecom applies Apache-2.0 by default. As a permissive license with a patent grant, it suits projects a company releases.

When to Consider Another License

• The ecosystem favors a specific license. Following community convention eases adoption.
• There is a dependency on a copyleft library such as GPL. You may have to follow the dependency’s obligations.

Permissive vs. Copyleft

• Permissive licenses (Apache-2.0, MIT, BSD) require little more than attribution and do not force a license on derivative works.
• Copyleft licenses (GPL, LGPL, MPL) can require derivative or combined works to be released under the same terms. The scope of the obligation varies by license.

Check Dependency Compatibility

Make sure the chosen license does not conflict with the licenses of your dependencies. For example, a strong copyleft dependency can make a permissive release impossible. For per-license obligations, see the license obligations section under “Using,” and request an OSRB review if the decision is unclear.

References

• choosealicense.com
• SPDX License List

3.3 - Background on Open Source Release

This section is learning material that answers “why.” It is kept separate from the action pages (Release Rules, Release Process).

Pages

• Benefits of Releasing Open Source: what releasing gives the company

3.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.

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

• Push toward SBOM requirements: EO 14028 directed defining the minimum elements of an SBOM and secure software development practices; the SBOM submission and self-attestation requirements for federal suppliers were detailed in subsequent OMB guidance.
• 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, which is, in principle, at least five years. If the expected use period is shorter than five years, the support period matches it (Regulation (EU) 2024/2847, Article 13 and Recital 60). In other words, five years is a baseline, not a cap.
• Vulnerability reporting obligation: On becoming aware of an actively exploited vulnerability or a severe security incident, the manufacturer must submit an early warning to the coordinating CSIRT and ENISA within 24 hours, followed within 72 hours by a notification and, later, a final report (Regulation (EU) 2024/2847, Article 14).
• 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, but standardized as ECMA-424 by Ecma International
• 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
• Servers: A system combining an OS (rootfs and installed packages) with an application and statically linked libraries

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 BomLens]
    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. BomLens: 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. Server SBOM: Explains how to generate the OS, application, and static-link layers separately and merge them into one.
5. Validation Checklist: Provides a checklist of essential items to verify before submission.
6. 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
• BomLens: 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 - BomLens

BomLens

BomLens 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

BomLens 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 no command line quick start.

• Executable: Download SBOM-Generator-*.exe (the BomLens executable) 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 CLI reference.

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 BomLens first.

Tool Selection Guide

graph TD
    A[Identify analysis target] --> S{A server combining an OS and an app?}
    S -- Yes --> T[Generate per layer<br>see the Server SBOM guide]
    S -- No --> 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]

A server that combines an OS and an application is not done in one scan. For the full per-layer procedure, see Server SBOM.

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.

cdxgen statically parses lockfiles and manifests. For accurate results, run it when dependencies are installed or resolved (a lockfile is present, or after a build). Scanning pure source without resolved dependencies may omit some components or purls.

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

A server that delivers an application on top of an OS (such as CentOS) is generated as two layers — OS (rootfs/image) and application — with statically linked libraries covered separately, then merged. As the warning above notes, the OS layer must target a rootfs or image that has a package database. For the full procedure, see Server SBOM.

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

• Server SBOM: How to generate and merge the layers of a server that combines an OS, an application, and static-link libraries
• Submission Requirements: The required data fields that must be included in the SBOM
• Validation Checklist: Items to verify before submission
• BomLens: SK Telecom’s SBOM generation tool

4.3.4 - Generating a Server (OS + Application) SBOM

A delivered server is not a single source tree. It is an operating system, the application installed on top of it, and libraries statically linked into the binaries during the build. Scanning only one of these misses the others, which is a common reason a server SBOM is rejected.

Treat the server as two layers — the OS and the application — generate each separately, then merge them. Both are produced with BomLens; only the input changes. Statically linked libraries, which neither layer’s scan catches, are handled separately as a blind spot.

The two layers of a server

Beyond the two layers, statically linked libraries (for example an openssl or liblfds built into the binary) are a blind spot: a package manager does not declare them and the OS package database does not list them, so neither layer’s scan finds them. They must be detected and recorded separately, and missing them is the most common rejection cause.

Generating each layer

The commands below use BomLens’s scan-sbom.sh script. For installing BomLens and its basics (downloading the script, the options, the web UI, and so on), see BomLens first. To use cdxgen/Syft directly, see Using Open Source Tools.

OS layer

Scan the server’s rootfs (the extracted root filesystem) or a container image of it. The package database (rpm/dpkg/apk) is read so every installed package gets a real purl (pkg:rpm/...).

# Target a rootfs directory
scan-sbom.sh --project myserver-os --version 7 --target /path/to/server-rootfs --all --generate-only

# Or, if the server is packaged as a container image
scan-sbom.sh --project myserver-os --version 7 --target myserver:7 --all --generate-only

The target must contain the package database. A folder holding only unpacked install files, with no rpm database, yields empty purls and is rejected.

Application layer

Scan the application source after the build. With a package manager (Maven, npm, pip, Go modules, Conan, and others), transitive dependencies resolve automatically.

cd /path/to/app-source
scan-sbom.sh --project myserver-app --version 2.0.0 --all --generate-only

A pure CMake/Make application with no manifest produces a sparse component list; add --deep-license to record the first-party source licenses.

Static-link libraries (a blind spot)

Source scanners do not see libraries statically linked into a binary, and the OS package database does not list them either — the blind spot the two layers leave. There is no fully automatic path, so combine two approaches. Analyze the delivered binary for what tooling can find, and for what it still misses, record the source and version by hand from the build script (for example openssl 1.1.1za).

scan-sbom.sh --project myserver-bin --version 2.0.0 --target /path/to/delivered-binary --all --generate-only

A precise inventory of statically linked components comes from binary composition analysis (BDBA), which SK Telecom runs as a complementary check.

Merge into one BOM for submission

SK Telecom’s submission system registers one SBOM per product. Merge the per-layer SBOMs with --merge into a single BOM and stamp the top-level component with the delivered product name and version. --merge dedupes by purl, so a library appearing in more than one layer is counted once.

scan-sbom.sh --project myserver --version 1.0.0 \
  --merge myserver-os_7_bom.json myserver-app_2.0.0_bom.json myserver-bin_2.0.0_bom.json \
  --generate-only

If the whole server is delivered as a single container image, you can scan that image with --target to capture the OS and application layers together.

Verify before submitting

Check that components carry real purls in both the per-layer SBOMs and the merged one. The total component count and the PURL-bearing count should be close.

jq '.components | length' myserver_1.0.0_bom.json
jq '[.components[] | select(.purl)] | length' myserver_1.0.0_bom.json

A large gap means many components lack a purl, usually from a raw-directory scan. For the full check, follow the Validation Checklist.

Learn more

The detailed procedure and examples for server delivery live in the canonical BomLens documentation.

Server delivery guide

Related Documents

• BomLens: SK Telecom’s SBOM generation tool
• Using Open Source Tools: using cdxgen/Syft directly
• Submission Requirements: required data fields
• Validation Checklist: items to verify before submission

4.3.5 - 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
• BomLens: A tool that generates an SBOM meeting the checklist items

4.3.6 - 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., BomLens 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