Releasing Open Source
Releasing SK Telecom software as 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
- Decide whether the project is worth releasing (see Benefits of Releasing).
- Get internal approval and request a review (stage A of the Release Process).
- Prepare your code following the SK Telecom Release Rules (stage B).
- Set up the project (stage C), then release and operate it (stage D).
Decision Flow
| Question | Next step |
|---|
| Is this code, used in a real product or service, worth releasing? | If so, start preparing for release |
| Do you have the right to release it (check third-party code, patents, sensitive info)? | If unclear, request a review first |
| Do you have the people and resources to support it after release? | If not, plan for them first |
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)
1 - SK Telecom Open Source Release Rules
The rules to follow when releasing software as open source.
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.
2 - SK Telecom Open Source Release Process
How to get a release approved, prepare it, and publish it.
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.
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
2.1 - Copyright and License Notices in Files
How to add copyright and license notices to source 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.
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
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 {} \;
2.2 - Deciding the Open Source Project Name
Choosing a name for your open source project
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.
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).
T-legalnet
If you need a more detailed check regarding trademarks, get a review from the IPR team through T-legalnet.
2.3 - Code Scrubbing Checklist
Removing sensitive information and secrets before release.
Before releasing, remove sensitive information from the code and the commit history. Check the items below.
Checklist
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" .
2.4 - License Selection
How to choose an open source license for the project you release.
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
3 - Background on Open Source Release
Background to help you understand open source release.
This section is learning material that answers “why.” It is kept separate from the action pages (Release Rules, Release Process).
Pages
3.1 - Benefits of Releasing Open Source
What benefits do you gain by 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.