Last updated: January 9, 2026

Background

LF Open Source, LLC (“LFOS”) enables the access and use of application development platforms of third party application stores and distribution entities (each, a “Platform”) and the distribution of applications through those Platforms. 

LFOS enables developers of qualified open source project developers who have executed and are subject to a LFOS Dev Account Access Agreement to access LFOS’s Platform accounts for the benefit of a qualified open source project (each, a “Dev Account”).  

Binaries

In this policy, “Binaries” refers to any such version of the Project’s software that is produced and published by the Project in a ready-to-run, packaged form, with the intent of making it broadly available for execution in that form by downstream recipients. Binaries include applications intended to be distributed via Platforms.

For example, for purposes of this policy, “Binaries” include (a) executable versions of the Project software compiled and published as a “Release” via a Platform pursuant to support by LFOS, (b) applications based on the Project software compiled and published to a Platform pursuant to support by LFOS, and c) source code versions of the Project software, when packaged together with third-party dependencies and published as a ready-to-run unit to a Platform pursuant to support by LFOS.

“Binaries” include any third-party dependencies that are included in the distributed content.

For purposes of this policy, “Binaries” do not include:

• • Object code files generated by third parties (including Project participants) on their own behalf, separately from the artifacts officially published by the Project community.
  • Object code files created as intermediate steps as part of the Project’s automated build and testing process, where such files are not intended for general downstream use.
  • Auto-generated files created by transforming a Project source code file into another source code form included in the Project’s source code repository.

• Example: when a Protocol Buffers .proto file is “compiled” into a language-specific file that is included in the Project’s source code repo, that automatically-generated file is not considered a “Binary” under this policy.

• • Binary data included in a project’s source code repository for purposes other than execution by end users.

• Example: Graphical image files in a repo are not considered “Binaries” under this policy, despite consisting of binary (non-textual) data.

• Example: Binary data files included as test cases in a repo are not considered “Binaries” under this policy.

Binary Distribution Considerations

A Project’s publication and distribution of Binaries raises several potential legal, policy, and compliance considerations that go beyond those involved in distributing source code, such as:

• License compliance: Applicable open source licenses, including those for third-party dependencies, may impose additional requirements on Binaries that go beyond those for source code itself.

• Security: Since a Binary is intended to be ready-to-run, and may include third-party dependencies that are not directly visible in the source code itself, Projects distributing Binaries should take extra steps to account for security and vulnerability management. 

• Export controls: Some countries’ export controls regulations may impose additional requirements on distributions of Binaries, particularly when cryptography is involved.

• Distributor requirements: A third-party software distribution network, such as an “app store” or a package manager, may impose contractual obligations that the Project needs to ensure it follows.

• Community expectations: Finally, a Project distributing Binaries should consider the typical assumptions that would be made by recipients of an open source project’s Binaries, and conform to those expectations.

• End-User Support Requirements: various Platforms require that support be provided to end-users of applications and Binaries distributed through their infrastructure. Any open source project that wishes to use LFOS in the distribution of Binaries must agree, and be ready to, provide such end-user support as the application Platform may require. LFOS is itself not positioned or able to provide end-user support. Any open source project that is unable to provide end-user support as may be required by any application Platform will have its access rights to LFOS Accounts removed.

The remainder of this policy sets forth requirements and recommendations for Projects that choose to distribute Binaries.

Requirements for Distributing Binaries

Before distributing a Binary—whether via its own repository or website, or on a Platform—the Project must ensure that it complies with the following requirements.

 

1. Identify LFOS as the distribution entity

In the metadata for the Binary, and where applicable at the points of distribution, the Project should ensure that “LF Open Source, LLC” is specified as the legal entity distributing the Binary.

2. Distribute at no charge under the Project’s Applicable Licenses

The Project must make the Binary available to all persons at no charge.

The Binary must be distributed under the open source licenses specified in the Project’s intellectual property policy, as set forth in its charter (see Section 3 below). Additional applicable licenses should also be specified and complied with as described in Section 4 below.

3. Comply with Project’s Intellectual Property Policy

The Binary must only include content that is subject to licenses that comply with the Project’s intellectual property policy. Please review the Project’s charter for details about its specific IP policy.

Projects’ IP policies typically require approval from a Project governing body when distributing content under licenses that differ from the Project’s own licenses. This may be necessary in particular for distributing third-party dependencies subject to other licenses.

Third-party dependencies will typically only be approved for distribution by a Project governing body when they are provided under either:

1. an appropriate free and open source software (FOSS) license, which is compatible with other applicable licenses for the Binary’s particular use case; or
2. in very limited situations, non-FOSS components that are required for redistribution with the Binary and subject to pterms permitting redistribution. This may include, for example, redistributable components that are separate programs (e.g. an application that directly calls a proprietary database), or that are necessarily interfaced with or used whenever any software is developed for the particular platform.

4. Comply with all Applicable Licenses

The Project must ensure that it complies with all licenses applicable to the Binary’s distribution.

The specific requirements will vary depending on the particular licenses and dependencies involved, and may include (among others) requirements such as:

• including a copy of all applicable licenses’ texts;
• retaining and reproducing all applicable copyright notices;
• making available applicable corresponding source code for part or all of the distributed content (including dependencies); and
• ensuring that the applicable licenses are “compatible” with one another for the particular use case of making the Binary available.

5. Comply with US Export Controls requirements

Please see the Linux Foundation’s guidance on export controls at https://www.linuxfoundation.org/resources/publications/understanding-us-export-controls-with-open-source-projects?hsLang=en for more information about the U.S. Export Administration Regulations (EAR) and open source.

If the Binary includes any cryptographic functionality, the corresponding source code for that functionality must be publicly available. (In other words, any non-FOSS, object-code-only components approved under 3(B) above should not include cryptographic functionality.)

Additionally, if the Binary implements any non-standard cryptography, then additional notifications must be delivered prior to making the Binary available. Please contact your Linux Foundation program manager or another Linux Foundation staff member to discuss.

6. Establish a Security Policy

All Projects approved for distribution of Binaries via LFOS must publish, in its governance materials or other project documentation, and maintain and follow a written security policy that describes how the Project:

1. uses secure software development practices; and
2. handles vulnerabilities in an effective manner.

This security policy should include a point of contact (such as a group email address that is monitored by more than one Project maintainer) for receiving reports of vulnerabilities.

The Project should verify on a regular basis that it is acting in accordance with its security policy.

7. Consider Privacy and Telemetry Requirements

If the Project will be collecting and processing any personal data via end users’ use of the Binary, the Project should work with its Linux Foundation program manager to determine whether a review by Linux Foundation privacy team members is warranted.

Similarly, if the Project’s Binary will be collecting any telemetry data (whether personal data or not) via end users’ use of the Binary, the Project should work with its Linux Foundation program manager to determine whether a review under the Project’s applicable Telemetry Data Collection and Usage Policy is warranted

 

Additional Requirements for App Store Distribution

Some Projects may desire to make Binaries available via third-party “app stores,” such as the Apple App Store, Google Play Store, and others.

These app stores typically require application providers to sign up to extensive contractual obligations, which are structured for use by commercial software companies rather than open source project communities. These obligations often relate to matters such as code signing; insurance requirements; confidentiality commitments; and others.

As a result, in order for a Project to make its Binaries available on a third-party “app store” that requires additional contractual terms, the Project must ensure that it complies with the following requirements in addition to those set forth above.

1. LF Directed Fund approval required

Because of the expenses involved in satisfying app store requirements, any Project that desires to publish Binaries on an app store must be supported by a funded Linux Foundation Directed Fund.

The Directed Fund’s governing board must (A) formally approve the publication of Binaries on app stores, and (B) agree that the Directed Fund’s budget will be responsible for any liabilities that arise from such publication of Binaries by the Project.

2. Ensure available (including elsewhere) under FOSS license

Some app stores may mandate that the applications it distributes be subject to particular end-user license agreement (EULA) terms, which may require including non-FOSS provisions.

If so, then in addition to the Binary published on the app store under such terms, the Project community should also ensure that it makes available an equivalent version of the Binary in a separate location (such as the Project’s repo artifacts or website) under the Project’s applicable FOSS licenses.

3. Establish an End User Support Policy

While virtually all FOSS licenses explicitly disclaim obligations for software licensors to provide support, some app stores may nonetheless mandate that their platforms’ end users are supported by the application providers.

In order to comply with this requirement, the Project should develop and publish, in its governance materials or other project documentation, a written end user support policy that describes how the Project will provide maintenance and support for end users of the Binary.

This end user support policy should include a point of contact (such as a group email address that is monitored by more than one Project maintainer) for receiving support requests.

The Project should verify on a regular basis that it is acting in accordance with its end user support policy.

4. Reference the applicable LFOS Privacy Policy

App store terms typically require that the Binary application’s metadata include a link to the applicable Privacy Policy. The Project should work with its Linux Foundation program manager to identify and reference the correct Privacy Policy.

5. Sign a Dev Account Access Agreement with LF distribution entity

Projects supported by the Linux Foundation, being open source communities, naturally do not contemplate the use of confidentiality obligations. However, some app stores impose confidentiality requirements on the persons who are provided with access to tools and information used for publishing applications to the app store.

Since Project maintainers are almost always not employees of the Linux Foundation, confidentiality requirements imposed by the app stores would not automatically be applied to the Project maintainers who would be involved in actually carrying out the publication to the app stores.

Therefore, one or more of the Project maintainers may be required to enter into a short dev account access agreement with the LF binary distribution entity, so that the confidentiality requirements imposed by the app stores can be satisfied.

Recommendations

Projects are strongly encouraged to establish a process for creating and publishing Software Bills of Materials (SBOMs) describing the contents of the Binaries. SBOMs should be published in a standardized format such as SPDX.

Comments

This policy may be amended from time to time. Comments and feedback on this policy should be sent to legal@lfopensource.com.