Releasing Open Source

• 1: SK Telecom Open Source Release Rules
• 2: SK Telecom Open Source Release Process
• 2.1: Copyright and License Notices in Files
• 2.2: Deciding the Open Source Project Name
• 2.3: Code Scrubbing Checklist
• 2.4: License Selection
• 3: Background on Open Source Release
• 3.1: Benefits of Releasing Open Source
• 4: Releasing an AI Model
• 4.1: AI Model Pre-Release Checklist
• 4.2: Writing the Model Card
• 4.3: AI SBOM and Regulation

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.

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

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 {} \;

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

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

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 - 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.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 - Releasing an AI Model

Releasing an AI model follows most of the same steps as releasing source code. You obtain organizational approval, confirm you have the right to publish, remove sensitive information, and assign someone to support the project afterwards. For those shared steps, follow the release process and the release rules.

This page covers only what differs because the artifact is a model.

What differs from a code release

Training datasets are where teams most often get stuck. Even with the model license settled, the license of the data you trained on may restrict redistribution or commercial use. Check the two separately.

Summary

1. Obtain internal approval and request an OSRB review (stage A of the release process).
2. Confirm the license of both the model and every training dataset. Do this early — if it fails here, the rest of the preparation is wasted.
3. Work through the pre-release checklist. Alongside it, write the model card — the document your users will read first.
4. Generate an AI SBOM to check your documentation against regulation.
5. Publish the repository and operate it (stage D of the release process).

Stage D is written for source code going to GitHub. A model goes to your model development organization’s Hugging Face account rather than a personal one; everything else about operating it is the same. Ask your organization’s owner if you need access.

Checking your model before you publish

Work through the rights and data items on the pre-release checklist first. A private repository is still an upload to an outside service, and pushing weights that turn out to contain something you cannot publish is hard to undo.

After that, you can check the model yourself while the repository is still private. Push the model privately and run BomLens, the SBOM generator, with your own Hugging Face token (HF_TOKEN); it reports what is missing and how to fill it. Strengthen the model card with that result ahead of time, and the OSRB review has the documentation it needs and goes more smoothly. The command to run BomLens, how to prepare the token, and how to read the result are in AI SBOM.

Related pages

• Release process — the shared path from approval to operation
• Release rules — what to satisfy before publishing
• Sensitive information checklist — cleaning code and commit history
• AI Model Licenses — RAIL, Llama and similar licenses

Contact

For questions and review requests about releasing an AI model, contact the OSRB (opensource@sktelecom.com).

4.1 - AI Model Pre-Release Checklist

Read through this when you start writing the model card, not on the day you publish. Some items here can only be fixed by training again.

1. The right to publish

Settle this first. If it fails here, the rest of the preparation is wasted.

• If you fine-tuned a base model, does its license permit distributing derivatives?
• Have you identified what the base model license requires of derivatives (naming, license inheritance, passing on use restrictions)?
• Do the licenses of your training datasets permit distributing what was trained on them?
• If purchased or contracted data is involved, does the contract allow publication?
• Are there patent filings covering the model or the training method?

2. Choosing a license

• Have you chosen a license for the model weights?
• If the base model forces a particular license, does your choice honour it?
• If you need use restrictions, have you documented why? (RAIL-family licenses)
• If you publish the training dataset too, has it been licensed separately?
• Does the model card’s license field carry the exact identifier?

For the characteristics of each license, see AI Model Licenses, the Llama 2 guide and the RAIL guide.

3. Data and sensitive material

• Have you checked whether the training data contains personal data?
• If it does, has the privacy team reviewed it?
• Have you checked whether the training data contains third-party copyrighted works?
• Is internal documentation or customer data absent from the training set?
• Have you considered the risk of the model reproducing its training data verbatim?
• Have you prepared the public summary of training content? (EU AI Act Article 53, on the Commission’s template)
• Have you set out your copyright policy? (respecting text and data mining opt-outs, and so on)
• Are the files you are about to publish free of API keys, internal hostnames and credentials? (see the sensitive information checklist)

4. Model card

For how to write it, see Model card.

• Have you filled in all seven sections of the model card? (model description, intended use, out-of-scope use, limitations and bias, training data, evaluation, contact)
• If there is a base model, is it declared in base_model?

5. Files and identifiers

• Does the list of weight files match what you intended to publish (no stray checkpoints)?
• Do you have a hash (SHA-256) for each weight file?
• Has the model name passed internal naming rules and a trademark check? (see Choosing a project name)
• Have you decided on a versioning scheme?

6. Approval and afterwards

• Have you obtained approval from your organization’s executive or leader?
• Have you requested an OSRB review? (stage A of the release process)
• Is someone assigned to answer questions after release?
• Is there a route for reporting vulnerabilities or misuse?
• Have you decided what would make you withdraw or revise the model?

Checking it automatically

The model card, license and dataset items above can be checked with a tool. Give BomLens a model id and it reads the model card, then reports what is missing and how to supply it. Why it matters and how to run it are both in AI SBOM.

What a tool can check stops at what the model card and the repository metadata reveal. Whether personal data ended up in the training set, or whether a contract allows publication, is a judgement a person has to make.

Related pages

• Releasing an AI model — the whole path
• Model card — how to write it
• AI SBOM — documenting for regulation

Contact

For items you are unsure about, contact the OSRB (opensource@sktelecom.com).

4.2 - Writing the Model Card

A model card is not a separate form. It is the README.md file in the model repository. The YAML block at the top is the metadata machines read; the Markdown below it is the description people read.

It is the first thing users read after release, and it is also where documentation for regulation starts. Anything absent from it cannot be verified by any tool either.

File structure

---
license: apache-2.0
language:
  - ko
  - en
base_model: Qwen/Qwen2.5-7B
datasets:
  - HuggingFaceFW/fineweb
pipeline_tag: text-generation
library_name: transformers
---

# Model name

Description, intended use, limitations and evaluation results.

Metadata fields

The YAML block drives search and filtering, and it is what a tool reads when building an AI SBOM. These four fields matter most.

For a non-standard license, set license: other and give the name and a link.

license: other
license_name: License name
license_link: https://example.com/license

Declare datasets as far as you can even when you are not publishing the data itself. If something cannot be disclosed, saying so in the body — and why — is better than leaving it blank.

What belongs in the body

Start from the model card template that Hugging Face provides. These sections connect directly to documentation duties, so it is worth not leaving them empty.

Model description

What the model does, how it is built, and roughly how many parameters it has.

Intended use

The situations the model was built for. This corresponds to the part of the EU AI Act’s technical documentation that states a system’s purpose.

Out-of-scope use

Where it should not be used. Naming high-consequence domains explicitly — medical diagnosis, credit scoring — is more useful than a general disclaimer.

Limitations and bias

The performance limits and biases you know about. If an area went unverified, write that it went unverified. Disclosing a known problem is safer than omitting it.

Training data

What you trained on, and how you preprocessed and filtered it. If you filtered out personal data or copyrighted works, say how.

Evaluation

What you measured, against what, and with what result. Name the evaluation datasets and metrics.

Contact

Where questions and reports should go. Someone has to be assigned to answer them after release.

When to write it

Leaving the model card until the end means reconstructing details from training time, which makes it inaccurate. Recording as you go is far easier.

1. Before training, record the dataset list, provenance and licenses.
2. During training, record hyperparameters and evaluation results.
3. While preparing the release, move these into the model card and add intended use and limitations.
4. Confirm what is left with the pre-release checklist.

Related pages

• Pre-release checklist — checking model card items
• AI SBOM — what gets built from the model card
• Model Cards — Hugging Face documentation

Contact

For anything you are unsure about, contact the OSRB (opensource@sktelecom.com).

4.3 - AI SBOM and Regulation

An AI SBOM is a machine-readable inventory of a model, its training datasets, and their provenance and licenses.

• Where a software SBOM carries package dependencies, an AI SBOM also covers what a software SBOM leaves out: model weights and training data.
• It is built from what the model card says, so a thin model card leaves an AI SBOM with that many empty entries.

Why produce one

It serves two purposes.

1. For the publisher it is a self-check on how complete the documentation is. Seeing what is missing as a list means you can close the gaps before release.
2. For the recipient it is evidence for a review. Just as SK Telecom asks suppliers for an SBOM, other organizations have begun asking the same of AI models.

Key regulations

• What reaches you when you release a general-purpose model is Article 53. It asks for technical documentation, a copyright policy, and a public summary of training content, and it already applies.
• Fine-tuning someone else’s base model may leave you outside those duties. The Commission’s guidelines use a third of the original training compute as the dividing line.
• Releasing the weights and the architecture under an open-source licence exempts the technical documentation, but the copyright policy and the public summary of training content remain. The summary follows a template the Commission provides.
• Article 11 and Annex IV attach to the high-risk system your model ends up in, not to the model.
• Korea’s AI Framework Act keeps its detailed documentation requirements in the enforcement decree, so it is less specific than the EU’s. Article 32 (safety) applies only to systems trained above a compute threshold set by that decree, so a linked element points at the subject of the duty rather than establishing that the duty applies.

The G7 minimum elements

In May 2026, the cybersecurity agencies of the G7 jointly published “Software Bill of Materials for AI — Minimum Elements”, with Germany’s BSI and Italy’s ACN leading the work. It defines 50 minimum elements in seven clusters that an AI system’s inventory should carry. It is a non-binding recommendation, not a regulation.

• Thirteen of the 50 have no automated source. Things like the intended application area or the sensitivity of the training data cannot be proven by any model card field, so a person has to supply them.
• BomLens reports these 50 as 51 checks, because it scores model openness on its own line.
• The technical documentation the EU AI Act asks for corresponds to the G7 system-level, model, and dataset clusters. That correspondence is BomLens’s reading.
• Advisory as they are, the elements overlap substantially with the documentation those regulations require. Filling the G7 side also builds most of what a regulatory submission needs.

Producing an AI SBOM

Give BomLens, SK Telecom’s open-source SBOM generator, a model id and it reads the model card, builds a CycloneDX AI SBOM, and reports G7 element coverage alongside the regulatory mapping. (It reads the model card and the repository metadata; it does not download the weight files themselves.)

• Setup, usage and how to read the reports are covered in the BomLens AI model guide.
• It needs a Docker engine, and pulls the AI-model scanning image (about 3.5 GB) once.
• The command below assumes BomLens is already installed.

./scripts/scan-sbom.sh --project my-llm --version 1.0.0 \
  --model "my-org/my-llm" --generate-only

A private repository needs a token with read access.

• Create a read-scoped token under Access Tokens in your Hugging Face account settings. A fine-grained token needs read access to that repository granted explicitly.
• How to pass it as HF_TOKEN, and what a gated repository additionally requires, are in Private and gated models.

You get:

• an AI SBOM covering the model and its datasets
• per-element coverage, and how to supply what is missing
• the mapping to the EU AI Act and Korea’s AI Framework Act
• components whose license needs human review

Checking the result

An overall pass does not mean every G7 element is filled. G7 elements are all advisory and do not move the verdict. Read the covered count and the gap count separately.

• Gaps come in two kinds: those you close by writing in the model card, and those a person has to judge. Start with the first kind.
• To see what a report looks like before running anything, open the conformance report from a sample model scan. It opens with coverage per cluster and the licences flagged for review, then works down to the per-check verdicts.

Related pages

• Model card — the input to an AI SBOM
• Pre-release checklist — what to confirm before release
• What is an SBOM — SBOMs in general
• BomLens AI model guide — setup, usage, reading the reports
• BomLens — the tool, and its supplier-facing usage

References

• Software Bill of Materials for AI — Minimum Elements (G7, May 2026)
• Regulation (EU) 2024/1689 (AI Act)
• Timeline for the implementation of the EU AI Act (European Commission)
• AI Framework Act (Korea)

Contact

For questions about producing or reading an AI SBOM, contact the OSRB (opensource@sktelecom.com).