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.
2 - SK Telecom Open Source Release Rules
Describes SK Telecom’s open source release rules.
SK Telecom respects the value of collaboration with open source communities and encourages releasing internal software as open source projects. However, there are several rules that must be observed in order to protect SK Telecom’s intellectual property and to prevent unintended copyright infringement.
Obtain Approval
From a copyright perspective, an open source release is the granting, through an open source license, of the right for anyone to modify/use/distribute the author’s work. Generally, the copyright of a work created during employment is owned by the employer. That is, a work created by an SK Telecom member is owned by SK Telecom. If a member releases a work as open source arbitrarily, it can cause unnecessary copyright infringement issues.
Therefore, if you want to release software as open source, follow the review request and approval process in accordance with SK Telecom’s open source release policy. Open Source Release Process
If anything seems undesirable during the release process, do not hesitate to contact the OSPO.
Release Only Code You Have the Right to Release
You do not have the right to release code that you did not write.
One of the worst situations that can occur in an open source project is the inclusion of legally problematic code in the project. Code that the company does not have the right to distribute, or code that infringes IP such as another company’s patents, can cause legal problems. Therefore, when preparing the code to be released, verify the origin of all code and remove any code that could be problematic.
Be Careful About Exposing Intellectual Property
Do not release code or documents that raise concerns about exposing the company’s intellectual property, such as sensitive information or patents.
If the code you want to release contains a company patent, verify whether it is acceptable to release that patent under an open source license. If anything is ambiguous, contact the OSPO.
Do Not Release Substandard Code
The readability and maturity of code serve as a measure of whether it is ready to be released as open source. Immature code causes the project to lose the community’s trust.
That said, the code does not have to be perfect. If you try to prepare the code to be perfect, you may never be able to start at all. Prepare it to the best level possible in the given environment and release it. Once the community becomes active, external contributors will participate in improving the code.
Release Useful Code
To become a successful project, it must also be useful to others. If a similar project already exists, it is better to participate in the existing project than to create a new one. Even if it is a project driven by a competitor, collaboration is important in open source. By participating and collaborating together, everyone can have excellent code.
You should not assume that the community will manage code unconditionally just because you release it, even if it is no longer useful. The open source community is not an organization that manages old code on your behalf. In fact, if a company repeatedly releases unattractive code, it will lose trust in the open source world, and later, even if it releases other code as open source, developers will pay no attention.
You should be able to expect that the open source you release will be a project that (1) provides differentiated value to the open source community, (2) solves problems the community has not been able to solve, and (3) can attract positive attention by showcasing our technical capabilities.
- If it is code that you were unable to use in an actual product or service, it is best not to release it as open source either. If you cannot persuade people to use it even in our own products, it is not easy to persuade others to use it.
- Do not release code that addresses a problem the open source community has already solved. In such a case, it is better to contribute to an existing open source project.
If you determine that the code you want to release can be useful externally as well, continue with the release process.
Secure Resources
You must secure the resources, including developers, that need to be allocated to the project.
- In the early stages, you need developers at a level similar to a typical in-house project.
- You also need developers who can quickly review external contributions.
- In addition, the roles of the legal and marketing teams are needed.
- You must also secure a budget for the infrastructure required to maintain and manage the project. This includes tools for project hosting such as GitHub.
If you cannot create an environment with sufficient resources, it is best not to release the project as open source.
Use Your Company Email
When engaging in open source release activities, do not use a personal email; use your SK Telecom email. Through this, (1) members gain a sense of responsibility that they are communicating with the community on behalf of the company, and (2) SK Telecom can improve its recognition as a company that actively engages in open source community release activities.
For how to set up your email on GitHub, refer to the following Link.
3 - SK Telecom Open Source Release Process
Describes SK Telecom’s open source release process.
1. Internal Approval from Your Organization
To release software as open source, obtain approval from the executive or leader in charge of your organization.
2. Request OSPO Support
After deciding to release open source and obtaining approval from your organization, request support from the OSPO: Support (opensource@sktelecom.com)
The OSPO explains the open source release rules and process based mainly on the contents of this guide and provides the support you need.
3. Key Decisions
Deciding the Project Name
It is best to choose a name that sounds good, is easy to remember, and conveys what the project is. Avoid names that could cause problems. For details, refer to the following page.
Deciding the License
To release software as open source, you must grant a license. Only then can others use, copy, modify, and distribute the software. A license also protects contributors from legal issues. Therefore, when starting an open source project, you must choose an appropriate open source license and apply it to the project.
By default, SK Telecom applies Apache-2.0 when releasing software as open source. Apache-2.0 provides users with broad freedom while also being a well-drafted license from a legal standpoint, including an explicit patent grant clause.
However, in exceptional cases such as the following, a license other than Apache-2.0 may be applied.
Some communities have a designated license that they primarily use. For example, the Node.JS project uses the MIT license. In such cases, you can apply that license.
Some projects have a dependency on a library under the GPL license and therefore must be released under the GPL. In such cases, you can apply the GPL.
For reference, GitHub provides a guide on choosing a license when releasing open source: https://choosealicense.com
Inquiry
If you find yourself in a situation where you need to choose a license other than these, contact the OSPO (Open Source Program Office): Support (opensource@sktelecom.com)
Deciding on a CLA
While operating a project released as open source, a situation may arise in which, for whatever reason, the existing open source license must be changed to a different license. In such a case, even the project Leader cannot change the license arbitrarily; it is only possible with the consent of all copyright holders who contributed works to the project. For a project that has received contributions from many contributors over a long period, obtaining consent from all copyright holders is in practice nearly impossible, and therefore changing the open source license is also impossible.
To reduce such disputes that can arise while managing the works of many contributors, a CLA (Contributor License Agreement) is an agreement that obtains contributors’ consent in advance, and it typically contains content seeking the contributor’s consent to the following.
- I (or the company I belong to) have the right to contribute the contribution I intend to make to the project. (That is, I am the author of this contribution.)
- I (or the company I belong to) grant the project the right to modify, distribute, and manage my contribution.
- I (or the company I belong to) will not revoke the rights granted.
- I (or the company I belong to) grant the project the right to change the license in the future as needed.
Requiring contributors to sign a CLA has the advantage of making it easier for the project to manage contributors’ works, but it has the disadvantage that contributions cannot be accepted from contributors who refuse to sign the CLA.
SK Telecom uses the attached CLA. SK Telecom template
- Whether to use a CLA for a project is decided by the releasing organization, depending on the project’s purpose and environment.
- If (1) there is no plan to change the open source license in the future, or (2) multiple companies participate and the likelihood of a copyright dispute is not high, you do not have to use a CLA.
4. Preparing and Reviewing the Code to Be Released
Before releasing code as open source, clean it up in advance—for example, by removing parts that could unnecessarily become issues.
Cleaning Up 3rd Party Code
If you need to include 3rd party code in the project—that is, if you need to include code to which SK Telecom does not hold the copyright—first verify whether SK Telecom has the right to redistribute it. If the code is already under an open source license, it can be redistributed on the condition that the license obligations are met.
In the case of 3rd party code that SK Telecom can redistribute, place it in a directory separate from the existing code (for example, third_party). This increases the transparency of the project from a licensing standpoint and allows future users to easily find the 3rd party code and comply with the exact license requirements.
Every directory within the 3rd party directory must include its own LICENSE file (a text file containing the copyright information and the full text of the license). For example, the structure of the third_party directory in a Repository is as follows.
[Root Directory]
|-- SKT source code
|-- ....
`-- third_party
`-- [external library A]
| |-- `LICENSE`
| `-- ...
`-- [external library B]
|-- `LICENSE`
`-- ...
Copyright and License Notices in Files
Include a copyright and license notice in every file that contains source code. This helps users who want to copy and use only a few files comply with the license obligations as well. For details, refer to the following page.
Make sure that the code you are about to release does not contain the company’s trade secrets or unnecessary comments that could cause problems.
- Remove the names and email addresses of SK Telecom members (which do not need to be exposed externally).
- Remove internal information (internal code file names / paths, internal host / IP information, etc.).
For reference, the commands below make it easy to find unnecessary comments.
### Search for company website, email, and IP addresses
$ egrep -r '\.sktelecom\.com|@sk\.com|@sktelecom\.com|([0-9]+\.){3}[0-9]+' <path-to-source-directory>
### Search for Java/C/C++/Go/Objective-C/Objective-C++/Swift/Kotlin comments
$ find <path-to-source-dir> -type f | egrep '\.(c|cc|h|cpp|go|java|kt|m|mm|swift)' | \
while read f; do echo "------------ $f ------------------"; sed -n -e '/\/\*.*\*\// {p; b}' \
-e '/\/\*/,/\*\//p' -e '/\/\//p' "$f"; done
### Search for Python/Bash comments
$ find <path-to-source-dir> -type f | egrep '\.(py|sh)' | while read f; \
do echo "------------ $f ------------------"; grep -o "#.*" "$f"; done
Including a License File
Include a text file named LICENSE containing a copy of the license in the top-level directory.
Open Source License Inspection
Use an open source license inspection tool to examine the source code to be released and confirm the following.
- Whether it includes other open source under a license that requires notice / source code disclosure obligations
- Whether it includes 3rd party source code that you do not have the right to release
- Whether it includes code under a license that conflicts with the open source license you will apply
Open Source Security Vulnerability Inspection
Use an open source security vulnerability inspection tool to check whether the source code to be released includes any open source with security vulnerability issues.
5. Building the Development Environment / Infrastructure
Repository / Issue Tracker
Prepare a repository for the project. Many projects use a GitHub or GitLab repository, or provide their own repository using a tool such as Gerrit. Features for bug, issue, and feature tracking should also be included as part of the infrastructure plan.
We recommend using SK Telecom’s GitHub Repository: https://github.com/sktelecom
Test Automation
Open source development has the characteristic that many people in remote locations must collaborate asynchronously. To maintain excellent quality nonetheless, test automation is essential. Provide and automate the following tests.
- Unit Test
- Integration Test
- End-to-End Test
CI/CD
Build an environment that provides continuous automation and monitoring across the entire development life cycle—not only testing but also building and deployment. Again, an automated development, build, test, and deployment environment is essential for the success and continuity of an open source project.
Website
Build a website to provide a user guide and promote the project. It can also provide information such as the project’s leadership and governance details.
GitHub Pages provides an easy way to create and host a website.
Communication Channels
It is important to provide channels that enable smooth communication within the community. You also need tools that can be integrated into the entire development work flow, such as providing notifications for code check-ins, error logs, and other tasks. These become an important means of advancing the project in real time.
One excellent tool is Slack. Slack is an online project management and communication platform that lets users share messages and files, configure work flows, search for information, and perform other tasks. However, Slack is a commercial tool and incurs maintenance costs.
Tools released as open source include IRC, Gitter.im, and Rocket.Chat. Rocket.Chat is open source and provides functionality similar to Slack.
However, you must not discuss the company’s confidential information on third-party services such as Slack. These communication channels should be used only for public discussion and not as discussion tools for internal company organizations.
6. Establishing a Governance Structure
Membership
An open source project brings together diverse people from various regions to collaborate. For effective collaboration, the roles of the participants must be clearly distinguished. To this end, decide what membership to set up.
CODE OF CONDUCT
A CODE OF CONDUCT, also called a behavior code or code of conduct, is a document that defines the rules of conduct for participants so that the project remains healthy. For example, it emphasizes that there must be no discrimination based on gender, race, religion, age, and so on, and that everyone must act to ensure that all are warmly welcomed and able to participate safely. It also explains how to report someone who breaks those rules.
The following is a CODE OF CONDUCT template that can be used in SK Telecom’s open source projects:
7. Documentation
The most important part of attracting many users and contributors to an open source project is documentation. How detailed and accurate the documentation is perceived as the quality of the project. No matter how excellent the software’s features are, if they are not faithfully expressed in documentation, users will turn away.
README File
Do you want many users to use the open source you have released? Then provide a README file so that people can easily get started. The README file is the most important document for explaining the project to newcomers.
The README should include content that can answer the following questions.
- What does this project do?
- Why is this project useful?
- How do I get started?
- Where can I get help if I need it?
The background knowledge of project users varies widely. It is best to provide detailed documentation so that even people who are just starting out and have no experience can easily understand it. Remember that the more thorough the documentation, the more users and contributors you can attract.
Development Guide
Provide a development guide for prospective contributors who are willing to participate in the project. This document includes the following.
- How to build
- Testing Guide
- Coding Convention
- CI/CD
- Release
For an example of a development guide, refer to the HANU project Developing documentation.
CONTRIBUTING File
This is a file that provides content about “How to Contribute” for contributors to refer to. If the CONTRIBUTING file is not thorough, even users who were interested in contributing to the project will lose their enthusiasm.
The CONTRIBUTING file includes the following.
- How to submit a bug report (how to create an Issue / submit a Pull Request)
- How to propose a new feature
- How to set up the development environment and run tests
In addition, you can provide guidance on what kinds of contributions you would like to receive from contributors, such as the following.
- The types of contributions you want
- The project’s vision and roadmap
- How contributors can reach the project maintainers
In the early stages of a project, the CONTRIBUTING file can be simple. However, you must explain the essential conditions for contributing, such as how to submit bug reports and raise issues, and how to run preliminary tests.
Also, provide documentation with a warm and friendly tone. Such documentation makes potential contributors feel like participating in the project. For example, the Contributing guide of a project called Active Admin begins as follows.
“First of all, thank you for considering contributing to Active Admin. It’s people like you who make Active Admin such a great tool!”
CONTRIBUTING References
- CONTRIBUTING file template: CONTRIBUTING-template.md
- CONTRIBUTING files (examples)
Like the README, the CONTRIBUTING file is placed in the top-level folder within the project Repository. And to make it easy for users to access, provide a link to it within the README file.
8. Request OSPO Review
Once you are ready to release through the procedures above, provide the following information to the OSPO and request a review. The OSPO provides support to correctly release SK Telecom’s software as open source and to grow the community: Support (opensource@sktelecom.com)
Information to Submit
- A link to the project’s Repository where the current source code can be reviewed (grant access so that OSPO members can access it)
- A link to the repository where it will be released (e.g., github.com/?)
- The open source license to be applied
- What business value can be expected from releasing this project as open source?
- Is there any code not written by SK Telecom members? If so, which files, and an explanation of why they must be included.
- Have you obtained approval for the open source release from the executive in charge of the development team?
- What products or services use this code? (If it is not used, the reason why.)
- Have personnel been assigned to provide support after the open source release?
- Has the release preparation been completed according to the guide?
- What methods will be used to announce the project release? (e.g., blog post, conference presentation)
- Are there any patents related to the code to be released?
- Have you reviewed security vulnerabilities and addressed any shortcomings?
Once you release something, it is not easy to reverse it. For that reason, review and prepare the code with as much time as possible. Of course, perfect code is not required. You should minimize mistakes so that there is nothing you regret after the release.
If there are no problems during the review, approval proceeds simply and quickly. The OSPO provides a service to encourage and help open source releases, not to block them.
After OSPO approval, proceed with releasing the project.
9. Release
After completing all preparation and review steps, finally confirm the following.
- Confirm that all code and documentation exist in the Repository to be released.
- Confirm that all project infrastructure is running, secure, and scalable.
- Confirm that developers can join and monitor the communication channels (IRC, Mailing List, etc.).
Then, launch the open source project. Following the OSPO’s guidance, publicly release the source code repository at https://github.com/sktelecom. (Depending on the development team’s needs, you may release it using a different repository.)
10. Marketing
Marketing is essential to keep a project going. Marketing includes promoting the project, establishing a successful operating strategy, providing a realistic budget and project branding, activating social media accounts, and other activities for long-term success. Here are a few methods for releasing a project and making it known.
- Announce that the project has been released on the mailing lists or forums of communities related to the project.
- Introduce the project on the SK Telecom tech blog (https://sktelecom.github.io/).
- Promote it through the project’s social media (Twitter, Facebook, LinkedIn, etc.). You may also leverage SK Telecom’s social media accounts.
- Give a topic presentation at an open source conference related to the project.
Now it is your mission to promote the project and let people know they can use it. You can judge the project’s success by how many people participate in the project, use the code, fix bugs, and report problems.
- Community building does not happen on its own. For detailed activities for community building, refer to the following page: (The community growth guide is in preparation: haksung@sk.com)
- In addition, to do this, you must be able to measure the project. For details on metrics and measurement methods, refer to the following page: (The open source measurement guide is in preparation: haksung@sk.com)
3.1 - 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.
3.2 - Copyright and License Notices in Files
Describes how to indicate copyright and license notices within files.
Copyright is created automatically when an author creates a work (since the Berne Convention). Every work is protected by copyright, and the copyright holder has exclusive rights to the work. Therefore, to allow others to use our works (source code, text, images, other media, etc.), we must grant them a license. The dictionary definition of a license is “permission obtained from a qualified authority to exercise a particular right,” and exercising such a right without that permission becomes an illegal act, such as copyright infringement.
Although a copyright notice is not required by law, it makes sense to include a copyright notice in source code files, considering that (1) most open source licenses require a copyright notice, and (2) users may want to contact the copyright holder for legal or technical reasons.
For every source code file that SK Telecom writes and releases as open source, give notice of the copyright and license in the following way.
Copyright Notice
Add a copyright notice containing the following information to the header at the top of the source code.
- Copyright (or the © symbol)
- The year first written
- The name of the copyright holder
- The copyright of a work authored by an SK Telecom member is held by SK Telecom. Therefore, write the company name. (SK TELECOM CO., LTD.)
- If you plan to actively accept external contributions rather than developing solely within SK Telecom, you can also consider indicating the copyright information as “The [Project] Authors” and managing author information in an AUTHORS file.
- Contact (Optional)
- Users may want to contact the author for technical or legal inquiries. You can provide the author’s email information to respond to this. This is not required.
- Alternatively, write contact information such as the URL of the project’s website where users can obtain information.
Indicate the copyright notice using the SPDX Tag (“SPDX-FileCopyrightText”), which is the method recommended by REUSE.software. An example is shown below.
SPDX-FileCopyrightText: Copyright 2021 SK TELECOM CO., LTD. <{$project-website-url}>
License Notice
It is also important to indicate what the license is for each source code file. To reduce confusion, indicate the license using the SPDX ID provided by the Linux Foundation’s SPDX project. Using an SPDX ID is simple.
First, check the SPDX Identifier of the open source license you want to apply on the SPDX License List page. For example, the SPDX Identifier of Apache License version 2 is Apache-2.0.
Then, at the top of the source code file, indicate the license Identifier using a tag called SPDX-License-Identifier. An example is shown below.
SPDX-License-Identifier: Apache-2.0
(The guide needs to be improved after the tools are enhanced to add the SPDX tag together: haksung@sk.com)
addlicense
- addlicense: Automatically recognizes source files and adds copyright/license notices.
addlicense -c "SK TELECOM CO., LTD." -l apache [filename]
autogen
- autogen: Automatically adds comments and code to new files.
autogen --no-code --no-tlc -c "SK TELECOM CO., LTD." -l apache [filename]
You can also apply this as a batch. The example below is a batch applied to Java files.
find . -type f -name \*.java -exec autogen -i --no-code --no-tlc -c \
"SK TELECOM CO., LTD." -l apache {} \;