canada-ca / open-source-logiciel-libre

Open Source Software Requirements and Guidance (Draft) - Exigences et guides liés aux logiciels libres (Ébauche)

(Français)

Open Source Software

Treasury Board of Canada Secretariat’s draft standards to support the implementation of Treasury Board policy requirements related to open source use, contribution and creation.

The Government of Canada has been using Open Source Software as part of its technology ecosystem for years and is increasingly relying on them for its successful service delivery. As part of its commitment to become a digital government, it has to also contribute back to external projects as well as release its own source code under Open Source Licences. It is committed to doing so in a manner that is compatible with core administrative law principles such as transparency, accountability, legality and procedural fairness.

Other Information

For the purpose of the current drafts, the Standard template has been chosen to start the discussion. The final format may vary.

English Content

• OSS Standards

Translation

During this drafting period, translation is being done manually and continuously by contributors as well as with the following tools and services:

• Termium Plus
• Google Translate
• Deepl Translator

Official translation will be done once a first version is completed.

References

• Canada
  • Government of Canada: Directive on Management of Information Technology (§C.2.3.8)
  • Montréal City (EN):
    • Policy concerning the use and development of Open Source Software and Hardware
    • Directive on contributing to an Open Source Project
    • Directive on Publication and Maintenance of an Open-Source Municipal Project
• France (EN): DINSIC Open-source contribution policy
• United Kingdom Governement Digital Service (EN): Making source code open and reusable
  • Government Digital Services (EN): Guidelines
• United States of America (EN):
  • Federal Source Code Policy
  • 18F
• Linux Foundation (EN): Guides
  • TODO Group (EN):
    • Guides
    • Open Source Policy Examples and Templates
• Google (EN): Open Source Policy
• SUSE (EN): SUSE Open Source Policy
• Zalando (EN): OPEN SOURCE RULES AND STRATEGY

---

Logiciels libres

Ébauche des exigences et guides liés à l'utilisation, à la contribution et la création des logiciels libres au Gouvernement du Canada.

Le gouvernement du Canada utilise les logiciels libres dans le cadre de son écosystème technologique depuis des années et compte de plus en plus sur eux pour assurer le succès de ses services. Dans le cadre de son engagement à devenir un gouvernement numérique, elle doit également contribuer à des projets externes et publier son propre code source sous licence Open Source. Elle s'engage à le faire d'une manière compatible avec les principes fondamentaux du droit administratif tels que la transparence, la responsabilité, la légalité et l'équité procédurale.

Pour l'exercice d'ébauche, le format du Standard a été utilisé pour commencer la discussion. Le format final pourrait changer.

Contenu français

• Guides
  • Utilisation de logiciels libres
  • Contribution aux logiciels libres
  • Publication de code source libre

Traduction

Durant la période d'ébauche, la traduction du contenu est faite de façon manuelle et continuelle par les contributrices et les contributeurs ainsi qu'avec l'aide des outils et services suivants:

• Termium Plus
• Google Translate
• Deepl Translator

La traduction officielle sera effectuée une fois la première version terminée.

Références

• Canada
  • Gouvernement du Canada: Directive sur la gestion des technologies de l'information (§C.2.3.8)
  • Ville de Montréal (FR):
    • POLITIQUE SUR L’UTILISATION ET LE DÉVELOPPEMENT DES LOGICIELS ET DU MATÉRIEL LIBRES
    • Directive sur la publication et le maintien d’un projet Ville en libre
• France (FR): Politique de contribution open-source de la DINSIC
• Gouvernement de la Grande-Bretagne (EN): Making source code open and reusable
  • Services numériques gouvernementaux (EN): Guidelines
• Gouvernement fédéral des États-Unis d'Amérique (EN):
  • Federal Source Code Policy
  • 18F
• Fondation Linux (EN): Guides
  • Groupe TODO (EN):
    • Guides
    • Exemples et canevas de politique de logiciels libres
• Google (EN): Politiques de logiciels libres
• SUSE (EN): Politique de logiciels libres SUSE
• Zalando (EN): Règles et stratégie pour les logiciels libres

open-source-logiciel-libre's Issues

Using "should" instead of "must"

In Guide for Publishing Open Source Code (Draft), there are some statements that have "must" in them. Since this is a guide, you may want to consider switching some of them to "should" (where appropriate):

Here are some possibilities:

1. Source code must include a licence before publishing to a public source code repository. Include a licence by adding a LICENSE file as part of source code.
2. Before publishing, source code must include: (also the heading has Mandatory in it)
3. Employees must use their full name and Government of Canada email address for all code contributions to public repositories while acting within the scope of their duties or employment.

We discussed previously that item number 3 should probably be switched to a "should", but you should also consider whether 1 and 2 should be changed to "should" as well (depends if they are actually mandaotry as well).

Guidance on engaging the community for contributions

For section: https://github.com/canada-ca/open-source-logiciel-libre/blob/master/en/guides/contributing-to-open-source-software.md#verify-contributing-process-and-policies

Is there a need to mention any GC requirements for business review of intended contribution to ensure IP protection? For example, guidance can say any bug fixes, don't require GC business review. However, for any substantial contributions that include new features, a chat with GC business leader/legal team may be required?

Add some additional guidance on how to contribute with impact. Questions to ask such as:

• What are the coding conventions of this community?
• Is there a roadmap that includes your direction?
• Has your proposal come up before?
• Is the project actively maintained?

For small changes including bug fixes --> simple pull requests
For large contributions --> engage community first to understand their interest and get any feedback before spending significant time and effort on the contribution
Communities may have different forms of engagement: creating an issue in GitHub, mailing list, Slack channel or some discussion channel

Seperate sections for open source owned by GC and contribution to OSS not owned by GC

The requirements for GC employees contributing to GC owned projects probably should be different than those for GC employees contributing to project not owned by the GC. Should this document make that distinction?

Add R and Python to the Open Resource Exchange

https://canada-ca.github.io/ore-ero/open-source-software.html

Add new files to navigation

New documents were added, but aren't reflected in navigation

IP still belongs to the Crown?

So I'm not sure how

IP still belongs to the Crown

applies. Say if there's a bug in Drupal. That's already GPL. If you're contributing to that project it will be under the GPL license. There is no way that the Drupal community is going to track a patch that that is dual licensed or licensed under anything other than a GPL compatible license.

Can we remove this from https://github.com/canada-ca/open-source-logiciel-libre/blob/master/en/guides/contributing-to-open-source-software.md

Considerations for Open Source Software Evaluation

Some of the folks in my group have been looking at how to Evaluate Open source software and have identified some areas of concern . Its a bit much for me to break apart so I wanted to just upload the doucment. I asked the document author for permission and he gave it.

I hope some of it is useful or can create spin off discussions

Introduction

When evaluating open source software, as with commercial software, there should be two primary considerations: functionality and total cost of ownership. Together the overall value of the software can be evaluated. However the value of open source software may come in a different form than commercial software. The following discussion considers the key issues for evaluating open source software vs. commercial software. It has been assembled from various online blogs and forums.

Considerations

The first consideration is that open source software tends to have narrowly focused functionally. There is an expectation users will integrate and manage multiple products together to create a solution. A large open source solution commonly requires one or more core products and 3rd-party plugins. The work of integration, support, and management tends to fall more on the user than with commercial software. This may not be a concern if in-house expertise is valued as part of the solution.

Second, access to support needs to be considered. The quality of open source updates, documentation, and forums will differ by product from excellent to non-existent. However most open source products do not provide a contractual means by which a specific question can be answered or update obtained in a timely manner. This tends to be a greater issue early in a solution’s lifecycle therefore significant lab testing can help offset concerns in this area. Some companies offer commercial support for open source software however this rarely covers all parts of an integrated solution.

The final major consideration is the benefits of open source software. The most obvious relate to acquisition and deployment. While open source software will have an attached license, they generally allow free acquisition and deployment without restriction. Open source software tends to provide ease of integration through open APIs, data exchange tools, and open storage formats. Also, open source software allows full access to the source code for ease of inspection and modification. For these reasons open source software tends to allow flexibly to scale and change the solution to meet future needs and reduce product lock-in.

Evaluation

When evaluating open source software the availability of information presents a barrier. Unlike commercial software, most open source projects do not have a sales and marketing team creating easy to consume information. This poses a challenge and may require searching the internet for secondary sources, reading technical documentation, and lab testing.

In general, open source functionally should be evaluated in the same manner as other software. Beyond functionality, the key questions are: can the solution be managed, is support available, and do the benefits lead to best value? While these questions apply to commercial software, they have increased relevance for open source and can be harder to answer. The questions below provide a roadmap to answering these larger questions for open source software.

1. What open source product(s) are needed to meet the requirements?
2. Integrating a large number open source products may meet requirements but cause other problems. Can the same requirements be met with a less complex solution?
3. Many open source products assume an industry standard environment. Can the requirements be changed to match industry standards and allow open source products to work with less integration or modification?
4. Can integration be accomplished with open APIs or a well defined plug-in architecture?
5. Is data stored in an easy to manipulate (import/export/inspection/migration) format?
6. Are the APIs and storage formats used by other products and do they use open standards?
7. What are the license restrictions?
8. Are the products normally used in the proposed manner?
9. How large is the user base and is it growing or shrinking?
10. Are there other users, similar to you, using similar solutions?
11. Who is the developer and are they likely to continue with the project? E.g single developer, research group, small company, tech giant, consortiums, …
12. Is one group the only significant contributor?
13. Is one group clearly limiting features? For example, is there one company that is the primary contributor and also offers a commercial “enterprise” version? If so, are they doing so in a logical manner and what would the long term impact be?
14. Does the project have rules for contributing that are supportive of community contributions?
15. Are proposed enhancements from 3rd-partys (pull requests) left unresolved?
16. Does the project follow a documented release management process?
17. Are all parts of the solution released and tested together?
18. Does a recent Long Term Support (LTS) release exist? Is so, what is the planned support duration?
19. Has the project been forked? If so, are the forks taking away from the main project or contributing to it?
20. Are bugs public? Is so, are bugs left unresolved for long periods?
21. Are security related bugs resolved quickly with easy to deploy patches?
22. Is documentation complete and up to date?
23. Are there bugs related to documentation and are they resolved in a timely manner?
24. Are their secondary sources of documentation, tutorials, etc.?
25. Is there a dedicated and active community support forum? What is the tone of the forum? Are forums limited in any way such that you may be forced to buy support or an enterprise version?
26. Is commercial support available? Is so, is it available from more then one source? Is commercial support available from someone other than the primary contributor?
27. Can the product(s) be tested in a lab environment?
28. Do we already have in-house expertise or can it be developed? What will the cost be?

Users who wish not to disclose their emails

With:

Employees must use their full name and Government of Canada email address for all code contributions to public repositories while acting within the scope of their duties or employment.

What do we do if GC employees are facing harassment online? There are people out there who have good reasons to not want to publicly share their full name and email address. Can they not contribute under an alias as they might well be doing already? Not sure why this is in here.

Obtaining Rights to Custom Code in Contracts

Wow, we've got a long ways to go with open source adoption. How on earth is this not the other way around. If any contractor wants to own the IP that should be the exception, not the norm. How are we expecting innovation to happen in Canada if we keep locking up our IP in 3rd party staffing agencies and USA owned companies?

Just noting this as a major policy hurdle.

https://github.com/canada-ca/open-source-logiciel-libre/blob/master/en/guides/publishing-open-source-code.md#obtain-rights-to-custom-code-in-contracts

Nix Gcdevexchange reference

Would be good to remove https://gcdevexchange-carrefourproggc.org/ until it is actually an option.

I do wonder if it is worth mentioning that managers may have the ability to buy support for open source tools for under $10k on their credit card. There is lots of work that could be fairly informally done this way.

Include an opening on what is Open Source?

Could link to Open Source Definition on Wikipedia and also give a short description.

Example:
Open Source is a software development practice that allows you to example, modify and redistribute modified source code and use the software however one wishes. As long as the source code is open, the provider doesn't have to provide the following and can charge for:

• Customer Support
• Cloud Based Services
• Managed Solutions for Large Scale Deployments
• Packaged Software (software you don't have to compile from the source)
• UI using artwork/typeface (art is not software)

IP still belongs to the Crown

Looking here https://github.com/canada-ca/open-source-logiciel-libre/blob/master/en/guides/contributing-to-open-source-software.md#other-notes

So how would someone submit a patch, module, documentation or a theme to Drupal.org if in the end "IP still belongs to the Crown". There is nothing which allows you to specify this in Drupal.org

https://www.drupal.org/about/licensing
https://www.drupal.org/docs/user_guide/en/copyright.html

If you want to submit a whole new project on GitHub, knock your socks off. However, existing projects have licenses already which usually aren't the Crown (or at least not ours).

Additional guidance in Open Resource Exchange section

Consider adding why folks should consider registering their use of open source tech in the Open Resource Exchange - and is it required for some sort of internal compliance/governance at GoC?

Example:
All uses of open source, including versions and dependencies, must be registered/noted. Any development tools or runtimes used on your machine, eg. editors, not required, to be registered.

Reasons for requesting registering may include:
GoC is working towards automation and tracking scenarios of open source usage at GoC and this information is extremely important for security teams.

Documentation or transparency on the use of open source?

Should there be a publish and record of all open source libraries being used across GC? As an example, sharing how this is currently maintained for Microsoft projects: https://3rdpartysource.microsoft.com/

Should/will 2FA (2 factor authentication) be required for making GitHub contributions

https://help.github.com/articles/about-two-factor-authentication/

Additional publishing open source guidance

For section: https://github.com/canada-ca/open-source-logiciel-libre/blob/master/en/guides/publishing-open-source-code.md#guide-for-publishing-open-source-code-draft

In addition to the GC review before publishing, you may want to include some scrubbing guidance. Unless an individual/department started a project with the intent of releasing an initially private repository, they may need to consider the following:

• adding source code headers that include copyright/license information
• scrubbing the code and comments for any references to internal/confidential information such as internal paths, tools, code names, email addresses, etc.
• Pushing history may contain credentials, prorietary code, and undesirable comments/references --> one can either start with a clone of a new repo and then copy in source files or use other techniques to get the same effect
• Additionally, instead of flipping a private repository to public, one should consider deleting a repo and recreating it (can help remove any sensitive information in issues, PRs, comments, code reviews, wiki pages, etc.) - cleaning up manually may be too difficult and be aware of any hidden data, eg. each repo stores last 300 events - so there may be sensitive data in event timelines if only the visible information is scrubbed
• You may need to check for other open source in your project - are you redistributing something as part of your project? And list the appropriate GC action, such as legal review, required for this scenario

Official Languages - Langues officielles

Feedback has highlighted that requiring projects to be fully bilingual (from source code comments, to configuration documentation, user interface, API references, training material, etc.) could discourage the community in open sourcing their projects. Maintaining project documentation up-to-date is already a challenge for development teams in general, having to maintain bilingual versions of everything related to a project may create further resistance and lead to no projects being outsourced or .

As such, we need to find the right balance in being compliant with the Official Languages policies and enable the projects team in thriving with their development.

To be confirmed/clarified:

• What should and shouldn't be bilingual in an open source project?

To note: I believe that having a project with localization incorporated in its development when applicable should be seen as an advantage to build a large multi-cultural and inclusive user base and community. That being said, source code and comments found within shouldn't be subject to Official Languages. The rest of a project should abide to the same principles any other information technology project, including proprietary solutions, has to be subject to, including end-user documentation in official languages.

From my personal experience, anything that is to be used by a non-technical end-user should be bilingual: Graphical User Interface (exclude command-line), End-user documentation.

Looking forward developers, user experience designers, users, official language advisors and others' input.

Add redirects for renamed files

Some of the markdown files were renamed in reorganizing the documents. Redirects should be added so links aren't broken.
Will need https://github.com/jekyll/jekyll-redirect-from and updates to the _config.yml maps since we don't use direct frontmatter on the Markdown files

List of departments that have sub-delegated authority to assign a license.

By default the ability to assign a license to Crown Copyright work sits at the DM level.

It would be nice to have a list of departments and where the authority to assign a license currently sits to make it easier for people attempting to open source their work.

It took me a while to figure out that the authority had been delegated to the DG level at ESDC as it wasn't common knowledge in my department.

Thankfully my department is large enough that it has an Intellectual Property Centre of Expertise and they knew who had that authority but I had to write a lot of emails to get to that point.

I did some googling and it looks like there might at one point have been a published list but it doesn't look like that's the case anymore.

Change "Prior to Starting" to "Open Source Software Acquisition"

I noticed the "Prior to Starting" section isnt following the other naming convention used for the other sections. is that on purpose ?

IMO I think the section should be renamed to "Open Source Software Acquisition" to better fit in with the other sections.

If attention needs to be driven there as a first stop, maybe the standard could be modified to actually say that ? 🤷‍♂

Pointing to many reasons to contribute to open source.

I'm thinking about:

To make changes in open source software, engage with the community and submit your changes upstream to ensure that your modifications are supported by future updates.

And wondering if there is a way to put in a link to:
https://technology.blog.gov.uk/category/open-source/

make it clear some of the reasons why we're doing this. There are some golden blog posts here. Ensuring modifications are supported is just one.

General comment on guidelines

In general, I recommend to

1. Separate the guidelines as such : Guideline on the Use of Open Source Software, Guideline on Modifications and Source Code Contribution to Open Source Software Projects, and Guideline on Leading Open Source Software Projects. I would not put any infos about customizing OSS.

2. The Table of Contents should be something like
   a. Purpose
   b. Introduction
   c. Guideline 1 Title
   d. Guideline 2 Title
   e. Key Terms and Definitions
   f. Annex A: Title A
   g. Annex B: Title B
   h. References

3. In the Introduction, you should refer to the other guidelines

Change site theme from GCWeb

Since we're not on canada.ca, we should swap to the regular WET "base" theme

Banner links to Canada.ca incorrect after a content move

Summary

On https://canada-ca.github.io/open-source-logiciel-libre/en/guides/contributing-to-open-source-software.html
Please be advised that the link to the official standard that appears in the alert is broken.
"This is the latest working copy of these Standards, for the official standards please visit here."

Apologies if this isn't the place to report this, but I figured that this is outside scope for the Principal Publisher.

Steps to reproduce

1. Navigate to https://canada-ca.github.io/open-source-logiciel-libre/en/guides/contributing-to-open-source-software.html
2. Click on the link that appears in the alert at the top of the page. https://www.canada.ca/en/government/system/digital-government/open-source-software.html
3. Get a 404 error.

Example

See screenshot.

What is the current bug behavior?

404 error

What is the expected correct behavior?

Not a 404 error, a functional link.

Relevant logs and/or screenshots

Possible fixes

Add a functional link (please).

Clarification on Protected Information - Tests, Testing Procedures, and Audits

I would like clarification on what Information about testing procedures, tests, and audits is considered protected information? The document doesn't specify the type of tests and I can see there being confusion when the open source software has tests that automate the software.

Link to Section : https://github.com/canada-ca/open-source-contribution-logiciel-libre/blob/master/en/contribution.md#protected-information

My issue in the open first whitepaper can be closed in favor of this one: canada-ca/Open_First_Whitepaper#117

Are we being too specific?

I'm just looking at https://github.com/canada-ca/open-source-logiciel-libre/blob/master/en/guides/contributing-to-open-source-software.md#verify-open-source-software-licence

Verify Open Source Software Licence

GC can contribute to all software licensed under an Open Source Initiative approved license or a Free Software Foundation free software licence.

Does this mean that the GC cannot contribute to projects that are listed under the Public Domain?

I'm just wondering what licenses are potentially a problem. Lots of government work has contributed to proprietary projects owned by a variety of vendors.

There are good reasons to select software that is leveraging an approved open source license. There are reasons to select one of the preferred licenses when releasing a project. But if a government department is already using a piece of software and they want to contribute to it, why is the license a consideration? It seems the norm is to do this for proprietary tools at the moment.

Also, is it "Licence" or "License" in Canada? My spellcheck thinks it is the latter.

GPL version and license notices needs improvement

https://www.gnu.org/licenses/identify-licenses-clearly.html

So, some recommendations I have are,
in publishing-open-source-code.md
"Recommended reciprocal licences are:" it should say
GPL 3.0 or later | LGPL 3.0 or later | AGPL 3.0 or later

"And then, To apply to source code, add the text of the chosen licence to a LICENSE.txt file in the root folder of the project."

There should be some additional instructions about license notices. They are especially important for the GPL licenses, as that is the means to specify they include any later version. Without that specificiation, its unclear. Apache license also has requirements about the notice, simply read its text. I think its generally accepted that this notice won't be in every source file, but it should be at least in a README, or for example many package manifests, for example npm want you to specify a license using spdx, and GPLv3 is not an option from the current license list, you need select "or later" or "only", see https://spdx.org/licenses/ .

Link to actual TBS definition of "open standard".

In the Guide for open standards, it would be good to link directly to the TBS definition of "open standard".

I tried to chase down the definition, in the various references given, but was unable to. I was looking for some key phrases like "royalty-free", etc.

Unlike the term "open source", there isn't a completely clear, widely agreed-on definition of "open standard" (although the definition of "open standard" given by the Open Source Initiative is good and is maybe the closest thing we have to a formal definition of the term -- see also additional commentary re "FRAND" here). Thus the importance both of linking to the TBS definition, if there is one, and of ensuring that that definition is a solid one that allows unrestricted, non-monopolized, royalty-free implementation in open source software.

(I think issue #25 may be related to this, though it's not exactly the same.)

Ensuring that open source software be actively....

Just looking at the last line here:

https://github.com/canada-ca/open-source-logiciel-libre/blob/master/en/requirements/using-open-source-software.md

Requirements

Ensuring that open source software be actively and fairly considered for all new technologies, upgrades or migrations, including cloud solutions.

Any reason not to just remove it?

It's already in a "Requirements for using open source software" section. I'm not sure what it ads.

What would someone look for? When wouldn't open source be appropriate?

Clear guidance and visibility

Examples of times where we could have used an OSS alternative

Executive version of the Open First Whitepaper

Whitepaper is lengthy so we need a more succinct version for executives.

Clear guidance for devs, managers, etc.

Acquisition and procurement

Conclusion of discussions:

OSS is not an acquisition, equivalent on reading an article

Classification Levels

Source code needs to be clearly identified as Unclassified.

Security: should not be an obstacle for OSS (use or release).

Assets management

Most organizations have a "software assets management" group or similar. This organization and your organization's Enterprise Architecture should be involved, as should any "business relationship management" units to coordinate the use of software in general - OSS should be a possibility but there is a danger of allowing subject areas or their "portfolio" programmers jumping the gun on what software to use.

Modeling the OSS Standard in Archimate

<pressed enter before I was finished typing so this is all appearing as an edit :( >

This is a bit of an evening project for me, but I think it could benefit alot of GC architects who have to deal with policies coming out of TBS.

Using the text from https://canada-ca.github.io/open-source-logiciel-libre/en/open-source-standards.html

I did a first-pass(technically a second pass) and modeled out how I thought the standard looked like as an architect in archimate.

The model can be visualized here https://kingbain.github.io/OSS-Model/

I basically deconstructed the activity of creating the standard as well as created lists of requirements, criteria and a principle that basically represent the standard in its peices. Linked them all together using Archimate notation.

If anyone is interested in enhancing the model, you can access it via Archi and the Collaboration plugin

My question for the authors though, is how do you plan to link the Standard to the other section of the document. Does my model make sense, where is it missing information ?

Specifically ...
Prior to Starting
Use of Open Source Software
Contribution to Open Source Software
Publication of Open Source Code

Will those be part of the standard ? How will those section be consumed ?

Guide for Open Source Software Acquisition and Modeling

I dont know where to put this...

When I read the first paragraph it describes how the architecture review should be done, but when I read the following sentence I get a bit confused by.

"These align with the Digital Standards and requirement C.2.3.8 of the Mandatory Procedures for Architecture Assessment which provide that, where possible, open source software be used first."

To me that sentence is repeating some of the previous sentence and the use of "these" i find confusing.

Is there any chance someone could walk me through the Acquisition principle, it would help with modeling ?

This is what I have so far

The "open core" section has problems and is not sufficient.

First, its missing things: See the section of "Practical Differences between Free Software and Open Source"
https://www.gnu.org/philosophy/open-source-misses-the-point.en.html

I wouldn't like to see this guide encouraging Canada to buy tivoized devices they have no freedom over, then being beholden to a vendor just as if it was proprietary.

Also, a wider issue than "open core" is software which claims to be open source but simply isn't. "Verify Open Source Software Licence" is simply too vague about how to check licenses, and will lead to using proprietary software. For example, did you know that Ubuntu, arguably the most popular GNU/Linux based OS has harcoded requirement to download and and run nonfree software for all versions which include linux (the kernel) and run on amd or intel processors: https://packages.ubuntu.com/bionic/intel-microcode https://packages.ubuntu.com/bionic/amd64-microcode . Whereas Trisquel, or Debian, does not have this requirement. According the guide "A solution that is built with open source software but requires the use of closed-source components should not be considered open source software for the purpose of this guide", but I bet most people actually using the guide would not figure out that ubuntu on intel or amd processors "should not be considered open source for the purpose of this guide."

In the majority of issues I've seen, the software claims to be "open source", but is not fully free, doesn't happen when software claims only to be "free software." (as in freedom). In any revision which tries to help people better identify "open source", I suggest that they should prefer software that calls itself "free software", as I only see the term "open source" becoming more and more misused and not actually providing freedom in practice. For example, note the front page of ubuntu.com "Ubuntu is an open source software operating system", and the front page of debian.org: "Debian is a free operating system (OS) for your computer", where free links to a definition of free software. As an extremely practical matter, preferring software which claims to be free software, will actually lead to more "open source."

Directive on Automated Decision-Making; Releasing source code.

Has anyone noticed the wording they added to the directive for AI on release source code.
https://www.tbs-sct.gc.ca/pol/doc-eng.aspx?id=32592

------------------------------------------------
Release of Source Code
6.2.6
Releasing custom source code owned by the Government of Canada as per the requirements specified in section C.2.3.8 of the Directive on Management of Information Technology, unless:

6.2.6.1 The source code is processing data classified SECRET, TOP SECRET or PROTECTED C;

6.2.6.2 Disclosure would otherwise be exempted or excluded under the Access to Information Act, or

6.2.6.3 An exemption is provided by the Chief Information Officer of Canada.

6.2.7 Determining the appropriate access restrictions to the released source code.
------------------------------------------------

Why do you think source code for things that process secret, top secret and protected C need a special process to be released ?

Processing could mean anything... like a test script(TDD) or spellcheck or whatever ?!

Risk responsibility

Departments want to hold someone responsible for each piece of code or software in case something goes wrong, and there is a responsible party. There are several ways to approach this, including:

1. Proprietary software: Whoever sold it is responsible. But black box/hidden code is not inherently more secure, and pointing the finger does not necessarily solve a problem.

2. Enterprise managed Open Source: Allows for free license with paid support. Also provides someone to be responsible, but has the same problem as 1, in that departments are tied to that service provider and code is not necessarily internally understood and optimized.

3. Internally managed Open Source: Training and supporting internal capacity that builds on a (volunteer) community for OS tools. Requires more department commitment, but means all code is internally understood and flexibility is maintained. However, blame doesn't go outside department.

Is the "point the finger" paradigm the best we can do? Internal capacity is required no matter which option is chosen to ensure best use of any software or tool. We do not need to be limited to option 1 or 2 for comprehensive security (contra what I have heard from some here at Open First day), and there may be many further possibilities.

Importance of policy from TBS

Karen from Agriculture:

Departments are on their own to write their internal policies since there's not currently an overarching policy.

Diversity of OSS will need to be reflected in the policies that will enable them.

Data Sharing Standards (ISO)

Steve

ISO : Data Sharing Standard being worked on at the moment (MS is a contributor as well).

Code is a sort of data, then you'll have test data, all types, etc. Sharing.

Add a CLA (Contributor License Agreement)

https://en.wikipedia.org/wiki/Contributor_License_Agreement
This should be checked by bots for signing if possible https://github.com/cla-assistant/cla-assistant

Security Controls for Open Sourcing your code.

I've been documenting some Security Controls for Open Source Code, figured I'd share it here since it might be useful for people in other organizations.

These are the controls that I'm putting in place for my project and may not be needed for everyone's work.

Signed Commits

Only signed commits can be merged into the master branch.

Peer Code Review

All pull requests must be reviewed by 2 team members (1 Senior member is mandatory). If you review code you are as responsible for that code as the person who wrote that code.

Static Code Analysis

All Code must be run through a static analysis tool. This should run as a precommit hook or on pull requests to master.

Dependency Scanning

All Dependencies should be scanned using a dependency scanning tool either as a precommit/push hook or as webhook on a pull request.

Dependency Scanning tools

snyk.io Free for open source software
OWASP Dependency Check Java and .Net only

Secret and Credential Policy

You must store secret keys and credentials separately, for example with a secret management system, and inject them into the code. This protects the keys from being accessed by unauthorised staff, and makes it easy to provision different keys for different environments and rotate keys if needed.³

2 Factor Authentication (2FA)

2FA is mandatory for members of the development team if it is supported by the source control platform.

Security Audits

The project will be routinely audited for any unallowed data, and run through several credential detection tools. Such as GitRob and TruffleHog

Security Disclosure Policy

A security disclosure policy is needed to outline the steps to take if a vulnerability is found in our source code.

Accidental Credential Disclosure Policy

Come up with a procedure to follow when we accidentally disclose a secret of some kind.

Example

Assume key is compromised
Revoke credentials if possible
Generate new keys
Determine potential impact of disclosure
If it's determined that protected B or above information could be disclosed follow your organizations guidelines on an accidental privacy disclosure.

References

1. Title: 10 GitHub Security Best Practices
   Link https://snyk.io/blog/ten-git-hub-security-best-practices/

2. Title: Making source code open and reusable
   Link: https://www.gov.uk/service-manual/technology/making-source-code-open-and-reusable

3. Title: Security considerations when coding in the open
   Link: https://www.gov.uk/government/publications/open-source-guidance/security-considerations-when-coding-in-the-open#deal-with-security-vulnerabilities

4. Title: Tensorflow SECURITY.md File
   Link: https://github.com/tensorflow/tensorflow/blob/master/SECURITY.md

5. Title Apache Storm SECURITY.md file
   Link: https://github.com/apache/storm/blob/master/SECURITY.md

Security

In the use of Open Source guide, there doesn't seem to be a mention of security risk responsibilities.

In using any open source software, user must be aware of any security vulnerabilities related to the code. Some considerations to validate:

• Check for public vulnerabilities - ensure the open components do not contain publicly-known vulnerabilities, such as those with reported CVEs or with vulnerabilities described in other public resources
• If possible/available, use commercial security intelligence - use additional vulnerability data sources (such as from data vendors) to augment the public vulnerability data
• Perform static analysis - use station analysis tools to validate that the open source components do not contain unreported security vulnerabilities. Report any newly-identified vulnerabilities to the open source project's author so it can be remediated.
• Perform comprehensive security reviews - in addition to the prior points, perform a comprehensive security review of the open source component

All organizations that use open source should have a strategy for responding when new vulnerabilities are disclosed. This often takes the form of monitoring the National Vulnerability Database for new information, or using tools built into a package manager (such as NPM Audit). While these certainly provide value, there are a few reasons why organizations shouldn't stop here:

There is no requirement for an open source project to report vulnerabilities up centrally. Details may exist in a GitHub issue, change log, or commit message, but would not be easily discoverable.
The vulnerability may have been found by an attacker, or a security researcher that is unwilling to publicly disclose the issue.
The project author fixing a bug may be unaware that it's actually a vulnerability, and so has no reason to report it.

A comprehensive security audit of an open source component can provide the highest level of assurance that the component is highly secure. Such an audit should include multiple areas, including:
Project Health. Is the component still maintained? Does it have a history of security vulnerabilities? Does the author release security fixes in a timely manner?
Public Vulnerabilities. Are there publicly-known vulnerabilities, either explicitly (for example, CVEs) or discoverable in the project’s issues list?
Static Analysis. Run high-quality static analysis tools to identify potential security vulnerabilities.
Dynamic Analysis. For certain types of components, perform active testing (such as web-based “black-box” testing, fuzzing.)
Secure Configuration. Understand whether there are security-sensitive configuration settings that should be enabled when using the component.
Code Review. Use the static analysis results to perform a directed code review, looking for security vulnerabilities. If any are found, build additional static analysis rules to catch the vulnerability next time.
Once this work is complete, document the findings for other teams in your organization to leverage. If any new security vulnerabilities were found, work with your security response team to inform the open source authors and if possible, suggest a fix.

CVS are considered deprecated.

I'd change this to "CVS and Subversion are considered deprecated."

Why reciprocal license restrictions in "Guide for Using Open Source Software"?

In the Guide for Using Open Source Software, in the section Verify Open Source Software License, it says that applications that are going to be modified can't use a "strong reciprocal" license if they're web apps nor any reciprocal license if they're going to be distributed externally.

This raises several questions/issues:

• In general, one can never predict with certainty whether one will have to make modifications to an open source software application one is deploying. One may start out intending to make no modifications, and discover one year down the road that modifications are necessary (furthermore, one cannot predict whether those modifications would be of the sort that should be submitted upstream, rather than merely published, and whether upstream would accept them if they were submitted).

• Since the Guide for Publishing Open Source Code says that work should happen in the open by default, in principle all modifications are intended for external distribution anyway (except for those which meet one of the rare exception conditions stated, but those do not concern us here).

What this all adds up to is that the Guide for Using Open Source Software effectively prohibits GC from using any reciprocally-licensed (i.e., copyleft / GPL'd) software at all.

Presumably this was not the intent?

What is the purpose of discouraging contact with reciprocal licenses, as specified in points 3 and 4 of the section "Verify Open Source Software Licence", anyway? Or am I just misreading the text somehow?

FWIW, the publication guide (a separate document) does not similarly discourage use of reciprocal licenses -- it just lists them as an option along with other types of licenses. Unless I've misunderstood something, the interaction between those two policies means that GC could easily end up publishing open source software that GC itself cannot re-use.

Link from pages to the repository

Hi @nschonni and @ShadeWyrm!

I was thinking that we could possibly include a link on the published guidelines directly to their related documents in the repo.

I think this would be the first time I see a set of published guidelines directly linking to their living workspace in the GC 😄

Thanks!

Guide to apply specific licence needs a bit more details

We have highlighted 5 very popular licences. Since the number is pretty low, it would be worth it providing a bit more details on how to write each one to help remove any confusion.