All,

The following email is being shared with cf-dev@ in the interests of
transparency into the project for the larger community. There will be a
follow up email related to the impact of this on buildpacks.

Guidance to CFF Project Teams - Handling of Proprietary Software
IntegrationsCloud Foundry FoundationBackground

Cloudfoundry.org Foundation, Inc. (CFF) is a United States based 501(c)(6)
nonprofit organization. The Foundation’s purpose is to support the growth
and adoption of Cloud Foundry as the leading application platform for
cloud computing globally.

Due to the nature of the Cloud Foundry software, the CFF actively
encourages the integration of relevant and complementary technologies, both
open source and proprietary. These integrations provide valuable
functionality for end users of Cloud Foundry, both direct users of the open
source and users of commercial distributions / services derived from the
CFF’s open source software.

As a U.S. based organization, the CFF is required to comply with relevant
U.S. regulations and laws related to the export of software from the U.S..
In particular, the CFF’s software is collectively classified as ECCN 5D002
due to the inclusion of encryption technologies within the platform. The
CFF exports its software under the terms of the TSU exception in EAR
section 740.13(e), which applies to software containing or designed for use
with encryption software that is publicly available as open source, and
have been registered by the CFF with the U.S. government under this TSU
exception. More information can be found here:
https://www.cloudfoundry.org/exports/
Software Distribution

In order to comply with the requirements in the TSU exception, the CFF and
it’s projects should only distribute open source software.

This includes both source code and compiled versions of that software. The
open source software need not be a project of the CFF (it may be sourced
from other open source projects). In cases of compiled software, there must
be a direct correlation between the binary and the open source code that it
is created from.

Distribution of software should be considered any of the following:

1.

Distribution from CFF owned GitHub organizational repositories,
including, but not limited to, source repositories and release artifacts.
This applies to the following GitHub organizations:
1.

https://github.com/cloudfoundry
2.

https://github.com/cloudfoundry-incubator
3.

https://github.com/cloudfoundry-attic
4.

https://github.com/cloudfoundry-samples
5.

https://github.com/openservicebrokerapi
2.

Distribution of software via any cloudfoundry.org URL, regardless of the
infrastructure that it is hosted on.
3.

Distribution of software via bosh.io
4.

Distribution from any other location directly associated with any CFF
project team


This does not apply to locations not owned by, or the responsibility of,
the Cloud Foundry Foundation or its projects. This includes commercial
vendor distribution locations, which are not the responsibility of the CFF.
Guidance on Handling Proprietary Software Integrations

As stated earlier, the CFF actively encourages the integration of any type
of relevant and complementary software into the CFF’s software. This
includes proprietary and closed source software products.

However, CFF project teams must be aware of the distribution restrictions
and design the integrations in a way that avoids the CFF distribution of
proprietary software.

Code written to support the integration of proprietary software is
encouraged (where appropriate), and may be hosted within the CFF project
repositories and distributed via CFF distribution channels. As always, all
source code included in CFF projects must comply with the relevant CFF
policies on licensing, including the Intellectual Property Policy
<https://www.cloudfoundry.org/wp-content/uploads/2017/01/CFF_IP_Policy.pdf>
and the Development Operations Policy
<https://www.cloudfoundry.org/wp-content/uploads/2017/01/CFF_Development_Operations_Policy.pdf>
.

Distribution of proprietary software should be left to either the
organization from which the software is sourced (the vendor) or be the
responsibility of Cloud Foundry downstream distributions / service
providers.

Project teams are also asked to review existing integrations in order to
ensure compliance.
Getting Help

If any project team has questions around this guidance, CFF staff will
either directly answer the question or facilitate a conversation with the
appropriate legal counsel.

--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815