HackMD
🚀 Open Source Policy Draft
Unofficial! draft! no fighting.. yet!
🌸 Reminders
- Purpose
-
"Having a well-defined policy in place, that’s great, but it’s got to be a well-defined minimal policy. Otherwise you get lawyers, security folks, business folks, all piling in their concerns and constraints. Soon you end up with a strait-jacket full of policy that basically means that nobody can do anything." - Jeff McAffer , director of the Open Source Programs Office at Microsoft
💡 Rationale
Software as a Digital Public Good
UNICEF's software should aim to be, and serve as Digital Public Goods.
In alignment with our mission to protect children's rights and well-being, UNICEF develops, maintains, and shares a variety of software tools and platforms that address the needs of children and parents globally. We should embed end-user freedom rights in all our software.
Promoting Accessibility and Collaboration
UNICEF advocates for broad and immediate accessibility, use, and sharing of its software content. This software plays a critical role in shaping national, regional, and global policy, as well as guiding international assistance and informing both national and international practices.
Standardized Licensing
The adoption of default open-source licenses, such as the Apache License 2.0, for UNICEF's software allows for widespread use, modification, and distribution under standardized, machine-readable conditions. This approach simplifies compliance and fosters a collaborative development environment.
🙋 Roles/Responsibilities
- Immediate requirements: 🟢
- Prioritized requirement in next 12-24 months: 🟡
- Not urgent, can be supported through external groups: 🔴
Governance 🟢
- Responsible for defining and overseeing the standards, policies, and structures that guide the organization's open source activities.
- Establish policies for open source use and contributions.
- Monitor compliance with these policies, manage the organization's open-source portfolio, and assess the impact of the organization's open source activities.
- Involved in strategic decision-making related to open source
This role is important from the beginning as it is responsible for establishing the policies and guidelines that will guide all open-source activities. It's crucial to have these guidelines in place early to ensure compliance, standardize open source activities, and manage the organization's open-source portfolio.
Open Source Adviser 🟢
- Guide the organization’s open source strategy.
- Provide expert advice on open source use and contribution, including compliance, technology decisions, community engagement, and risk management.
- Maintain an overview of the open source landscape, keeping abreast of emerging trends, and identifying potential opportunities for collaboration or strategic utilization.
The Open Source Adviser is pivotal for the foundation of an OSPO. Their expertise and guidance will help formulate strategies, oversee compliance and technology decisions, and manage risks. Their role is critical in integrating open source principles into the organization's culture and projects.
Individual Contributor 🟡
- Contribute to open source projects. This can involve coding, but also includes contributions like documentation, design, bug reporting, community support, etc. Individual contributors need strong technical skills and a solid understanding of the specific open source communities they work within.
These are the boots on the ground in Open Source projects and will be required once initial strategies and frameworks are in place. They will be the ones contributing/reviewing PRs to Open Source projects, which could involve coding, documentation, design, bug reporting, community support, etc.
Education 🟢
- Focus on educating the organization about open source, creating training materials, hosting workshops
- Support developers/project managers understand how to use and contribute to open source projects effectively.
- Advocate for open source principles and practices, fostering a culture that values open collaboration.
The role of Education is vital from the very beginning to ensure the proper understanding of open source concepts, benefits, and practices within the organization. They are responsible for creating and delivering the educational materials and training that will help staff understand and contribute to open-source projects effectively.
Community Engagement 🟡🟢
- Build and nurture relationships with open source communities.
- Engage with community members, manage community events, respond to community feedback, and facilitate collaboration.
- Represent the organization's interests within these communities, and vice versa.
- Proactively identify potential partnerships or collaborative opportunities within the community.
Initial community engagement should be the responsibility of the Open Source Adviser. However, as UNICEF grows in the open source community, there will be a need to establish a dedicated Community Engagement role within 12-24 months to manage relationships, facilitate collaborations, and represent the organization within the open source communities.
Security 🟡
- Oversee the security aspects of using and contributing to open source.
- Ensure compliance with security best practices and protocols, perform or oversee security audits, handle security incidents, and provide security training to UNICEF staff.
- Regularly assess the security of open source tools and libraries the organization uses or contributes to.
- Stay updated on emerging security threats and implement preventative measures as necessary.
While security is an important aspect of all projects, in the early stages, basic security measures can be handled by the Open Source Adviser. As open source contributions and adoption expand, a dedicated role focusing on security will become crucial.
Licensing 🔴
- Handle the legal aspects of open source.
- Ensure compliance with various open source licenses, handle legal issues related to open source use and contributions, advise on the selection of appropriate licenses for open source projects, and provide education to staff on open-source licensing to prevent misuse.
- Handle intellectual property issues related to open source and be the point of contact with the legal team.
While licensing is a key aspect of open source, in the initial stages, legal advice on licensing can be outsourced or managed in collaboration with organization's existing legal team. As the open source work scales, we should consider bringing this expertise in-house.
Project Management 🔴
- plan, coordinate, and oversee project activities, ensuring that projects are completed on time, within scope, and within budget. They also manage resources, handle project communication, and mitigate project risks
In the early stages, project management can be handled by individual contributors or team leads. As the organization's involvement in open source projects grows, there may be a need for dedicated project management, but this can initially be supported by external project management resources or software.
🚀 Behavior
- Software Company
- Technology Strategy Experts
- Open Source Advocacy
- Project Facilitators - collaboration
- Standards Collaborative
- Partners Collaborative
- Internal project Collaborative
🌱 Size (early stage)
- Innovation Manager - limited capacity (manage team)
- Open Source Innovation Specialist: Set policies and standards, Internal Open Source capacity building (COs, divisions, partners), work with Open Source Technical Advisor, Support DPGA, Community engagement
- Open Source Technical Advisor/Mentor: Working with portfolio companies, DPG reviews, maintain Open Source knowledge hub, work with Innovation specialist to improve mentorship modules
🧩 Responsibilities
- 📒 Support Open Source capacity building
- 🧭 Eliminate Friction from Using and Contributing to Open Source
- 🖥️ Collaborate on managing Open Source IT Infrastructure
- 🧑💼 Give Advice on Open Source
- 🫶 Grow and Retain Open Source Talent Inside the Organization
- 🤝 Implement InnerSource Practices
- ⏱️ Track Performance Metrics
- 🤝 Collaborate with Internal Stakeholders
- 🤝 Collaborate with Open Source Organizations
- 📈 Prioritize and Drive Open Source Upstream Development
- 💪 Establish and Improve Open Source Processes
- 📝 Establish and Improve Open Source Policies
- 🔍 Oversee Open Source Compliance
- 📘 Develop and Execute Open Source Strategy
🌼 Questions to drive Policies
(We = UNICEF personnel, staff+consultant)
- How we can contribute to open source projects
- How we can open source internal projects
- How we accept external contributions to our open source projects
- How to prepare for open source releases
- How approvals are received
- How developers can use open source code they find on git forges
- Procedures and rules explaining how open source code can be brought into UNICEF
- How the incoming code is cataloged so others know it is being used - SPDX Guidelines
- How we can grow a community of like-minded external developers around it to keep it thriving
- Rules that help determine when code should be released as open source
- Default license? Boiler plate template repo
👩⚖️ Policy v 0.01**
Create
Open Source Contribution Workflow
Reading list
- UNICEF Open Source toolkit
- GPLv2 vs. GPLv3
- Intro to Creative Commons licenses
- Legal & Business Aspects
- Trademark strategies
⚖️ Approved Licenses
Approved/Accepted licenses for United Nation Children’s Fund’s Open Source project:
**Software: **
- OSI approved Licenses.
- Unless a specific and special reason, choose one of the following licenses as per the type of content. For specific question, open a ticket at <github repo for support>
| License Type | Permissive | Weak Copyleft | Copyleft |
| Software | MIT License | LGPL (Lesser General Public License) | GPL (General Public License) |
| Data | PDDL (Public Domain Dedication and License) | ODC-ODbL (Open Data Commons Open Database License) | n/a |
| Content | CC0 (Creative Commons Zero) | n/a | CC-BY-SA (Creative Commons Attribution-ShareAlike) |
| Hardware | CERN OHL-P (CERN Open Hardware License Permissive) | n/a | CERN OHL-S (CERN Open Hardware License Strong) |
| Others (like designs or 3D models) | SIL Open Font License (OFL) for fonts | n/a | CC-BY-SA (Creative Commons Attribution-ShareAlike) |
Use
Compliance and Governance
- Identify all Open Source tools used within UNICEF.
Grow
Open Source Education/Capacity Building
- Continous improvement of Open Source Inventory (toolkit)
Success Metrics
Continuous Evaluation
References and Attributions
- Todo Group - https://todogroup.org/
This document is shared under CC-BY-SA 4.0 
UNICEF STANDARD ON OPEN SOURCE SOFTWARE
Products
- In this category, any product that is adopted and implemented as-is (without need for either customizing or contributing). The software products under this category might be webservers (Apache Tomcat), CMS/Application software (WordPress), Operating systems (Linux), Database (MySQL, PostgreSQL, Couchbase ) etc.
Tools/Utilities
- Anything that is adopted and implemented either as part of other software products or to be used in development of other products without additions or modifications by UNICEF. The software under this category might be JavaScript frameworks like AngularJS and SAPUI5, language frameworks like Django and Ruby on Rails, Mobile frameworks like Ionic and Cordova.
Custom Developed/Derivative works
- Anything that is developed in-house or under UNICEF supervision by third parties to either build custom software solutions (e.g RapidPro, eTools) or to extend and augment software solutions that are open sourced (e.g ActivityInfo).
Open Source Software
- UNICEF will actively and fairly consider open source solutions alongside proprietary ones in making procurement decisions.
- Open-source software/solution adoption decisions will be made on the basis ofbased on the cost effectiveness of the solution to the business requirement, taking account of total lifetime cost of ownership of the solution, including exit and transition costs, after ensuring that solutions fulfil minimum and essential capability, security, scalability, transferability, support and manageability requirements.
- Where there is functional parity but no significant overall cost difference between open and non-open source products, open source will be selected on the basis of because of its inherent flexibility.
- Where appropriate, general purpose software developed for UNICEF will be released on an open source basis (provided it does not have any proprietary components or does not require proprietary software, infrastructure or licensing requirements).
Re-Use and Redistribution
- UNICEF will look to secure full rights to bespoke software code, so as toto enable re-use elsewhere in the organization, extended partner community or within the UN community.
- Wherever appropriate, when a new system is proposed, partners will be required to promote or support, either in whole or in part, reuse of UNICEF owned system.
- Where UNICEF already owns the system (either internally developed or co-developed with partners), UNICEF will reserve the right to redistribute the solution as appropriate even if there maybe potential partners with commercial arrangements (for hosting or infrastructure services) or providing commercial services (for operational support & maintenance).
- If public release of the project or code is restricted by other local law or regulation, such as Encryption then that portion of project or software code may not be released for public distribution.
Security & Privacy
- All open-source or custom development (either original or derivative work) which is undertaken either in-house or developed by a partner has tomust undergo the standard Security Review process following Security policy and guidelines set forth under UNICEF POLICY ON INFORMATION SECURITY: OPERATIONS SECURITY MANAGEMENT: CF/ITSS/POLICY/2016/003.
- If the IT Security Review recommendation deems that the public release of software code would pose an unacceptable risk to UNICEF’s operational security then that project or software code (either wholly or partially) will not be released in public domain (e.g specific code interfacing with UNICEF corporate systems, Authentication with UNICEF corporate systems).
Open Standards
- UNICEF will use open standards in its procurement specifications and require vendors to comply with open standards. UNICEF will actively support internal adoption of open standards and specifications.
- UNICEF will require and mandate use of open standards in either internally developed general purpose software or as part of proprietary off-the-shelf software to ensure interoperability between disparate solutions.
Special Considerations in Emergency Contexts (as applicable)
- UNICEF may under special emergency contexts partner with counterparts and other agencies for fast response which may entail use of software and tools not directly owned by UNICEF in which case exceptions to this standard and associated standards maybe allowed under exigent circumstances by the CIO.
Accountabilities for Implementation
- All UNICEF Offices and Project Teams that undertake any type of software or systems procurement or development work are responsible for implementation of the standard.
RESPONSIBILITIES
- The CIO, as the Business Owner of this Standard, will oversee the implementation and adherence to the standard and principles, ensuring that the standard is aligned with overall organizational strategy and objectives.
- The Programme Management Office will coordinate and manage dissemination and communication of the standard.
- The Deputy Director (Business Solution Centre) ensures that the standard is implemented and exceptions are properly documented.
- The Project Owners and Business Stakeholders of specific initiatives will be responsible for ensuring adherence to its principles.
- ICT Project Managers and ICT SMEs will be responsible for ensuring adherence to the standard.
