PHEP 6: Community and Licensing Standards

pheps/phep-0006.md

@@ -0,0 +1,161 @@
+```
+PHEP: 6
+Title: Community and Licensing Standards
+Author: Jonathan T. Niehof <jtniehof@gmail.com> <https://orcid.org/0000-0001-6286-5809>
+Discussions-To: https://github.com/heliophysicsPy/standards/pull/44
+Revision: 1
+Status: Draft
+Type: Standards Track
+Content-Type: text/markdown; charset=UTF-8; variant=CommonMark
+Requires: 4
+Created: 20-Oct-2025
+Post-History: 04-June-2025, 18-Oct-2025, 20-Oct-2025, 19-Dec-2025
+Resolution:
+```
+
+# Abstract
+<a name="abstract"></a>
+This PHEP updates the PyHC standards relating to licensing, open development, and community.
+
+# Motivation
+<a name="motivation"></a>
+The consideration of PHEP 4 on package tiering requires a revisit of our standards to clarify how standards relate to various package tiers. PyHC standards GitHub [pull request #16](https://github.com/heliophysicsPy/standards/pull/16) also provides several suggested updates.
+
+Discussions at the Fall 2024 PyHC meeting suggested a particular need for further discussion on licensing, particularly how PyHC as a community wants to address the existence of "non-ideal" licenses and how to handle any exceptions. Licensing is closely related to open development and the creation of community around packages.
+
+# Rationale
+<a name="rationale"></a>
+PyHC standards GitHub [issue #33](https://github.com/heliophysicsPy/standards/issues/33) opened discussion regarding open development, community, and licensing. There was little discussion there; fall meeting 2024 discussion indicated little appetite for further "hard" community standards. There was consensus that permissive open source licenses remain preferred for PyHC; however, other licenses continue to affect our community and a consensus needed to be developed surrounding them.
+
+This PHEP focuses on three goals:
+
+  1. Bringing the current community-related [standards](https://doi.org/10.5281/zenodo.2529131) (2, 5, 12, 13, 15) into the PHEP framework while making only minor updates in accordance with current practice.
+  2. Providing extensive best-practices examples for further steps packages can take to foster open development.
+  3. Clarifying standards around licensing and package tiering.
+
+The licensing standards are updated according to several principles:
+
+  1. Minimize the effort spent by the community in thinking about license selection and compatibility; reduce license proliferation. For these reasons, the list of recommended licenses is very short: rather than recommending every reasonable license, the goal is to present the minimum choice that does the job.
+  2. Provide clear, simple recommendations to new projects.
+  3. Require open source licenses. This is the minimum standard for an open community like PyHC. Rather than duplicating effort, the [Open Source Initiative (OSI) list](https://opensource.org/licenses) is used.
+  4. Discourage licenses that place barriers to contributions. Notably, the [NASA Open Source Agreement (NOSA)](https://opensource.org/license/nasa1-3-php) is discouraged due to requirements it places on "Contributors".
+  5. Prefer permissive, "BSD-style" licenses and discourage copyleft-style licenses. Copyleft licenses (such as the GPL) place restrictions on the distribution of binaries and combinations with other code that can be limiting and confusing. The goals behind copyleft licenses are less applicable in domain-specific, often research-focused, software such as PyHC projects. NASA Scientific Information Policy [SPD-41a](https://science.nasa.gov/wp-content/uploads/2023/08/smd-information-policy-spd-41a.pdf) states "software should be released under a permissive license that has broad acceptance in the community". NASA policies are binding for many PyHC contributors.
+  6. Encourage the use of licenses which are familiar to PyHC, to the open source community, and to institutions which may need to approve the release of code. The development of this PHEP drew on the [Report of the License Proliferation Committee](https://opensource.org/proliferation-report) from the OSI. This minimizes uncertainty about license compliance for those using, distributing, and contributing to PyHC projects. For these reasons, and the SPD-41a directive, preferred licenses are selected from OSI's [list of licenses that are popular and widely used](https://opensource.org/licenses?categories=popular-strong-community). Of these: the **3-clause BSD** is a license with a long history, familiar to legal and technical experts; the **Apache 2.0** license is accepted by NASA for release of internally-developed software; and the **MIT** license is the most commonly used license on existing PyHC projects. All three m eet the other principles.
+  7. Given these principles, recognize that some projects may have special needs due to institutional requirements or accidents of history. It is preferred that these projects be accommodated within the community rather than left out if they are unable to change their license.
+
+# Specification
+<a name="specification"></a>
+
+Considerable best-practice information is included in [How to Teach This](#how-to-teach-this) but is not considered part of this specification proper.
+
+The following current [PyHC standards](https://github.com/heliophysicsPy/standards/blob/main/standards.md#standards) remain as approved in 2018, with the addition of reference to this PHEP. They are explicitly incorporated into this PHEP. They are applicable to all bronze, silver, and gold tier packages.
+
+Standard #2 "**Open Development**: All code must be made available and developed publicly (PHEP 6)."
+
+Standard #6 "**Version control**: All code must use version control. It is strongly recommended that projects make use of a distributed version control system (e.g., git) (PHEP 6)."
+
+Standard #12: "**Duplication**: Duplication of code and functionality is discouraged. Forking projects into new projects is strongly discouraged (PHEP 6)."
+
+Standard #13: "**Collaboration**: Contributions to packages must be encouraged. Packages must provide contribution guidelines and clearly explain when a contribution is not accepted (PHEP 6)."
+
+Standard #15: "**Code of conduct**:  Each project must adopt a code of conduct that is compatible with the [Contributor Covenant](https://www.contributor-covenant.org) and make it publicly available (PHEP 6)."
+
+Licensing standards are significantly updated, as follows.
+
+All projects must provide an explicit license and should use the [BSD 3-clause](https://opensource.org/license/bsd-3-clause), [Apache 2.0](https://opensource.org/license/apache-2-0), or [MIT](https://opensource.org/license/mit) licenses.
+
+Projects at the bronze tier or above must use an [OSI-approved open source license](https://opensource.org/licenses) and should use the [BSD 3-clause](https://opensource.org/license/bsd-3-clause), [Apache 2.0](https://opensource.org/license/apache-2-0), or [MIT](https://opensource.org/license/mit) licenses.
+
+Projects at the gold tier must use one of the [BSD 3-clause](https://opensource.org/license/bsd-3-clause), [Apache 2.0](https://opensource.org/license/apache-2-0), or [MIT](https://opensource.org/license/mit) licenses; or include a detailed description of:
+
+  * the reason for using another license
+  * why relicensing is not possible, including any efforts taken to that end
+  * what steps will be taken to overcome the disadvantages of the license, including the ability to distribute via normal means, the ability to accept contributions without restrictions, and the ability to be used as a component of other projects.
+
+Project reviewers will consider this rationale in evaluating the package for gold tier. It is still strongly recommended to use a permissive license from the OSI category "[Licenses that are popular and widely used or with strong communities](https://opensource.org/licenses?categories=popular-strong-community)", i.e. [BSD 2-clause](https://opensource.org/license/bsd-2-clause), [CDDL](https://opensource.org/license/cddl-1-0), [EPL](https://opensource.org/license/epl-2-0), or [MPL](https://opensource.org/license/mpl-2-0). This will be taken into consideration when evaluating the reason for the selection of license.
+
+At all tiers, dual licensing is acceptable provided at least one of the licenses meets the relevant requirements.
+
+Standard [#5](https://github.com/heliophysicsPy/standards/blob/main/standards.md#standards) is replaced with: "**License**: Projects must provide a license and should use the BSD 3-clause, Apache 2.0, or MIT licenses. Projects at the Bronze or higher tier must use an [OSI-approved open source license](https://opensource.org/licenses). Most projects at the gold tier must use the BSD 3-clause, Apache 2.0, or MIT licenses; projects with special licensing needs refer to [PHEP 6](https://heliopython.org/docs/pheps/)."
+
+# Backwards Compatibility
+<a name="backwards-compatibility"></a>
+This PHEP makes no changes to existing PyHC standards except in licensing. All packages following the previous standard's recommendation for OSI-approved permissive licenses are unaffected. Those packages using non-recommended licenses will have to perform additional work for package tiering evaluation, including documenting the need for a non-recommended license, or be relegated to a lower package tier.
+
+As more packages use the recommended licenses, legal interoperability between projects should be improved.
+
+# Security Implications
+<a name="security-implications"></a>
+This PHEP raises no security implications as it does not interact with any executing code or provide any coding standards.
+
+# How to Teach This
+<a name="how-to-teach-this"></a>
+
+## Community and licensing standards
+
+Most standards remain unchanged. The approval of this PHEP will help make them and the best practices more visible. Upon approval of this PHEP the included best practices will be advertised at the following telecon, and they will also be provided as a reference for package tiering applications. Reviewers of package tiering should provide feedback related to best practices as an education tool, but not enforce them as part of the review.
+
+For many projects, the licensing standards will require no updates. The key education tool will be project tiering evaluation forms and processes, which should clearly emphasize the preferred licenses while still providing room for justifying other licenses. Standards on packaging should also refer to this PHEP, as projects should be making license decisions early in the lifecycle along with other initial packaging work. The [SPDX license list](https://spdx.org/licenses/) is an additional resource for the text of licenses and relevant notes.
+
+## Community and licensing best practices
+<a name="best-practices"></a>
+
+See also [Reference Implementation](#reference-implementation) for examples of how these best practices are used in PyHC and other projects.
+
+Public availability and development of the code are key to, but not sufficient for, growing a community around a package.
+
+This includes development in a version controlled repository which is accessible to the public. PyHC uses git almost universally and most projects use GitHub, which facilitates much of the workflow around these activities. Using similar tools across packages helps integrate the PyHC community.
+
+To keep development open, not just the code, most projects have a means to discuss design and other decisions in a way that allows for public visibility and input. This includes means of collecting user feedback, bug reports, feature requests, and other inputs. Providing all contributors access to the same or similar workflow as project developers, e.g. pull request and reviews, smooths contributions and breaks down distinctions between "internal" and "external" contributions. Choosing a license without restrictions on the ability to distribute via normal means, the ability to accept contributions, and the ability to be used as a component of other projects further supports open development.
+
+A publicly available reporting procedure for reporting violations of the code of conduct encourages healthy interactions. For one example, see [the Code of Conduct Response and Enforcement Manual for NumFOCUS](https://numfocus.org/code-of-conduct/response-and-enforcement-events-meetups). Consider best practices for email vs. other means of communication, anonymity and/or privacy of reports, and transparency.
+
+GitHub provides several means of [exposing important information](https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions) through the GitHub interface, including [license](https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/adding-a-license-to-a-repository), [Code of Conduct](https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/adding-a-code-of-conduct-to-your-project), [ways to get support](https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/adding-support-resources-to-your-project), and [contributor guides](https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors).
+
+# Reference Implementation
+<a name="reference-implementation"></a>
+Several PyHC projects provide examples of best practices for growing a community. Both the documentation and its visibility from the project's main page are important.
+
+Examples of contributor workflow and similar documentation:
+
+  * SunPy's [Newcomers' Guide](https://docs.sunpy.org/en/latest/dev_guide/contents/newcomers.html), linked from a "contribute" page in the main navigation header of all SunPy documentation.
+  * [Contribute to PlasmaPy](https://www.plasmapy.org/contribute/), linked from the main navigation header of all PlasmaPy pages.
+  * [Contributing to PySPEDAS](https://pyspedas.readthedocs.io/en/latest/contributing.html), linked from sidebar of PySPEDAS docs.
+
+Examples of processes for community input to design decisions:
+
+  * [PlasmaPy Enhancement Proposals](https://github.com/PlasmaPy/PlasmaPy-PLEPs), linked from the sidebar of PlasmaPy docs.
+  * [SpacePy Design and Roadmapping discussions](https://github.com/spacepy/spacepy/discussions/categories/design-and-roadmapping).
+
+Examples of Codes of Conduct:
+
+  * [SunPy](https://sunpy.org/coc/), linked from the sidebar of SunPy "about" pages.
+  * [PlasmaPy](https://docs.plasmapy.org/en/latest/CODE_OF_CONDUCT.html), linked from sidebar of PlasmaPy docs and "about" dropdown in nav header.
+
+
+# Rejected Ideas
+<a name="rejected-ideas"></a>
+Many of the suggestions in [Best Practices](#best-practices) were considered for standards. Discussion before and during the Fall 2024 PyHC meeting indicated no consensus for imposing additional standards in this area, even as "shoulds". The existing standards seemed sufficient and the community lacked broad agreement on anything further.
+
+The "short list" was originally only two licenses long; the MIT license was added due to its wide use in PyHC.
+
+# Open Issues
+<a name="open-issues"></a>
+More / more varied examples for reference implementations would be *very welcome*.
+
+# Revisions
+Revision 1 (pending): Initial approval.
+
+# Copyright
+<a name="copyright"></a>
+This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive. It should be cited as:
+```
+@techreport(phep9999,
+  author = {Jonathan T. Niehof},
+  title  = {Community and Licensing Standards},
+    year = {2025},
+    type = {PHEP},
+  number = {6},
+     doi = {10.5281/zenodo.XXXXXXXX}
+)
+```