Merge pull request #822 from swinslow/source-available-update-1.1

Add expanded source available recommendations

Author: jeefy

source-available-recommendations.md

@@ -1,4 +1,4 @@
-# Source Available Recommendations v1.0
+# Source Available Recommendations v1.1
 
 Third Party Dependencies that have been Relicensed to Source Available, non-open source licenses
 
@@ -26,7 +26,7 @@ Separately, other dependencies that were once available under Apache-2.0 or othe
 
 Speaking broadly, "source available" means that the source code is made available by the licensor, but a source available license does not necessarily grant the full set of rights and freedoms for use, modification, and distribution that are granted by open source licenses. For example, some source available licenses may prohibit the recipient of software from using it for commercial purposes, or in production environments, or may forbid certain types of people or companies from using or redistributing it. Other source available licenses may grant the full set of open source rights, but may impose conditions that are vague or effectively impossible to comply with. Often these licenses are used to make the source code available for evaluation or testing purposes only.
 
-Because of these restrictions or limitations on rights, certain "source available" licenses do not qualify as “open source” under the [Open Source Definition], and are therefore unlikely to be approved by the CNCF Governing Board  for inclusion as dependencies for CNCF projects.
+Because of these restrictions or limitations on rights, certain "source available" licenses do not qualify as “open source” under the [Open Source Definition], and are therefore unlikely to be approved by the CNCF Governing Board for inclusion as dependencies for CNCF projects.
 
 Where a third-party dependency was once available under Apache-2.0 or another license approved by the Governing Board on an exception basis or subject to the [Allowlist License Policy], but has changed to a "source available" non-open source license, this can present a problem for CNCF projects. In such cases, the license of the component they depend on was previously aligned with the CNCF project's own license, but is no longer aligned.
 
@@ -35,6 +35,7 @@ Where a third-party dependency was once available under Apache-2.0 or another li
 The following are a few examples of licenses that CNCF understands to be "source available" but not open source. Please note that this is not an exhaustive list, and may include other versions of such licenses as well. Bracketed identifiers refer to [SPDX License List] identifiers, where applicable.
 
 * Business Source License 1.1 (BUSL-1.1)
+  - BUSL-1.1 includes several custom fields to be determined by the licensor, so its restrictions and requirements will likely differ among products.
 * Elastic License 2.0 (Elastic-2.0)
 * Hippocratic License 2.1 (Hippocratic-2.1)
 * licenses using the "Commons Clause" additional text
@@ -43,7 +44,7 @@ The following are a few examples of licenses that CNCF understands to be "source
 
 ## Recommendations
 
-There are a couple of approaches that CNCF projects should consider taking, for
+There are a few approaches that CNCF projects should consider taking, for
 dependencies that fall into this category.
 
 ### Switch to an alternative component
@@ -61,9 +62,71 @@ This is unlikely to be tenable as a long-term solution, particularly as
 the prior release is presumably unlikely to continue receiving maintenance
 updates, security fixes, etc.
 
-In either case, while a project's maintainers may request a license exception from the CNCF Governing Board, it is _extremely_ unlikely that one will be granted for the use of a dependency under a source available, non-open source license.
+### Fork and maintain
+
+Finally, the project might decide to take on the responsibility for maintaining its own fork of the open source version of the component, typically based on the final release prior to the change to a source available license.
+
+Please see [below](#considerations-for-forking-and-maintaining) for details to consider if the community desires to take this approach.
+
+### Exception requests
+
+In any case, while a project's maintainers may request a license exception from the CNCF Governing Board, it is _extremely_ unlikely that one will be granted for the use of a dependency under a source available, non-open source license.
+
+## Considerations for Forking and Maintaining
+
+A decision to fork and maintain a pre-existing independent project is typically not a small undertaking. Below are some of the considerations that a CNCF project would likely want to take into account when going this route. In any case, please reach out early to CNCF staff via the [CNCF Service Desk] to discuss details if you are considering this approach.
+
+### Governance and IP policy formalities
+
+The forked project’s ongoing maintenance could potentially be managed (1) within CNCF; (2) within a [separate open collaboration project under the Linux Foundation](https://www.linuxfoundation.org/projects); or (3) as part of a fully-separate community effort.
+
+If the fork would be part of the existing CNCF project which uses it, then it would need to comply with the IP policy from the [CNCF Charter] and be recorded as a sub-project subject to the CNCF project's existing governance processes. Similarly, if it would be set up as its own CNCF project, it would also be subject to CNCF’s standard processes for onboarding new projects; [initiating an application to join the CNCF](https://github.com/cncf/toc/tree/main/process).
+
+If the maintained fork would be a new project under the Linux Foundation, then it would likely need to be set up with its own governance structure and charter as with other LF-supported projects.
+
+Or, if it would be maintained via a separate community effort (as a standalone project or part of another open source foundation), then the CNCF project may want to review and confirm that its future licensing structure will align with the IP policy from the [CNCF Charter].
+
+### Comply with existing license requirements
+
+A fork is built upon the pre-existing third party project, and therefore needs to comply with all requirements of the pre-existing license(s).
+
+Open source license compliance is beyond the scope of this guidance document. However, as specific points (and as with any inclusion of a third party’s content), note that [all existing copyright and license notices should generally be retained without modification](https://github.com/cncf/foundation/blob/main/copyright-notices.md#dont-change-someone-elses-notice-without-their-permission).
+
+### Trademark changes
+
+It will typically be necessary to change the name of the forked project. The licensor will typically continue to use the old project names and logos in reference to the newly source-available project, and the fork would need to find a different name and logo, if applicable, for future diverging developments.
+
+As described [above](#comply-with-existing-license-requirements), trademarks referencing the original project can and should be retained where used in _pre-existing copyright notices_. And it will generally be acceptable to use a project’s name in _unstylized_ form solely for purposes of accurately describing the nature of the fork’s relationship to the original project (e.g., something like “Our project Frobozz is derived from Foo, and is forked from its final open source release. Foo is a trademark of FooBar, Inc.”).
+
+Please contact CNCF staff in advance via the [CNCF Service Desk] to discuss details for how to handle these changes.
+
+### Future developments
+
+For any collaborative open source development effort, proper attention to license compliance and provenance of contributions is an important part of project governance. When a development effort is building on top of a forked version of a non-participating licensor, compliance and provenance become especially crucial.
+
+Ultimately, a project’s formal contribution mechanisms -- such as Developer Certificate of Origin (DCO) sign-offs or Contributor License Agreements (CLAs) -- spell out the commitments that a contributor makes to the project and the community. A forked project may decide to establish additional processes to assist with demonstrating the community’s commitment to appropriate and transparent development.
+
+Here are a few guidelines and recommendations that a forked project will want to consider:
+
+**Do not’s**:
+
+* **Do not** copy any PRs, code or other content from the post-fork upstream source, where such content is published under the new non-open source license.
+  - It may be appropriate to e.g. read release notes and develop similar functionality, as long as such developments are done fully independently of the post-fork upstream project.
+* **Do not** remove or modify pre-existing license texts or copyright notices unless you are certain that they no longer apply (e.g., if a file no longer contains _any_ content that is arguably subject to that notice).
+
+**Do’s**:
+
+* **Do** talk to CNCF staff early and often during this process! Start by reaching out via the [CNCF Service Desk].
+* **Do** consider requiring contributors to document provenance details, such as explicitly marking within the repo:
+  - any content not originally written by the contributor, together with a pointer to its original source and license terms
+  - any content copied from one file within the codebase to another
+* **Do** require, as applicable, DCO sign-offs and/or authorization under signed CLAs for all contributions.
+  - Appropriate tooling can and should be used to help with ensuring that _all_ contributions are subject to the applicable sign-offs.
+* **Do** consider establishing a process for reviewing pull requests to confirm they are not similar to the post-fork upstream source.
+  - Depending on whether it is feasible given the project's size and the number of maintainers, a maintainer or reviewer who reviews a questionable pull request can subsequently limit their development in that area of the codebase to minimize this risk that their exposure to post-fork upstream code could influence their future contributions.
 
 [CNCF Charter]: https://github.com/cncf/foundation/blob/master/charter.md
+[CNCF Service Desk]: https://cncfservicedesk.atlassian.net/servicedesk/customer/portal/1/group/1/create/14
 [Allowlist License Policy]: https://github.com/cncf/foundation/blob/master/allowed-third-party-license-policy.md
 [AGPL-3.0]: https://www.gnu.org/licenses/agpl-3.0.en.html
 [Open Source Definition]: https://opensource.org/osd/