Conversation
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
|
It maybe worth updating the open source governance check list (and/or referencing it somewhere in these docs): |
|
The Source Control Policy should also probably be updated to clearly indicate open by default, and provide links to the other relevant policy and guidance? |
nevillejrbrown
left a comment
nevillejrbrown
left a comment
There was a problem hiding this comment.
Here's a few bits of feedback...
|
|
||
| ## 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. |
There was a problem hiding this comment.
This page needs to give advice on what license we should use if it's not being open sourced. I think the answer is don't give it any license, but I think this needs to be spelled out here somewhere.
There was a problem hiding this comment.
I would always advise adding a license to your repository no matter where your coding just to give you that flexibility if you need to change the visibility. I will add something in :)
There was a problem hiding this comment.
But what if you specifically don't want to license it? This is possible, e.g. in the case of commercially sensitive contend. We need to keep that option open I think.
nevillejrbrown
left a comment
nevillejrbrown
left a comment
There was a problem hiding this comment.
Thanks for making the changes :-)
nevillejrbrown
left a comment
nevillejrbrown
left a comment
There was a problem hiding this comment.
Actually I think we need to resolve the licensing conversation. Do you want to discuss on a call?
| 4. Publish the repository and continue development in the open | ||
|
|
||
| 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 | ||
| If a team believes their code **cannot** be made open, they must provide a documented rationale with a specific reason from the approved list (see [Coding in the Open – Closed code](../../using-github/coding-in-the-open.md)) and record the expected date for opening. This must be reviewed at each service assessment. |
There was a problem hiding this comment.
Is this for new code only, or does this apply to legacy codebases?
| ## Ownership of Open Source repositories | ||
| - 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). |
There was a problem hiding this comment.
"UKHO Legal Advisor": Does such a person exist?
| ### 5. Secure Approval for Contributions | ||
|
|
||
| ### Reputation | ||
| - Obtain authorization from the Technology Head of Division before contributing to any open source repository. |
There was a problem hiding this comment.
Seems a bit senior for this. This is a relic of a previous HoD who was very nervous about this. Perhaps could be Head of Engineering...?
| - **SECRET or TOP SECRET content (MOD-specific)** – code that directly relates to classified systems or content at these markings must not be published | ||
| - **Third-party intellectual property not licensed for open publication** – code, algorithms, or data owned by a vendor or third party where the licence does not permit open redistribution | ||
|
|
||
| > **Note on "commercially sensitive" code:** Commercial sensitivity alone is **not** a valid reason under GDS or MOD guidance to keep code closed. If a team believes code is commercially sensitive, this must be assessed case-by-case with the product owner, security champion, and legal adviser. A clear and documented rationale must be provided — see [Providing a rationale for closed code](#providing-a-rationale-for-closed-code) below. |
There was a problem hiding this comment.
"Note on "commercially sensitive" code: Commercial sensitivity alone is not a valid reason under GDS or MOD guidance to keep code closed."
I don't think this statement is relevant. Isn't that just because these organisations don't think about commercial concerns? Surely commercial sensitivity is a concern for UKHO...?
| - identify the specific subset of code that must remain closed (do not close entire repositories unnecessarily) | ||
| - name the applicable reason from the list above | ||
| - state the expected date or condition under which the code can be opened | ||
| - be recorded in the repository's README or a linked document, and reviewed at each service assessment |
There was a problem hiding this comment.
We don't do service assessments. This is a GDS thing.
| * [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) | ||
| # The Importance of CONTRIBUTING.md in Open Source Projects |
There was a problem hiding this comment.
Do we give guidance anywhere about when to accept contributions? In some (a majority of?) cases, external contribution would be unwelcome.
If we do accept contributions (and have an CONTRIBUTING.md), what is the guidance about managing this work, bearing in mind all the teams manage most of their work on AzDo and (I think) don't typically process GitHub issues.
3 participants
No description provided.