From 112703cbe67259e7099ba17ccd2cb5841fdddc67 Mon Sep 17 00:00:00 2001 From: Paul King Date: Tue, 2 Sep 2025 16:00:02 +0100 Subject: [PATCH 01/13] Add coding in open guidance --- using-github/readme.md | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/using-github/readme.md b/using-github/readme.md index 0d8d2334..87f23e57 100644 --- a/using-github/readme.md +++ b/using-github/readme.md @@ -1,5 +1,7 @@ # Our guidance for using GitHub +We should be adhering to the MoD digital service manual and [point 12](https://www.digital.mod.uk/service-manual/meet-the-standard) states that we should be making new source code open. This is an extension of the [GDS guidelines](https://www.gov.uk/service-manual/service-standard/point-12-make-new-source-code-open) in which they talk about [what should be open and what should be closed](https://www.gov.uk/government/publications/open-source-guidance/when-code-should-be-open-or-closed). There is the additional care to be taken with [security classifications](https://www.digital.mod.uk/service-manual/security-classifications) and commercial protections however we should opt for a Public repo on creation unless agreed upon in threat modelling that a closed repo is required. + ## Background This repository is to provide guidance on what must exist in open repos as a minimum with the aim of enabling people to feel familiar when browsing, find information and to become productive if contributing back. @@ -11,9 +13,13 @@ All open repos must contain the following: * **A CONTRIBUTING.md within the root folder.** The file is a marker to people that this repo will accept changes from outside of the team. It must contain the processes that the owner of the repository needs people to follow when contributing to the project. [Guidance on how to write a CONTRIBUTING.md](creating-a-contributing-file.md). * **A LICENSE within the root folder.** This will be MIT in most cases. Having a license is critical as it states what others are allowed to do with the code. + * **A README.md within the root folder.** This must contain some basic useful information for the user allowing them to quickly understand the project and get started using it. It isn't the place for extensive documentation. [Guidance on how to write a README.md](creating-a-readme-file.md). -* **A continuous integration build process.** Each time a pull request is submitted a build is triggered which will run all the tests to ensure the change does not break any features. This will also give the contributor feedback and confidence that their code will work! +> [!IMPORTANT] +> An empty readme does not provide any useful information to ourselves, the reader or future maintainers. Please do not create the file just to tick a box. + +* **A continuous integration build process.** Each time a pull request is submitted a build is triggered which will run all the tests to ensure the change does not break any features. This will also give the contributor feedback and confidence that their code will work! This also supports in keeping your services up to date with dependency and vulnerability updates. Above is the minimum for what an open repo must contain, other useful things a repo may contain: @@ -36,6 +42,18 @@ Above is the minimum for what an open repo must contain, other useful things a r All open repos must be using git and code contributions should be made using the standard Fork and Pull Request approach (or equivalent). [Guidance on how to make a pull request](pull-request-details.md). +## Tooling + +All public repos will need to have the following tooling run against them to ensure that we are protecting ourselves: + +* SAST Tooling +* SCA Scanning +* Container Scanning (where applicable) +* Infrastructure as Code scanning (where applicable) +* Code quality scanning +* Dependency/Vulnerability update checks (Dependabot or similar) +* Pre-commit secret checks (GitHub advanced security) + ## Terminology ```Contributing``` - This is more than just adding code, this also includes creating issues/bug reports, asking questions, improving documentation. From 8fe27b2da310bc021b41c146ac55d15f5dbe2ed8 Mon Sep 17 00:00:00 2001 From: Paul King Date: Tue, 2 Sep 2025 16:13:42 +0100 Subject: [PATCH 02/13] Update contributing details --- using-github/creating-a-contributing-file.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/using-github/creating-a-contributing-file.md b/using-github/creating-a-contributing-file.md index 9436d38d..1ba7939c 100644 --- a/using-github/creating-a-contributing-file.md +++ b/using-github/creating-a-contributing-file.md @@ -4,7 +4,7 @@ The CONTRIBUTING.md is the file that users will normally read before contributing to a project and it must provide them with the information needed to contribute to the project in a style which the owner wants. The CONTRIBUTING.md allows the owner to specify the standards and processes they want contributors to use thus setting the rules for everyone, including the rules for how the owner treats contributors. The CONTRIBUTING.md is written in [Markdown](https://en.wikipedia.org/wiki/Markdown) and placed in the root directory of the repository. -If a repo does not have a CONTRIBUTING.md then we do not class it as "open" and the owner may not want external contributions. +It is important to understand that contributions are not always in the form of code. Make sure that you specify how you wish people to interact and contribute through this file and how they will go about doing this. ### Must Have From c9b03ac8753eeb6aecba4624b1bbf43a5af02a41 Mon Sep 17 00:00:00 2001 From: Paul King Date: Tue, 2 Sep 2025 16:26:20 +0100 Subject: [PATCH 03/13] Add coding in the open doc --- using-github/coding-in-the-open.md | 50 ++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 using-github/coding-in-the-open.md diff --git a/using-github/coding-in-the-open.md b/using-github/coding-in-the-open.md new file mode 100644 index 00000000..d235d28d --- /dev/null +++ b/using-github/coding-in-the-open.md @@ -0,0 +1,50 @@ +# How to Meet Section 12: Make New Source Code Open (MOD / GOV.UK Standards) + +This guidance explains how teams can meet [**Section 12 – Make New Source Code Open**](https://www.digital.mod.uk/service-manual/meet-the-standard), following both the GOV.UK Service Standard and Defence‑specific considerations from the MOD Service Manual. + +## 1. Why this matters + +- **Public value** + New source code created with public funds should be open by default—this maximises reuse, reduces duplication, and supports transparency and cost-efficiency across government. + +- **Defence-specific constraints** + Defence teams should open code when appropriate, but withhold publishing code relating to SECRET or TOP SECRET systems or content that hasn't been publicly announced. + +## 2. What "make source code open" means + +### GOV.UK expectations + +- Write code in the open from the start, using a public repository—but never include secrets like API keys or credentials. +- Always retain IP ownership of your service’s new code and license it openly (e.g., MIT or another Open Source Initiative–compatible licence). +- If code must remain closed (e.g., unreleased policy or sensitive security mechanisms), provide a strong rationale—but open it as soon as permissible. + +### Additional GOV.UK technical guidance + +- Host code publicly (e.g., GitHub), ensuring departmental control and compliance with cybersecurity standards. +- Avoid embedding secrets—manage them using secure secret-management systems. +- Open configuration code, database schemas, and even security‑enforcing code (cryptographic or authentication logic) unless there's a specific reason—noting that openness often strengthens security. +- Use a clear open-source licence, handle versioning (e.g. Semantic Versioning), provide contributing guidelines, manage issues, and encourage community contributions. +- Track changes via version control and prepare to manage security vulnerabilities in public code responsibly. + +## 3. Defence (MOD)‑specific enhancements + +- **Do open code where possible**—unless the code deals with SECRET or TOP SECRET elements. +- **Ensure classification awareness**: assess which parts of the codebase are sensitive and only withhold those as necessary, with intent to open once safe. + +## 4. Summary: Step‑by‑Step Guidance + +| Phase | Actions | +|---------------|-------------------------------------------------------------------------| +| **Planning** | - Define IP and open licensing (e.g., MIT)
- Choose open repo tool within Defence and compliant with cyber policy | +| **Development** | - Code openly from day one
- Exclude secrets and credentials (use secret management)
- Write clear documentation and commit history | +| **Security Review** | - Conduct security checks before publishing
- Remove sensitive content and confirm what may remain closed (e.g., unreleased policy or SECRET parts) | +| **Publishing** | - Release code publicly under an open licence
- Include versioning rules, contributing guidelines, issue tracking | +| **Ongoing Management** | - Continue development openly
- Maintain version control and handle issues transparently
- Monitor and promptly patch security vulnerabilities | + +## 5. Tips & Best Practices + +- **Open by default, closed only for strong reasons** – and open as soon as those reasons no longer apply. +- **Plan for openness from the start** – reducing the burden of retrospectively sanitising code. +- **Favour openness even in security‑critical modules** – properly designed open cryptographic code can be more robust. +- **Use secure development workflows** – store code in trusted repositories, manage secrets separately, and structure your release process to accommodate open-source norms. +- **Provide clear governance** – licences, versioning, contribution policies, and response channels for external collaborators. From 2bb9bfda9196ed7fa2b375e68b07760f38fe88cb Mon Sep 17 00:00:00 2001 From: Paul King Date: Thu, 25 Sep 2025 16:11:04 +0100 Subject: [PATCH 04/13] fix broken links --- using-github/coding-in-the-open.md | 2 +- using-github/readme.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/using-github/coding-in-the-open.md b/using-github/coding-in-the-open.md index d235d28d..c36b6253 100644 --- a/using-github/coding-in-the-open.md +++ b/using-github/coding-in-the-open.md @@ -1,6 +1,6 @@ # How to Meet Section 12: Make New Source Code Open (MOD / GOV.UK Standards) -This guidance explains how teams can meet [**Section 12 – Make New Source Code Open**](https://www.digital.mod.uk/service-manual/meet-the-standard), following both the GOV.UK Service Standard and Defence‑specific considerations from the MOD Service Manual. +This guidance explains how teams can meet [**Section 12 – Make New Source Code Open**](https://www.digital.mod.uk/policy-rules-standards-and-guidance/service-manual/meet-the-standard), following both the GOV.UK Service Standard and Defence‑specific considerations from the MOD Service Manual. ## 1. Why this matters diff --git a/using-github/readme.md b/using-github/readme.md index 87f23e57..53d6b7bc 100644 --- a/using-github/readme.md +++ b/using-github/readme.md @@ -1,6 +1,6 @@ # Our guidance for using GitHub -We should be adhering to the MoD digital service manual and [point 12](https://www.digital.mod.uk/service-manual/meet-the-standard) states that we should be making new source code open. This is an extension of the [GDS guidelines](https://www.gov.uk/service-manual/service-standard/point-12-make-new-source-code-open) in which they talk about [what should be open and what should be closed](https://www.gov.uk/government/publications/open-source-guidance/when-code-should-be-open-or-closed). There is the additional care to be taken with [security classifications](https://www.digital.mod.uk/service-manual/security-classifications) and commercial protections however we should opt for a Public repo on creation unless agreed upon in threat modelling that a closed repo is required. +We should be adhering to the MoD digital service manual and [point 12](https://www.digital.mod.uk/policy-rules-standards-and-guidance/service-manual/meet-the-standard) states that we should be making new source code open. This is an extension of the [GDS guidelines](https://www.gov.uk/service-manual/service-standard/point-12-make-new-source-code-open) in which they talk about [what should be open and what should be closed](https://www.gov.uk/government/publications/open-source-guidance/when-code-should-be-open-or-closed). There is the additional care to be taken with [security classifications](https://www.digital.mod.uk/service-manual/security-classifications) and commercial protections however we should opt for a Public repo on creation unless agreed upon in threat modelling that a closed repo is required. ## Background From df06012b1983055e516d6e272d71e6df77f42d9e Mon Sep 17 00:00:00 2001 From: Paul King Date: Fri, 26 Sep 2025 11:34:26 +0100 Subject: [PATCH 05/13] Update the code copyright policy --- .../CodeCopyright/CodeCopyrightPolicy.md | 11 -- using-github/code-copyright-policy.md | 150 ++++++++++++++++++ 2 files changed, 150 insertions(+), 11 deletions(-) delete mode 100644 software-engineering-policies/CodeCopyright/CodeCopyrightPolicy.md create mode 100644 using-github/code-copyright-policy.md diff --git a/software-engineering-policies/CodeCopyright/CodeCopyrightPolicy.md b/software-engineering-policies/CodeCopyright/CodeCopyrightPolicy.md deleted file mode 100644 index c0574cae..00000000 --- a/software-engineering-policies/CodeCopyright/CodeCopyrightPolicy.md +++ /dev/null @@ -1,11 +0,0 @@ -# Code Copyright Policy - -The topic of copyright and licensing topic is owned by the [National Archives](https://www.nationalarchives.gov.uk/). - -All the code we create is [Crown copyright](https://www.nationalarchives.gov.uk/information-management/re-using-public-sector-information/uk-government-licensing-framework/open-government-licence/open-software-licences/). - -We are encouraged to open source and license our code under the [Open Government License](https://www.nationalarchives.gov.uk/information-management/re-using-public-sector-information/uk-government-licensing-framework/open-government-licence/open-software-licences/), but are given freedom to use another open source license if we think it would promote adoption. - -If we want to open source code we should use the [MIT license as per the policy](https://github.com/UKHO/docs/blob/main/software-engineering-policies/OpenSourceContribution/OpenSourceContributionPolicy.md) (appendix A). This should assert Crown copyright, as per the example “Copyright (C) 2011 Crown copyright (United Kingdom Hydrographic Office)”). - -Where we are not open sourcing, if there is no license explicitly included in a repo then no license is granted. We can just miss out the license file. We should still assert Crown copyright. Since there will be no license file, it should go somewhere prominent like a readme. We don’t need to repeat it in every source file. diff --git a/using-github/code-copyright-policy.md b/using-github/code-copyright-policy.md new file mode 100644 index 00000000..fde5ad22 --- /dev/null +++ b/using-github/code-copyright-policy.md @@ -0,0 +1,150 @@ +# Software Licensing Guidance for Government Projects + +## Overview + +When developing software for government use, it's important to choose appropriate open source licenses that align with the UK Government's Open Source Policy and the Open Government Licence framework. + +## Recommended Open Source Licenses + +The UK Government recommends using well-established, OSI-approved licenses for software projects: + +### **MIT License** + +- **Best for**: Most government software projects +- **Permissions**: Commercial use, modification, distribution, private use +- **Conditions**: Include license and copyright notice +- **Limitations**: No liability or warranty + +### **Open Government Licence v3.0** + +- **Best for**: Government projects containing data, documentation, or software that should align with UK Government policy +- **Permissions**: Commercial use, modification, distribution, private use +- **Conditions**: Include license and copyright notice, acknowledge the source +- **Limitations**: Does not cover personal data, third party rights, or Crown/departmental crests + +## License Selection Guidelines + +### Choose MIT License when + +- Creating simple libraries or utilities +- Maximum adoption and reuse is desired +- Patent issues are not a concern +- You want minimal licensing overhead + +### Choose Open Government Licence v3.0 when + +- Your project contains data or documentation +- You want to align with UK Government's default licensing approach +- Creating mixed content (software, data, and documentation) +- Building government services or platforms + +## Implementation Steps + +1. **Choose your license** based on project requirements +2. **Add LICENSE file** to your repository root +3. **Include copyright headers** in source files +4. **Update README.md** with license information +5. **Ensure compliance** with any dependencies' licenses + +## License File Template + +### For MIT License + +Add a `LICENSE` file to your repository root: + +``` +MIT License + +Copyright (c) [year] Crown Copyright (UK Hydrographic Office) + +Permission is hereby granted, free of charge, to any person obtaining a copy +of this software and associated documentation files (the "Software"), to deal +in the Software without restriction, including without limitation the rights +to use, copy, modify, merge, publish, distribute, sublicense, and/or sell +copies of the Software, and to permit persons to whom the Software is +furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice shall be included in all +copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE +AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, +OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE +SOFTWARE. +``` + +### For Open Government Licence v3.0 + +``` +Open Government Licence v3.0 + +You are encouraged to use and re-use the Information that is available under this licence freely and flexibly, with only a few conditions. + +Using Information under this licence + +Use of copyright and database right material expressly made available under this licence (the 'Information') indicates your acceptance of the terms and conditions below. + +The Licensor grants you a worldwide, royalty-free, perpetual, non-exclusive licence to use the Information subject to the conditions below. + +This licence does not affect your freedom under fair dealing or fair use or any other copyright or database right exceptions and limitations. + +You are free to: +- copy, publish, distribute and transmit the Information; +- adapt the Information; +- exploit the Information commercially and non-commercially for example, by combining it with other Information, or by including it in your own product or application. + +You must (where you do any of the above): +- acknowledge the source of the Information in your product or application by including or linking to any attribution statement specified by the Information Provider(s) and, where possible, provide a link to this licence; + +If the Information Provider does not provide a specific attribution statement, you must use the following: +Contains public sector information licensed under the Open Government Licence v3.0. + +© Crown Copyright (UK Hydrographic Office) +``` + +## README License Section + +### For MIT License + +```markdown +## License + +This project is licensed under the [MIT License](LICENSE) - see the LICENSE file for details. + +© Crown Copyright (UK Hydrographic Office) +``` + +### For Open Government Licence v3.0 + +```markdown +## License + +This project is licensed under the [Open Government Licence v3.0](LICENSE) - see the LICENSE file for details. + +Contains public sector information licensed under the Open Government Licence v3.0. + +© Crown Copyright (UK Hydrographic Office) +``` + +## Important Considerations + +- **Crown Copyright**: Government-developed software is subject to Crown Copyright +- **Third-party dependencies**: Ensure all dependencies have compatible licenses +- **Contributor agreements**: Consider requiring contributor license agreements for external contributions +- **Export controls**: Be aware of any export control restrictions on your software +- **Security review**: Ensure security-sensitive code is reviewed before public release +- **Mixed content**: If your repository contains both software and data/documentation, consider using OGL v3.0 for consistency + +## Resources + +- [UK Government Open Source Policy](https://www.gov.uk/government/publications/open-source-procurement-toolkit) +- [Choose an open source license](https://choosealicense.com/) +- [OSI Approved Licenses](https://opensource.org/licenses) +- [Open Government Licence v3.0](http://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/) + +--- + +*This guidance is based on the UK Government's licensing framework and current best practices for open source software development.* From f1bf8a25ec97fd2c3c099d24f50f8485127569be Mon Sep 17 00:00:00 2001 From: Paul King Date: Fri, 26 Sep 2025 11:52:18 +0100 Subject: [PATCH 06/13] Add context --- using-github/coding-in-the-open.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/using-github/coding-in-the-open.md b/using-github/coding-in-the-open.md index c36b6253..a178b95a 100644 --- a/using-github/coding-in-the-open.md +++ b/using-github/coding-in-the-open.md @@ -26,6 +26,23 @@ This guidance explains how teams can meet [**Section 12 – Make New Source Code - Use a clear open-source licence, handle versioning (e.g. Semantic Versioning), provide contributing guidelines, manage issues, and encourage community contributions. - Track changes via version control and prepare to manage security vulnerabilities in public code responsibly. +#### Closed code + +You should keep some data and code closed, including: + +- keys and credentials +- algorithms used to detect fraud +- unreleased policy + +#### Open code + +You should open all other code. This includes: + +- configuration code +- database schema +- security-enforcing code +More details can be found in the [GDS Guidance- When code should be open or closed](https://www.gov.uk/government/publications/open-source-guidance/when-code-should-be-open-or-closed) + ## 3. Defence (MOD)‑specific enhancements - **Do open code where possible**—unless the code deals with SECRET or TOP SECRET elements. From 9f52ea5cea31cf83b586cc24e5d2e8d5388bf997 Mon Sep 17 00:00:00 2001 From: Paul King Date: Fri, 26 Sep 2025 14:47:43 +0100 Subject: [PATCH 07/13] Update the contributing file guidance --- using-github/coding-in-the-open.md | 2 +- using-github/creating-a-contributing-file.md | 221 +++++++++++++++---- 2 files changed, 179 insertions(+), 44 deletions(-) diff --git a/using-github/coding-in-the-open.md b/using-github/coding-in-the-open.md index a178b95a..30af9e01 100644 --- a/using-github/coding-in-the-open.md +++ b/using-github/coding-in-the-open.md @@ -64,4 +64,4 @@ More details can be found in the [GDS Guidance- When code should be open or clos - **Plan for openness from the start** – reducing the burden of retrospectively sanitising code. - **Favour openness even in security‑critical modules** – properly designed open cryptographic code can be more robust. - **Use secure development workflows** – store code in trusted repositories, manage secrets separately, and structure your release process to accommodate open-source norms. -- **Provide clear governance** – licences, versioning, contribution policies, and response channels for external collaborators. +- **Provide clear governance** – licenses, versioning, contribution policies, and response channels for external collaborators. diff --git a/using-github/creating-a-contributing-file.md b/using-github/creating-a-contributing-file.md index 1ba7939c..a93bdc58 100644 --- a/using-github/creating-a-contributing-file.md +++ b/using-github/creating-a-contributing-file.md @@ -1,48 +1,183 @@ -# Creating a CONTRIBUTING.md file +# The Importance of CONTRIBUTING.md in Open Source Projects -## Overview +## What is CONTRIBUTING.md? -The CONTRIBUTING.md is the file that users will normally read before contributing to a project and it must provide them with the information needed to contribute to the project in a style which the owner wants. The CONTRIBUTING.md allows the owner to specify the standards and processes they want contributors to use thus setting the rules for everyone, including the rules for how the owner treats contributors. The CONTRIBUTING.md is written in [Markdown](https://en.wikipedia.org/wiki/Markdown) and placed in the root directory of the repository. +A `CONTRIBUTING.md` file is a documentation file that serves as a guide for contributors who want to participate in your project. It acts as the first point of contact for potential contributors, explaining how they can help improve your project and in what manner the project owner will allow this. It is important to understand that contributions are not always in the form of code. Make sure that you specify how you wish people to interact and contribute through this file and how they will go about doing this. -### Must Have - -* Repo owner (Can be team or individual) -* Contact details for owner (Email) -* A welcome/intro paragraph. - -### May Have - -* Link to documentation -* Link to issue tracker -* Instructions on how to run tests locally -* Instructions on how to develop code locally -* Pull Request process -* Style guide -* Where a user can find help -* Security issue reporting -* How to report bugs -* How to request a feature -* Code of Conduct -* The recognition model(how people are thanked) -* Philosophy of the project -* Versioning process -* Commit message guidance -* Definition of done -* Roadmap -* Branching conventions -* Anything else that seems relevant - -### Resources - -* [Mozilla tutorial](https://mozillascience.github.io/working-open-workshop/contributing/) - Good guide on creating/thinking about writing a CONTRIBUTING.MD. -* [Template contributing.md](https://gist.github.com/PurpleBooth/b24679402957c63ec426) - Example base template of a CONTRIBUTING.MD. -* [Understanding the InnerSource Checklist](http://paypal.github.io/InnerSourceCommons/assets/files/InnerSourceChecklist.pdf) - pg. 25 - Creating good house rules for guests: Writing contributing agreements. - -### Examples - -* [Atom](https://github.com/atom/atom/blob/master/CONTRIBUTING.md) -* [OpenGovernment](https://github.com/opengovernment/opengovernment/blob/master/CONTRIBUTING.md) -* [Rails](https://github.com/rails/rails/blob/master/CONTRIBUTING.md) -* [GitLab](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md) +## Why is CONTRIBUTING.md Important? + +### 1. Lowers the Barrier to Entry + +* Provides clear instructions for new contributors +* Reduces confusion about how to get started +* Eliminates the need for maintainers to repeatedly answer the same questions + +### 2. Sets Expectations + +* Establishes standards and conventions +* Defines the review process +* Outlines acceptable types of contributions + +### 3. Improves Contribution Quality + +* Ensures consistent style across contributors +* Reduces back-and-forth during reviews +* Helps maintain project architecture and design principles + +### 4. Builds Community + +* Shows that the project welcomes contributions +* Creates a professional impression +* Demonstrates that the project is actively maintained + +## Essential Sections for a CONTRIBUTING.md File + +### 1. Introduction + +```markdown +Thank you for your interest in contributing! This is the purpose of the repository and how you can contribute to this project. +``` + +### 2. Getting Started + +```markdown +## Getting Started + +### Prerequisites +- .NET Core 10 +- Git +- Your favorite code editor + +### Setup +1. Fork the repository +2. Clone your fork: `git clone https://github.com/yourusername/project.git` +3. Install dependencies: `dotnet restore && dotnet build --no-restore` +4. Create a branch: `git checkout -b feature/your-feature-name` +``` + +### 3. Development Guidelines + +```markdown +## Development Guidelines + +The below explains how to run the code and tests. + +### Running the code + +> ```bash +> dotnet watch run +> ``` + +### Running Tests + +> ```bash +> dotnet test +> ``` +``` + +### 4. Contribution Process + +```markdown +## How to Contribute + +### Reporting Bugs +1. Check existing issues first +2. Use the bug report template +3. Include steps to reproduce +4. Add relevant system information + +### Reporting Security Issues +1. Gather any supporting information +2. Send the information to the email address in the [Security](/SECURITY.md) file +``` + +### 5. Code of Conduct + +```markdown +## Code of Conduct + +This project follows the [Contributor Covenant](https://www.contributor-covenant.org/). +Please be respectful and inclusive in all interactions. +``` + +## Best Practices for Writing CONTRIBUTING.md + +### 1. Be Specific and Clear + +* Provide exact commands and steps +* Include expected outputs where helpful +* Use examples to illustrate points + +### 2. Keep it Updated + +* Review and update regularly +* Ensure instructions match current project setup +* Remove outdated information promptly + +### 3. Make it Welcoming + +* Use inclusive language +* Thank contributors for their interest +* Provide multiple ways to contribute + +### 4. Link to Related Resources + +* Reference your Code of Conduct +* Link to issue templates +* Point to documentation and style guides +* Include references to anything of importance to your project that will support contributors + +## Template Structure + +Here's a basic template you can customize: + +```markdown +# Contributing to [Project Name] + +*Owner*: +*contact*: + +Thank you for your interest in contributing! This document outlines the process for contributing to this project. + +## Table of Contents +- [Getting Started](#getting-started) +- [Development Setup](#development-setup) +- [How to Contribute](#how-to-contribute) +- [Code of Conduct](#code-of-conduct) + +## Getting Started +[Instructions for setting up the project] + +## Development Setup +[Environment setup instructions] + +## How to Contribute +[Types of contributions welcomed] + +## Code of Conduct +[Link to or include code of conduct] + +## Recognition +[How is recognition of contribution given] + +## Questions? +[Contact information or links to discussions] +``` + +## GitHub Integration + +GitHub automatically displays your `CONTRIBUTING.md` file when users: + +* Create a new issue +* Open a pull request +* Visit the "Insights" → "Community" tab + +This integration makes your contribution guidelines highly visible and accessible. + +## Conclusion + +A well-crafted `CONTRIBUTING.md` file is essential for any successful open project. It serves as both a technical guide and a welcoming mat for new contributors, helping to build a healthy, collaborative community around your code. + +Remember: the easier you make it for people to contribute, the more likely they are to do so! From 7c0cab8a0767db53d069900f7813af88a5e2a0c1 Mon Sep 17 00:00:00 2001 From: Paul King Date: Fri, 26 Sep 2025 16:04:54 +0100 Subject: [PATCH 08/13] Update OpenSourceContribution to be about open source contribution --- .../OpenSourceContributionPolicy.md | 161 ++++-------------- 1 file changed, 35 insertions(+), 126 deletions(-) diff --git a/software-engineering-policies/OpenSourceContribution/OpenSourceContributionPolicy.md b/software-engineering-policies/OpenSourceContribution/OpenSourceContributionPolicy.md index 18466ae5..39b9eb2a 100644 --- a/software-engineering-policies/OpenSourceContribution/OpenSourceContributionPolicy.md +++ b/software-engineering-policies/OpenSourceContribution/OpenSourceContributionPolicy.md @@ -1,159 +1,68 @@ -# Open Source Contribution - -## Applicability - -This policy must be applied by those: - -- open sourcing UKHO code in public repositories that we control; -- contributing code to open source software which is controlled by others; -- paying others to enhance open source software for our use. - -## Introduction +# Safe Contribution to Open Source Projects We are increasingly making use of open source assets as part of our business infrastructure, as governed by our Use of Open Source Policy. This often requires us to invest in the development, enhancement or integration of those OS assets to meet our specific business requirements. -In line with Government policy and [GDS guidance](https://www.gov.uk/government/publications/open-source-guidance/when-code-should-be-open-or-closed), our default position is that all incremental investments, enhancements and integrations of existing OS assets should be contributed back to the community from which the OS asset was originally sourced. This improves the general quality of the asset for all and makes it more likely that the OS asset concerned will be actively used and maintained in future. - -With regards to bespoke development of complete business applications, algorithms or training data sets, either internally or through a 3rd party, our default position is to retain that IPR for our unique use - unless it is determined that the asset can be released without harming our interests as a commercial entity. Responsibility for agreeing such a release lies with our ExCo and must be formally approved and recorded before release. - -Because of the reputational, security and business risks (detailed below) that can occur as a result of any contribution to the OS community, all releases must adhere to policies laid out below - -Definition of Free Open Source Software - -For the purposes of this policy, free open source software (FOSS) is [as defined by the Open Source Initiative](https://opensource.org/osd). In particular, it: - -- Governed by an Open Source License; -- Free to incorporate in a solution and to redistribute; -- Is available to use and modify as source code - -Risks addressed by this policy - -|​Risk| ​Description | ​Mitigation | -|----| ----------- | ---------- | -| We damage our business by contributing to an OS asset. | We develop valuable IPR (most likely complete software, algorithms, or training data sets) and contribute it to an OS project that damages our business.| No UKHO developed software code, algorithms, data or training data sets should be released into an OS project without specific approval. See Authorisation | -|We attract an inappropriate liability for support of OS assets that we have contributed|Unless properly licensed, it is possible that the UKHO could attract some liability for IP assets that it develops and makes OS. | Only a specified license can be used. See Licensing. | -|Our brand is damaged by delivering poor quality OS asset contributions | Unless properly licensed, it is possible that the UKHO could attract some liability for IP assets that it develops and makes OS. | ur approved OS asset contributions must be produced to the same quality standards as those developed for our own internal use. See Standards| -|We inadvertently breach license terms of other software Most open source software relies on other open source software dependencies. | It is possible to breach the license terms of these dependencies by issuing them under an incompatible license, or not meeting their license terms in some way. |Licensing terms must be carefully managed. See Dependencies.| - -## Ownership of Open Source repositories - -**This section covers the case where we open source some of our own code in a repository that we own and manage e.g. GDS do this by default with their code, where they share software on a dedicated [GDS GitHub page](https://github.com/alphagov).** - -### Authorisation - -The open sourcing of a new piece of software must be authorised by a Lead Engineer. Significant changes to the scope of the software must be re-authorised. - -The Lead Engineer must present a completed "Open Source Goverance Checklist" to a Software Engineering Team Manager in order to demonstrate that sensible precautions have been taken. - -### Platforms - -Only the UKHO Github.com account can be used for creating an open source repository. - -### Reputation - -Contributors must be mindful that our open source software is linked to the UKHO brand through its presence on the UKHO GitHub page. The associated Lead Engineer is accountable for ensuring that that the code, comments, documentation etc. do not contain any inappropriate content. - -### Standards +In line with Government policy and [GDS guidance](https://www.gov.uk/service-manual/service-standard/point-13-use-common-standards-components-patterns), our default position should be that usage and contribution of common components and patterns is preferred over re-inventing the wheel. The aim is to provide users with a good experience through code thats been extensively tested in a cost effective manner. If the need to develop our own component or pattern arises this should be made open to allow others to benefit from our work (where possible). -The repository must match internal standards, including code standards, unit testing, documentation, package names etc. As with internal code, all contributions to an open source repository must be subject to code reviews. - -Additional standards will be applied to open source projects with regards to structure, standard documentation etc. These will be defined by the work to stand up our InnerSource capability[1]. - -An existing Lead Engineer must be assigned to each repository and is accountable for maintaining quality standards. - -### Community support - -The default position is to provide **no** support for consumers of the repositories other than documentation. We should not invite bug reports, or allow pull requests etc. - -Offering any level of support requires the authorisation of the Technology Head of Division. This needs to be carefully considered, as we would have to provide: - -- A governance process; -- Contributor agreements; -- Trusted committers to manage pull requests; -- A bug reporting / triage process; -- Extra security testing of the code; -- Discussion forums. - -### Licensing - -Our open source repositories must be licensed with a standard MIT open source license as per Appendix A. - -### Security - -Security needs to be carefully considered so that: - -- UKHO does not reveal anything that would make its systems vulnerable; -- UKHO takes reasonable steps to not publish code that is inherently insecure; -- UKHO does not accept changes to libraries that make them insecure. - -To this end, [GDS guidelines](https://www.gov.uk/government/publications/open-source-guidance/security-considerations-when-coding-in-the-open) must be followed. - -Dependencies - -Dependent modules in our code must be referenced using config for an appropriate dependency management tool, e.g. a Maven / pom.xml file. Binaries or source of dependencies **must not** be included in the repository. - -## Investment in Open Source +## Introduction -**The section covers the case where we contribute code to open source software that another organisation or community owns and manages.** +Contributing to open source projects can greatly benefit both the contributor and the community. However, it is essential to do so in a manner that safeguards our interests and adheres to established guidelines. This document outlines best practices for contributing to open source projects safely, incorporating insights from the [GDS guidance](https://www.gov.uk/service-manual/service-standard/point-13-use-common-standards-components-patterns). -**For example, there might be a complex framework that almost meets our needs, but it doesn't cater for a data type type we require. We might then add this code ourselves, contributing it back to the codebase. Alternatively we might pay someone else to do this for us.** +## Best Practices for Safe Contributions -### Authorisation +### 1. Understand the Project -Contributing to an open source repository must be authorised by the Technology Head of Division. Significant changes to the scope of the contribution must be re-authorised. +Before contributing, thoroughly review the project's documentation, contribution guidelines, and existing issues. Ensure that the project aligns with our business needs and that contributions will not compromise our intellectual property. The investment in open source will normally take place in the context of a wider project. It will thus be part of that project's overall investment appraisal / business case, as per the Secure Funding goal of the delivery framework. If that is not the case, it represents a separate change and will therefore require a separate business case. -**Any** UKHO developed software code, algorithm, data or training data set could represent valuable intellectual property and should **not** be released into an OS project without specific approval. +### 2. Follow Licensing Requirements -An exception would be a simple bug fix, correcting logic in existing code, which does not have to be authorised. +- Ensure that the open source project is governed by an OSI-approved license. +- Verify that the license allows for the intended use and contribution. +- Obtain necessary approvals from the UKHO Legal Advisor for any contributions that may involve valuable intellectual property (CLA for example). -### Licensing +### 3. Maintain Quality Standards -#### Licenses +Contributions must meet the same quality standards as internal projects. This includes: -The FOSS that the UKHO contributes to **must** be governed by a license. This license **must** be an [OSI-approved license](https://opensource.org/licenses). Since we will be contributing in order to use the enhancement in our own systems, the license is very likely to be on our allowlist of licenses that are approved for use. +- Adhering to coding standards and best practices. +- Writing unit tests to ensure functionality. +- Providing clear documentation for any changes made. -Exceptions must be approved by the UKHO Legal Advisor. +### 4. Avoid Forking -#### Contributor agreements +Forking a project and making changes without contributing back is discouraged. This practice can lead to security and maintenance issues. Always aim to contribute enhancements back to the original project. -Open source contributor license agreements (CLAs) define the terms that intellectual property is contributed to a project. Therefore: +### 5. Secure Approval for Contributions -- A CLA **must** exist; -- Contribution under that CLA must have been approved by the UKHO Legal Advisor; -- The CLA must be recorded and kept by DS&T. +- Obtain authorization from the Technology Head of Division before contributing to any open source repository. +- For significant changes, re-authorization is required. -Exceptions must be approved by the Head of DS&T. +### 6. Limit Support and Engagement -#### Evaluating investment +The default position is to provide minimal support for open source contributions. Avoid inviting bug reports or pull requests unless explicitly authorized. If support is necessary, ensure that a governance process is in place. -The investment in open source will normally take place in the context of a wider project. It will thus be part of that project's overall investment appraisal / business case, as per the Secure Funding goal of the delivery framework. If that is not the case, it represents a separate change and will therefore require a separate business case. +### 7. Protect Sensitive Information -#### Procurement +Be cautious not to disclose any sensitive or proprietary information in contributions. Follow security guidelines to ensure that no vulnerabilities are introduced into the codebase. -Paying a supplier to make enhancements to an open source codebase is a procurement exercise. It **must** be carried out through the UKHO Procurement team, who will ensure that the business is competed where appropriate, full long-term costs are considered, etc. +### 8. Document Contributions -#### Forking +Maintain thorough documentation of all contributions, including: -[Forking](https://en.wikipedia.org/wiki/Fork_(software_development)) FOSS and making changes which we do not contribute back to the open codebase is **not** permitted because it exposes UKHO to problems of security and maintenance. Exceptions must be approved by the Head of TPE. +- The purpose of the contribution. +- Any approvals obtained. +- The licensing terms under which the contribution is made. -#### Personal contributions to open source +### 9. Personal contributions to open source All contributions that relate directly to an engineer's work at the UKHO or relate to the UKHO's business (e.g. marine geospatial systems, information for the mariner) are subject to this policy, even if they are carried out on an engineer's own equipment or in their own time. Otherwise, engineers are free to contribute to open source projects. -### Appendix A - UKHO license file text - -The following license should accompany all code which the UKHO open sources. - -```text -The MIT License (MIT) +### 10. Procurement -Copyright (C) 2011 Crown copyright (United Kingdom Hydrographic Office) - -Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: +Paying a supplier to make enhancements to an open source codebase is a procurement exercise. It **must** be carried out through the UKHO Procurement team, who will ensure that the business is competed where appropriate, full long-term costs are considered, etc. -The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. +## Conclusion -THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. -``` +By adhering to these best practices, we can contribute to open source projects in a manner that is safe, responsible, and beneficial to both our organization and the wider community. Always prioritize quality, compliance, and security in every contribution. From 252d56f47d905d5f38c33740c5d389342749a2b8 Mon Sep 17 00:00:00 2001 From: Paul King Date: Fri, 26 Sep 2025 16:24:21 +0100 Subject: [PATCH 09/13] Update the governance checklist --- .../OpenSourceGovernanceChecklist.md | 58 +++++++++---------- using-github/coding-in-the-open.md | 4 ++ 2 files changed, 31 insertions(+), 31 deletions(-) diff --git a/software-engineering-policies/OpenSourceContribution/OpenSourceGovernanceChecklist.md b/software-engineering-policies/OpenSourceContribution/OpenSourceGovernanceChecklist.md index 9c00889c..c541c5de 100644 --- a/software-engineering-policies/OpenSourceContribution/OpenSourceGovernanceChecklist.md +++ b/software-engineering-policies/OpenSourceContribution/OpenSourceGovernanceChecklist.md @@ -1,59 +1,55 @@ -# Open Source Governance Checklist +# Repository Visibility Change Governance Checklist + +The purpose of this checklist is to ensure before changing a repository from private/internal to public the necessary due diligence has been performed. Support for this checklist can be sought from the Lead Tech (Security) ## Identifier -(e.g. repo name) + + ## Technical owner -The lead responsible for the repo + + ## Description of functionality -Must contain enough detail to allow assessment of whether it contains intellectual property that we need to protect. + ## Security -*How has security been considered?* +### Has this been assigned to the correct team -Has application code been scanned with security tooling and issues corrected? -> This must be done for code supported by our SAST tooling + -Has the application been threat modelled during development and the evidence captured within TFS (or similar)? -> Threat modelling must be carried out for all application code, this evidence needs to be reviewed by expert or lead engineer +### Does this repository have an active pipeline -Has the code been double-checked for security credentials, keys etc.? -> Give details of who has double-checked the code + -Is a disclosure process in place and linked from the codebase? -> Use the standard disclose text +### Has this repository had a clean secret scan -## Quality + + +### Has the SECURITY.md been updated -*How has code quality been considered?* + + +## Quality -Does the quality of the code reflect our ambitions for high quality code, in terms of being clean, well-tested etc. -> Correct answer = yes! +### Has a code review been performed -Has all code been reviewed? -> Correct answer = yes! + -Has the open-sourced codebase had its history removed? If not, have all check-in comments been reviewed? -> Describe the steps taken to prevent inadvertent disclosed in comments / etc. +### Is there a coherent Readme -Does the codebase contain all documentation and configuration elements required to build and verify the software? -> A user should be able to build / run tests etc. based on what is in the repo + ## Contributions -*Has the handling of contributions considered?* +### Has the CONTRIBUTIONS.md been updated -Are contributions explicitly encouraged in the codebase -> For example, have you enabled the use of issues and provided a CONTRIBUTING.md? -> Think very carefully before inviting change, as you will then have to answer 'yes' to the next two questions + -Is a process for responding to issues defined? -> Describe in detail the process by which you are going to ensure that issues are responded to in a timely manner +### Is there a process in place for dealing with issues -How is this process resourced? -> Describe how you have made sure that time is available to carry out the process described above. For example, has the relevant manager agreed for time for time to spent on this? + diff --git a/using-github/coding-in-the-open.md b/using-github/coding-in-the-open.md index 30af9e01..fae6476b 100644 --- a/using-github/coding-in-the-open.md +++ b/using-github/coding-in-the-open.md @@ -65,3 +65,7 @@ More details can be found in the [GDS Guidance- When code should be open or clos - **Favour openness even in security‑critical modules** – properly designed open cryptographic code can be more robust. - **Use secure development workflows** – store code in trusted repositories, manage secrets separately, and structure your release process to accommodate open-source norms. - **Provide clear governance** – licenses, versioning, contribution policies, and response channels for external collaborators. + +## 6. Opening a close repository + +In the case where a repository is available to be made open, it is required that a team lead fills in the [checklist](/software-engineering-policies/OpenSourceContribution/OpenSourceGovernanceChecklist.md) with the necessary details. This request can then be processed in the development portal. From 9d4eb5656f81151020574e12062176f9d069b213 Mon Sep 17 00:00:00 2001 From: Paul King Date: Wed, 22 Oct 2025 10:45:15 +0100 Subject: [PATCH 10/13] Fix bad linting --- using-github/creating-a-contributing-file.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/using-github/creating-a-contributing-file.md b/using-github/creating-a-contributing-file.md index a93bdc58..216b262a 100644 --- a/using-github/creating-a-contributing-file.md +++ b/using-github/creating-a-contributing-file.md @@ -1,12 +1,12 @@ # The Importance of CONTRIBUTING.md in Open Source Projects -## What is CONTRIBUTING.md? +## What is CONTRIBUTING.md A `CONTRIBUTING.md` file is a documentation file that serves as a guide for contributors who want to participate in your project. It acts as the first point of contact for potential contributors, explaining how they can help improve your project and in what manner the project owner will allow this. It is important to understand that contributions are not always in the form of code. Make sure that you specify how you wish people to interact and contribute through this file and how they will go about doing this. -## Why is CONTRIBUTING.md Important? +## Why is CONTRIBUTING.md Important ### 1. Lowers the Barrier to Entry From 967c2791462aa6346d3b4b3f674c84d350d0305b Mon Sep 17 00:00:00 2001 From: Paul King Date: Wed, 22 Oct 2025 11:27:41 +0100 Subject: [PATCH 11/13] Minor spelling mistakes --- using-github/code-copyright-policy.md | 2 +- using-github/coding-in-the-open.md | 8 +++++--- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/using-github/code-copyright-policy.md b/using-github/code-copyright-policy.md index fde5ad22..40f20dbc 100644 --- a/using-github/code-copyright-policy.md +++ b/using-github/code-copyright-policy.md @@ -2,7 +2,7 @@ ## Overview -When developing software for government use, it's important to choose appropriate open source licenses that align with the UK Government's Open Source Policy and the Open Government Licence framework. +When developing software for government use, it's important to choose appropriate open source licenses that align with the UK Government's Open Source Policy and the Open Government License framework. ## Recommended Open Source Licenses diff --git a/using-github/coding-in-the-open.md b/using-github/coding-in-the-open.md index fae6476b..c1b91aa1 100644 --- a/using-github/coding-in-the-open.md +++ b/using-github/coding-in-the-open.md @@ -15,7 +15,7 @@ This guidance explains how teams can meet [**Section 12 – Make New Source Code ### GOV.UK expectations - Write code in the open from the start, using a public repository—but never include secrets like API keys or credentials. -- Always retain IP ownership of your service’s new code and license it openly (e.g., MIT or another Open Source Initiative–compatible licence). +- Always retain IP ownership of your service’s new code and license it openly (e.g., MIT or another Open Source Initiative–compatible license). - If code must remain closed (e.g., unreleased policy or sensitive security mechanisms), provide a strong rationale—but open it as soon as permissible. ### Additional GOV.UK technical guidance @@ -23,7 +23,7 @@ This guidance explains how teams can meet [**Section 12 – Make New Source Code - Host code publicly (e.g., GitHub), ensuring departmental control and compliance with cybersecurity standards. - Avoid embedding secrets—manage them using secure secret-management systems. - Open configuration code, database schemas, and even security‑enforcing code (cryptographic or authentication logic) unless there's a specific reason—noting that openness often strengthens security. -- Use a clear open-source licence, handle versioning (e.g. Semantic Versioning), provide contributing guidelines, manage issues, and encourage community contributions. +- Use a clear open-source license, handle versioning (e.g. Semantic Versioning), provide contributing guidelines, manage issues, and encourage community contributions. - Track changes via version control and prepare to manage security vulnerabilities in public code responsibly. #### Closed code @@ -33,6 +33,8 @@ You should keep some data and code closed, including: - keys and credentials - algorithms used to detect fraud - unreleased policy +- Commercially sensitive +- Intellectual Property not owned by UKHO #### Open code @@ -61,7 +63,7 @@ More details can be found in the [GDS Guidance- When code should be open or clos ## 5. Tips & Best Practices - **Open by default, closed only for strong reasons** – and open as soon as those reasons no longer apply. -- **Plan for openness from the start** – reducing the burden of retrospectively sanitising code. +- **Plan for openness from the start** – reducing the burden of retrospectively sanitizing code. - **Favour openness even in security‑critical modules** – properly designed open cryptographic code can be more robust. - **Use secure development workflows** – store code in trusted repositories, manage secrets separately, and structure your release process to accommodate open-source norms. - **Provide clear governance** – licenses, versioning, contribution policies, and response channels for external collaborators. From e26026f93fa4ca9ea9fc89fe8881fdb87819d6ce Mon Sep 17 00:00:00 2001 From: Paul King <6100643+gyro2009@users.noreply.github.com> Date: Tue, 11 Nov 2025 16:57:50 +0000 Subject: [PATCH 12/13] Update based on PR feedback --- .../OpenSourceContribution/OpenSourceGovernanceChecklist.md | 6 +++--- using-github/coding-in-the-open.md | 4 +++- ...ode-copyright-policy.md => software-licensing-policy.md} | 4 +++- 3 files changed, 9 insertions(+), 5 deletions(-) rename using-github/{code-copyright-policy.md => software-licensing-policy.md} (92%) diff --git a/software-engineering-policies/OpenSourceContribution/OpenSourceGovernanceChecklist.md b/software-engineering-policies/OpenSourceContribution/OpenSourceGovernanceChecklist.md index c541c5de..696c5ef4 100644 --- a/software-engineering-policies/OpenSourceContribution/OpenSourceGovernanceChecklist.md +++ b/software-engineering-policies/OpenSourceContribution/OpenSourceGovernanceChecklist.md @@ -10,15 +10,15 @@ The purpose of this checklist is to ensure before changing a repository from pri ## Technical owner - + ## Description of functionality - + ## Security -### Has this been assigned to the correct team +### Has this been assigned to the correct team? diff --git a/using-github/coding-in-the-open.md b/using-github/coding-in-the-open.md index c1b91aa1..2c01071e 100644 --- a/using-github/coding-in-the-open.md +++ b/using-github/coding-in-the-open.md @@ -36,6 +36,8 @@ You should keep some data and code closed, including: - Commercially sensitive - Intellectual Property not owned by UKHO +These items will usually be identified early in the product lifecycle with support from your product owner and cyber security team. If you are unsure if your code should be open or closed then it is important to organize a session to work through this. + #### Open code You should open all other code. This includes: @@ -68,6 +70,6 @@ More details can be found in the [GDS Guidance- When code should be open or clos - **Use secure development workflows** – store code in trusted repositories, manage secrets separately, and structure your release process to accommodate open-source norms. - **Provide clear governance** – licenses, versioning, contribution policies, and response channels for external collaborators. -## 6. Opening a close repository +## 6. Opening a closed repository In the case where a repository is available to be made open, it is required that a team lead fills in the [checklist](/software-engineering-policies/OpenSourceContribution/OpenSourceGovernanceChecklist.md) with the necessary details. This request can then be processed in the development portal. diff --git a/using-github/code-copyright-policy.md b/using-github/software-licensing-policy.md similarity index 92% rename from using-github/code-copyright-policy.md rename to using-github/software-licensing-policy.md index 40f20dbc..8aee69c5 100644 --- a/using-github/code-copyright-policy.md +++ b/using-github/software-licensing-policy.md @@ -2,7 +2,9 @@ ## Overview -When developing software for government use, it's important to choose appropriate open source licenses that align with the UK Government's Open Source Policy and the Open Government License framework. +When developing software for government use, it's important to choose appropriate open source licenses that align with the UK Government's Open Source Policy and the Open Government License framework. No matter the visibility of the repository you should select a license to support the project you are working on to protect the project in case of visibility change. + +It is important that we include a LICENSE file with the relevant contents within the repository so that GitHub can correctly pick up the license in which we are publishing our code with. It is also advised to add a section at the bottom of the README.md for the relevant license type so that it is visible for anybody viewing the repository. ## Recommended Open Source Licenses From 061bdf321cb67e100a47fb51bfed1488df4c21cb Mon Sep 17 00:00:00 2001 From: Paul King <6100643+gyro2009@users.noreply.github.com> Date: Tue, 11 Nov 2025 17:06:11 +0000 Subject: [PATCH 13/13] Updated based on further feedback --- .../OpenSourceContribution/OpenSourceGovernanceChecklist.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/software-engineering-policies/OpenSourceContribution/OpenSourceGovernanceChecklist.md b/software-engineering-policies/OpenSourceContribution/OpenSourceGovernanceChecklist.md index 696c5ef4..1b752a6e 100644 --- a/software-engineering-policies/OpenSourceContribution/OpenSourceGovernanceChecklist.md +++ b/software-engineering-policies/OpenSourceContribution/OpenSourceGovernanceChecklist.md @@ -18,7 +18,7 @@ The purpose of this checklist is to ensure before changing a repository from pri ## Security -### Has this been assigned to the correct team? +### Has this been assigned to the correct team @@ -48,7 +48,7 @@ The purpose of this checklist is to ensure before changing a repository from pri ### Has the CONTRIBUTIONS.md been updated - + ### Is there a process in place for dealing with issues