Open Source Ambition Ladder in Custom Tendering or Contracting

--- layout: default --- <style> .oud, .nieuw { } .oud { background: #f9dfdd; -webkit-touch-callout: none; /* iOS Safari */ -webkit-user-select: none; /* Safari */ -khtml-user-select: none; /* Konqueror HTML */ -moz-user-select: none; /* Old versions of Firefox */ -ms-user-select: none; /* Internet Explorer/Edge */ user-select: none; /* Non-prefixed version, currently supported by Chrome, Edge, Opera and Firefox */ } .nieuw { background: rgb(200, 255, 200); } .variabele { background: rgb(225, 225, 225); color: rgb(100, 100, 100); } </style> Open Source Ambition Ladder in Custom Tendering or Contracting == >[!Note] Explanation >All text in these blocks will not appear in the published document on GitHub Pages, but are intended as an explanation for you as a contributor here on HackMD. >[!Note] Participate? >:100: The goal of this document is to collaboratively develop a fully elaborated ambition ladder that will offer a framework for open source in tenders or contracting. Everyone is free to participate in this document. Based on mutual trust. > \ > \ > You have two options in this document: > 1. Leave a comment; > 2. Make a text suggestion. > > Select a piece of text. A small menu will open where you can choose "*Comment*", "*Suggest Edit*", "*Edit from here*" or "*Copy link*". > \ > \ > Participating via GitHub is not possible and any suggestion there will not be addressed. Instead, you can participate on HackMD with or without your GitHub account. > \ > \ > Want to be attributed as a contributor in the list of contributors at the bottom of this document? Then put your name and optionally your organization in a comment field under that chapter. If you want your name to link to an online profile, please let us know. >[!Important]Administrator >:cop: Maurice Hendriks >[!Tip]GitHub account? >:star: For everyone with a GitHub account. You can log in here via that account so that your contributions are traceable. > [!Note] Community call > > {%hackmd 09HDRFB7TqeWsi1T2YTTKw %} # Content > [!Note] > The goal of this document is to collaboratively work towards an ambition ladder for open source in tenders or contracting. It was initially created by Maurice Hendriks (Senior CIO Advisor at the Ministry of Health, Welfare, and Sport). The knowledge comes from concrete experiences with open source tendering within the Dutch Government. > > Experience shows that, with some help, a person can articulate the objectives and ambitions they see in the application of open source. However, what is ultimately missing are concrete tools to apply this in practice, in this case for tenders or contracting, as well as experiences from others to help ease any concerns. With the 'open source ambition ladder' this document provides a practical tool for contracting authorities when putting out a tender for custom software or related services. The ladder helps determine and specify the desired level of "open source", depending on strategic objectives. Examples of such objectives include increasing transparency, promoting reuse, or safeguarding digital sovereignty. The focus here is specifically on the development of custom-made software. The procurement of services related to open source, or the purchase of existing off-the-shelf packages are covered in other document. In procurement, a wide range of non-functional requirements play a role. You can roughly distinguish between strict compliance requirements and value-driven requirements. With strict compliance requirements, you clearly meet or do not meet the criteria. Think of open standards or information security. Open source and social return or environmental sustainability are value-driven requirements. There is no clear set of standards that you must meet. Legislation does provide an obligation to make an effort to apply open source as a means to enhance transparency and reusability of digital technology. Open source can contribute to additional goals, such as reduced vendor lock-in, increased security/privacy, greater transparency and more impactful government purchasing. Therefore, there is no single set of requirements that all procurements must meet. With open source, this requires a deliberate consideration of the various goals you want to achieve with open source in your procurement and to what extent. The level of this will indicate the final ambition. In this document, those goals are broken down into the four advantages of [open source working](https://opensourcewerken.nl/). Open source working (Opensourcewerken in Dutch) is a program by the Dutch Ministery of Internal Affairs. The program is build around the four sets of goals also used here. This does not mean, however, that the lowest ambition level described here cannot be seen as a minimum standard. The minimum set of requirements set forth in this document does meet the obligations the Dutch have under the Open Government Act and the Public Sector Information Reuse Act. > [!Note] Why only development and not services? > This point has often been raised by feedback providers: Why focus only on the development of software and not on procuring services? I (Maurice Hendriks) have no experience with these kinds of tenders, so I cannot provide input on them. The invitation is, of course, to share knowledge from that perspective. > > I envision working towards a general document "open source tendering", where various perspectives are described, including: > * Tendering of (custom) development (this document) > * [Tendering of support or services](https://hackmd.io/Un-vnRnBRcOAtQ1jAeYz8g) > * [Tendering of standard software](https://hackmd.io/NbYC48GJRx-KIuVX5sHGeg) > > If anyone is willing to take the lead in writing the other chapters, the documents are ready under the links. {%hackmd Lf8vRdFhShOiVX83M3pY5Q %} :::info :bulb: **Tender, contract, or job vacancy?** Although the texts are written with a tender in mind, they can also be read as requirements for contractors, freelancers, job vacancies, or your development team. For example, knowledge of Git, SBOM-standards, and open source licenses are assumed in all level of ambitions. Parties or individuals who can meet a higher level of ambition can be preferred over others. ::: :::info :bulb: **Create your own menu?** This document provides suggestions that you can reuse in a tender. They are explicitly suggestions and not rules. Feel free to selectively shop from these suggestions by ignoring some, rephrasing them, combining them differently, or adapting them in any way that works best for your specific situation. ::: :::info :bulb: **Free?** *Free as in free speech, not as in free beer - Richard Stallman* Open source software is not gratis software, but rather libre software. The freedom referred to here means that users of open source software have the right to access the source code on which it is built, to study it, to modify it, and to further distribute it. Another often-used example is that of free puppies. A free puppy still requires investment in facilities such as a food bowl, leash, bed, as well as food, a veterinarian, or training. In the same way, while the source code may be freely available, investments are still required to be able to make use of it. Just as open source does not mean cost-free software, striving for a higher level of ambition is not without cost. Pursuing higher ambitions has consequences for you as the contracting authority. It generally requires more from your own organization, for example in terms of coordination, finances, the knowledge and expertise of staff, but also from the contractor(s). Likewise, the more you challenge a closed source software supplier the higher the price will be. The higher the requirements you set, the fewer choices you have. Software procurement is no different from other products or services in this regard. It is therefore possible that the pool you can draw from becomes smaller when ambitions are raised, but in return you gain greater freedom. Neither comes without a cost. Not in open source, not in proprietary source. ::: # Benefits of Working in Open Source [Go to top](#content) This document focuses on the following four benefits of open source, as communicated by the Dutch Opensourcewerken program. This doesn't mean that each benefit is equally important for every situation or should be pursued with the same goals in mind. For each benefit, ambitions or options can be formulated. These can be combined as needed. Aim to cover all four benefits to reduce ambiguity, even if the ambition for a given benefit is low. 1. **Efficiency and Independence** \ Do we want to tender for multiple suppliers who each take care of a part of the tender? If choosing collaboration with multiple contractors: how is the cooperation managed? 1. **Security and Reliability** \ To what extent can we be sure that the developed work is secure and does what it’s supposed to do? No concessions are made in these requirements in this ambition ladder. Therefore, this category is not divided into different ambitions. 1. **Transparency and Trust** \ To what extent do we want the products in this tender to be developed as openly and transparently as possible? Or to what extent do we want hired experts to be able to implement the ambition with their knowledge and experience? 1. **Collaboration and Innovation** \ To what extent do we want suppliers, societal partners (government, knowledge institutions, and/or citizens), and/or other interested parties to be able to collaborate during or after the development of the products? In general, it's important to think about what the objectives look like in the short, medium, and long term. What kind of collaboration with stakeholders (suppliers, partners, and/or other interested parties) will be necessary in 1, 5, and 10 years? # Benefits of Open Source Tenders [Go to top](#content) Open source tendering brings a wide range of benefits, not only for the client but certainly also for the contractor. **For public clients** * Governments fulfill their **legal obligations** to be transparent and accountable * By developing the source code as open source as possible from the start, the **responsibility** to do this decently is moved towards the contractor. You can expect the contractor to have the expertise to handle properly. * It significantly **prevents remedial work** later on if the source code is not developed in a transparent-by-design way. * It **prevents vendor lock-in** in custom tenders. Due to the knowledge gap of other suppliers, they typically have no interest in taking over the further development of someone else's work. When the code is well-documented and developed open source for reuse, this knowledge gap is minimized. * Clients are not **stuck with ownership of software**. It represents capital that could yield returns when made publicly available as open source. * Contractors are stimulated to develop with **reuse in mind**. **For contractors** * Contractors have the **freedom to reuse** the work they have developed at the client's expense **in other (commercial) contexts**. * Contractors who do not win a tender can still benefit from the work and knowledge developed from the contract. They are left with only a **minimal knowledge gap**. This is particularly important when multiple suppliers operate within a specific system. * It is easier for contractors to build a **portfolio** not only of finished products but also **with insight into the quality of previously developed technology**. The higher the open source ambition level within a tender, the greater the chance that the above benefits will be realized. This way, a public software tender does not only provide a practical IT solution for the client in question but also leads to policy, public, financial, and even commercial value. # Text Suggestions ## General Texts [Go to top](#content) A procurement consists of various interrelated documents. It is important that all of these documents properly address the requirements imposed on open source development. An example sentence that can be used in the *Descriptive Document*: > The Contracting Authority wishes that the software and documentation developed under this agreement can be used free of charge and without restriction by the Contracting Authority, the Tenderer, or other recipients. With this procurement, compliance with the Re-use of Public Sector Information Act (Who) is ensured by design, and vendor lock-in is reduced. This is in addition to the transfer of copyright arising from the procurement conditions or the final contract. This means that the developed software and documentation shall not contain any elements that would prevent such use. All requirements described under categories 1, 2, and 3 are intended to be included in the Program of Requirements. It is good to introduce these requirements with a leading sentence: > In the development of the works, the client expects that [some level | a high standard | the highest standard] of open source working will be applied. This means that: ## 1. Efficiency and Independence [Go to top](#content) For this benefit, you speak less of ambitions and more about options. To achieve it, you need to set up the tender in a specific way from the start. During the market consultation, indicate whether you plan to "*parcel out*" the tender. For example, you might want one supplier to handle (re)development, integration, technical and functional management, hosting, and other tasks. Or you might prefer to consciously spread these services across different suppliers. However, to prevent vendor lock-in with the initial contractor, the following two requirements must be met: ### Option 1. A single contractor is tendered to provide all services 1. The Tenderer shall ensure that the solution and documentation are developed in such a way that it is easy for other suppliers to provide services related to it, including maintenance and further development of the software. 1. The Tenderer shall provide readable and consistently structured documentation and source code, using formats and coding styles customary within the specific tech stack. 1. The Tenderer shall be open to having the maintainability of the source code externally assessed. 1. The Tenderers shall guarantee that the various components and the overall solution do not rely on components with mutually conflicting licences. ### Option 2. Multiple contractors are tendered to take on different components of the services 1. The Contracting Authority requires tenderers to collaborate on the solution and to jointly organise governance in such a way that this collaboration is optimally facilitated. ### Option 3. Suppliers, social partners, and/or other interested parties work together and can continue to collaborate. New partners should also be able to easily join the collaboration. 1. The Contracting Authority expects the Tenderer to take the lead in the development and design of a solution that can (at a later stage) be elevated by the Tenderer into a broader societal collaboration. This means that the Tenderer shall not only deliver the solution, but also contribute to enabling the formation of a community around the solution that jointly maintains and further develops it. ## 2. Security and Reliability [Go to top](#content) As stated earlier, no concessions will be made with regard to this benefit. Make use of the texts below to procure open source software in a safe and reliable manner. 1. The licenses and copyright holders are clearly communicated throughout the source code and documentation, as is customary. 1. Existing and proven open source components are used as much as possible 1. The components the developed software consists of is made visible in every version through a SBOM (Software Bill of Materials) according to the CycloneDX or SPDX standard. 1. All findings and/or improvements on existing open source components must be communicated and/or returned to the relevant communities (constributed to the upstream). 1. In case of vulnerabilities, the contractor must act as one can expect from the client's Coordinated Vulnerability Disclosure policy. 1. When using these components, the contractor must ensure no license conflicts arise and that the terms on which they are made available are respected. 1. The Contracting Authority expects the Contractor to be aware that, when using open source components, they assume the role of a manufacturer as defined in Chapter II of the Cyber Resilience Act (Regulation 2024/2847/EU). 1. Every version of the source code must contain a metadata description according to the publiccode.yml standard. 1. Work modularly, and develop modules as independently as possible to facilitate reuse. 1. Sensitive and confidential information must not be shared publicly. The solution is developed in such a way that the impact of this is minimized. For example, using independent configuration files so the source code can be published. 1. Any sensitive information must be actively monitored by the contractor. 1. Keep application source code strictly separate from operational data and credentials. ## 3. Transparency and Trust [Go to top](#content) ### Ambition 1. Publish all source code open source after completing the tender 1. All source code and documentation developed under the agreement, under an open source license recognized by the Open Source Initiative (OSI) and a documentation license from the Creative Commons family to be agreed upon, must be shared on a commonly used public—Git-supported—platform after completion of the assignment. 1. The Tenderer shall submit a proposal specifying under which licenses all source code and documentation will be published after completion of the assignment as part of the Contracting Authority’s project. The final license choices will be determined by the Contracting Authority and will form part of the final agreement. 1. Upon delivery, the Contractor shall guarantee the full technical and legal reusability of the developed work and other delivered works by providing all assets and documentation necessary for others to continue the work. 1. Before any published works or repositories are removed from public access, the Contractor must provide the Contracting Authority with as complete an archive as possible of the repository and associated metadata, so that the Contracting Authority can secure them on its own platform. ### Ambition 2. Publish the source code at fixed intervals or at key moments 1. All source code and documentation developed under the agreement, under an open source license recognized by the Open Source Initiative (OSI) and a documentation license from the Creative Commons family to be agreed upon, must be shared on a public Git-supported platform at agreed intervals or key milestones. 1. The Tenderer shall submit a proposal specifying under which licenses all source code and documentation will be published after completion of the assignment as part of the Contracting Authority’s project during the assignment. The final license choices will be determined by the Contracting Authority and will form part of the final agreement. 1. Upon delivery At the agreed intervals or key milestones, the Contractor shall guarantee the full technical and legal reusability of the developed work and other delivered works by providing all assets and documentation necessary for others to continue the work. 1. Before any published works or repositories are removed from public access, the Contractor must provide the Contracting Authority with as complete an archive as possible of the repository and associated metadata, so that the Contracting Authority can secure them on its own platform. 1. The Contractor shall assume full management of the software repositories. 1. The documentation shall clearly indicate the differences between two published versions. ### Ambition 3. Fully open source development of the source code 1. All source code and documentation developed under the agreement, under an open source license recognized by the Open Source Initiative (OSI) and a documentation license from the Creative Commons family to be agreed upon, must be shared be fully developed openly on a public Git-supported platform at agreed intervals or key milestones. 1. The Tenderer shall submit a proposal specifying under which licenses all source code and documentation will be published during the assignment publically developed. The final license choices will be determined by the Contracting Authority and will form part of the final agreement. 1. At the agreed intervals or key milestones, The Contractor shall guarantee continiously the full technical and legal reusability of the developed work and other delivered works by providing all assets and documentation necessary for others to continue the work. 1. Before any published works or repositories are removed from public access, the Contractor must provide the Contracting Authority with as complete an archive as possible of the repository and associated metadata, so that the Contracting Authority can secure them on its own platform. 1. The Contractor shall assume full management of the software repositories. 1. The documentation will clearly explain the differences between two published versions. 1. Both the history and progress of the development will be fully traceable, including the design choices made. ## 4. Collaboration and Innovation [Go to top](#content) ### Ambition 1. External contributions will be ignored 1. Published versions must be distinguishable from each other by consistent version numbering. ### Ambition 2. External contributions are handled but not actively sought 1. Published versions must be distinguishable from each other by consistent version numbering. 1. The conventions for code style, version numbering, git workflow, etc., are made clear. 1. It is well-documented how other interested parties can contribute to or ask questions about the source code and/or documentation. 1. All contributions require a signed Contributor License Agreement (CLA) or an approved Developer Certificate of Origin (DCO) before acceptance. ### Ambition 3. Active collaboration 1. The conventions for code style, version numbering, git workflow, etc., are made clear. 1. It is well-documented how other interested parties can contribute to or ask questions about the source code and/or documentation. 1. Through well-documented governance, conventions, project objectives, and communication channels, it is made clear how other interested parties can participate in the collaboration. 1. With open documentation on the operation of the software and design choices in the underlying source code, immediate reuse or future development is facilitated as optimally as possible. 1. All contributions require a signed Contributor License Agreement (CLA) or an approved Developer Certificate of Origin (DCO) before acceptance. # Examples ## Lowest ambition So, Baseline example for the lowest ambition: option 1 *Efficiency and Independence* + *Security and Reliability* + ambition 1 from *Transparency and Trust* + ambition 1 from *Collaboration and Innovation* Suggestions for in the **Selection document** and/of in the **Descriptive document**: > The contracting authority seeks a single contractor to provide all services and expects from that the contractor that it will publish all source code open source prior to completing the tender. It will be made clear that external contributions will be ignored. For in the **Requirements**: > In the development of the works, the client expects that some level of open source working will be applied. This means that: > > 1. All source code and documentation developed under the agreement must be shared on a public git-supporting platform after the completion of the agreement, under the respective [open source license] and [documentation license]. > 1. The contractor guarantees, at delivery, the full portability of the development work and deliverables by providing all assets and documentation required to enable others to continue the development. > 1. Before removing any published works or repositories from the public, the contractor must provide the client with a complete as possible archive of the repository and related metadata, so the client can secure it on their own platform. > 1. Published versions must be distinguishable from each other by consistent version numbering. > 1. The licenses and copyright holders are clearly communicated throughout the source code and documentation, as is customary. > 1. Existing and proven open source components are used as much as possible > 1. The components the developed software consists of is made visible in every version through a SBOM (Software Bill of Materials) according to the CycloneDX or SPDX standard. > 1. All findings and/or improvements on existing open source components must be communicated and/or returned to the relevant communities. > 1. In case of vulnerabilities, the contractor must act as one can expect from the client's Coordinated Vulnerability Disclosure policy. > 1. When using these components, the contractor must ensure no license conflicts arise and that the terms on which they are made available are respected. > 1. The client expects that the contractor is aware that, when using open source components, they also take on a chain responsibility. This means they, together with the community, ensure the safety of the components used. > 1. If vulnerabilities come to light, the contractor must immediately take appropriate measures—with minimal impact on the users of the service—to prevent potential misuse. > 1. When a vulnerability arises, stakeholders must be informed through the appropriate channels, including at least the client. > 1. The vulnerability must be fixed as soon as possible. This can be done by implementing patches that have already been provided by the underlying community, by taking responsibility for developing a patch, or by replacing the component with one offering similar functionality. > 1. Every version of the source code must contain a metadata description according to the publiccode.yml standard. > 1. Work modularly, and develop modules as independently as possible to facilitate reuse. > 1. Sensitive and confidential information must not be shared publicly. The solution is developed in such a way that the impact of this is minimized. For example, using independent configuration files so the source code can be published. > 1. Sensitive information is made visible and actively monitored. > 1. Keep application source code strictly separate from operational data and credentials. ## Highest ambition So, de basis of option 3 *Efficiency and Independence* + *Security and Reliability* + ambition 3 from *Transparency and Trust* + ambition 3 from *Collaboration and Innovation* Suggestions for in the **Selection document** and/of in the **Descriptive document**: > The contracting authority wants that suppliers, social partners, and/or other interested parties can work together and can continue to collaborate. With open documentation on the operation of the software and design choices in the underlying source code, immediate reuse or future development is facilitated as optimally as possible. New partners should also be able to easily join the collaboration. For in the Requirements: > In the development of the works, the client expects that some level of open source working will be applied. This means that: > > 1. All source code and documentation developed under the agreement must be fully developed openly on a public git-supporting platform, under the respective [open source license] and [documentation license]. > 1. The contractor guarantees continuously, the full portability of the development work and deliverables by providing all assets and documentation required to enable others to continue the development. > 1. Before removing any published works or repositories from the public, the contractor must provide the client with a complete as possible archive of the repository and related metadata, so the client can secure it on their own platform. > 1. The contractor will be responsible for the full management of the software repositories. > 1. Both the history and progress of the development will be fully traceable, including the design choices made. > 1. The conventions for code style, version numbering, git workflow, etc., are made clear. > 1. Through well-documented governance, conventions, project objectives, and communication channels, it is made clear how other interested parties can participate in the collaboration. > 1. With open documentation on the operation of the software and design choices in the underlying source code, immediate reuse or future development is facilitated as optimally as possible. > 1. All contributions require a signed Contributor License Agreement (CLA) or an approved Developer Certificate of Origin (DCO) before acceptance. > 1. The licenses and copyright holders are clearly communicated throughout the source code and documentation, as is customary. > 1. Existing and proven open source components are used as much as possible > 1. The components the developed software consists of is made visible in every version through a SBOM (Software Bill of Materials) according to the CycloneDX or SPDX standard. > 1. All findings and/or improvements on existing open source components must be communicated and/or returned to the relevant communities. > 1. In case of vulnerabilities, the contractor must act as one can expect from the client's Coordinated Vulnerability Disclosure policy. > 1. When using these components, the contractor must ensure no license conflicts arise and that the terms on which they are made available are respected. > 1. The client expects that the contractor is aware that, when using open source components, they also take on a chain responsibility. This means they, together with the community, ensure the safety of the components used. > 1. If vulnerabilities come to light, the contractor must immediately take appropriate measures—with minimal impact on the users of the service—to prevent potential misuse. > 1. When a vulnerability arises, stakeholders must be informed through the appropriate channels, including at least the client. > 1. The vulnerability must be fixed as soon as possible. This can be done by implementing patches that have already been provided by the underlying community, by taking responsibility for developing a patch, or by replacing the component with one offering similar functionality. > 1. Every version of the source code must contain a metadata description according to the publiccode.yml standard. > 1. Work modularly, and develop modules as independently as possible to facilitate reuse. > 1. Sensitive and confidential information must not be shared publicly. The solution is developed in such a way that the impact of this is minimized. For example, using independent configuration files so the source code can be published. > 1. Sensitive information is made visible and actively monitored. > 1. Keep application source code strictly separate from operational data and credentials. > 1. If there is any intention to remove published works or repositories from the public, the client must be given the opportunity to secure them as fully as possible (publicly) on their own platform. # Frequently Asked Questions by Contractors [Go to top](#inhoud) During a tender process, contractors typically have several opportunities to ask questions in the form of a Note of Information. Below are the most frequently asked questions, along with suggested answers. * **The tender asks for further development. Does this mean we also have to make existing source code publicly available as open source?** Regardless of which open source license is chosen in this procurement, strong copyleft licenses such as the (A)GPL are not as strict as is often assumed. The (A)GPL does not make existing software that uses proprietary components completely unusable when further developed under the (A)GPL. A pragmatic approach is allowed here. Continuing to use those proprietary components is possible. The (A)GPL does require full transparency about this, so that future users understand which concessions have been made. For example, the (A)GPL includes a system library exception and allows room for additional exceptions. The main goal is that recipients of the software are not dependent on the supplier to carry out further development and maintenance themselves. The ultimate objective should be to migrate away from this situation. [Source](https://www.gnu.org/licenses/gpl-faq.html#FSWithNFLibs) * **Are we also responsible for vulnerabilities found in third-party components?** \ The contractor has a responsibility for their own upstream supply chain to (together with the community) resolve the vulnerability as quickly as possible and minimize any potential consequences. Further details are specified in the Program of Requirements under the theme "open source." Specific measures expected and the standards that must be followed to ensure the security of the source code are further outlined in the Program of Requirements under the theme "information security." * **Where does the intellectual property of the delivered source code lie?** \ The signed contract states that the intellectual property of all custom work developed under this agreement belongs to the client. This includes the full rights for each recipient to use, modify, and distribute the source code (including making it publicly available as open source), without further permission or compensation to the rightsholder. * **Can anyone do whatever they want with the open source developed work?** \ The client allows anyone to reuse the works developed under this agreement in any (commercial) context, as is customary with open source development, with respect for the open source license conditions. For reuse within the context of this tender, the applicable demands must, of course, be followed. * **How does the client expect contractors to make money from open source code?** \ Contractor gets paid by the contracting authority for all development requested under this tender. The intellectual property of the works developed for this tender belongs to the client. Naturally, contractors are free to reuse the developed source code in any other (commercial) context, given the open source nature of the tender. * **What requirements are there regarding how we should work openly with open source code?** \ Contractors are free to make choices that suit their needs as long as the requirements set out in the Program of Requirements are met. * **Can the client specify the security requirements for the repository where all open source development must take place?** \ Regarding the security of the public repository, we expect at least the following: * Access to the repository is managed by the client in its role as functional administrator (responsible for authorizations and permissions, distinct from technical hosting). * All commits must be signed with a verified key. * Changes are only made via Pull Requests with two approvals. * Enable and maintain code scanning, secret scanning, and dependency review (e.g., GitHub Advanced Security or equivalent capabilities). * **What risks do you see in the chosen approach of public open source development, and how have these been mitigated so far?** \ We see two types of risks: security risks and image risks. Security risks, in the sense that a public repository provides an additional source of information for malicious actors. However, we believe the security risks of closed source are greater than those of open source, as vulnerabilities can remain under the radar longer. Image risk, in the sense that substandard work could damage the client's reputation and thus the trust in the product's use. Both risks are mitigated by limiting the number of dependencies, documenting technical choices, inviting feedback from the community, and working professionally and diligently. * **Are there specific requirements or guidelines regarding managing third-party contributions (e.g., pull requests) to the public repository?** \ A (minimum) process must be established. The main part of this process is that external parties must sign a CLA (Contributor License Agreement). For reviewing and approving changes, the assumption is that the same process is followed as for contributions within the team. * **Have alternatives to full open source publication from the start been considered? If so, why were they rejected?** \ It was considered to only transition to open source publication after a startup phase. This was rejected to avoid a situation where a "clean-up" action would be necessary before publication could occur. # Recommendations In this chapter, there are two types of recommendations. Recommendations that can be read as a suggestion and those intended as a warning. The suggestions offer tips that can be considered for the procurement. The warnings are meant to make the contracting authority aware of the consequenties certains choices have. ## :bulb: Further Development All ambitions are framed as if the solution or component were fully custom-built. Of course, further development can also take place on existing (open source) solutions or components. It is preferable to align as much as possible with the underlying community during further development. This is the fastest way to ensure that new developments benefit the commons. If this is not possible for certain reasons, such as the time required to implement changes, unwillingness to cooperate, or simply a lack of knowledge and expertise, further development on existing open source can also take place on a copy (also called fork). This makes sure the continuity of the contract is secured, and it gives the contractor full control over the (further) developed product and the associated repositories. The small downside of working on a copy, however, is that the contractor also becomes responsible for the maintenance, documentation, security, etc. of that copy. When further developing on a copy, it's also the intention that improvements benefit the community behind the original work in line with the ambition. At the very least, they should be kept informed of all developments and be offered cooperation if willingness arises to implement the changes. Ideally, this would eliminate the need for the copy. Development on that copy should, of course, take this into account, ensuring that there is built-in flexibility to easily switch between versions; whether it's the copy or the original (updated) solution or component. When further development is done on a closed-source product, that development can be considered as a standalone open source development. ## :bulb: Sponsoring Open Source (Components) Open source software can only exist because of the underlying community working together on the software and managing it. This can involve volunteers, but also commercial and (non-profit) organizations. When using open source, you have a moral obligation to contribute in some way. This can be done by offering expertise, as suggested in the current requirements. When improvements are made to existing source code, these should flow back to the underlying communities. You are therefore putting concrete development capacity into the further development of existing code. In the Netherlands, the government has, in general, only two ways to spend money: through procurement or through a subsidy. The 'disadvantage' of both methods is that you cannot discriminate. You cannot allow certain parties to claim a procurement or subsidy in advance. So, if you want to start a subsidy program for open source, all open source projects would be eligible. Your money could then go to developers who are not working on components used in your project. For the goal social return its common practice to allocate 2% of the contract value for sociel benefits. In the same way, you can ask the contractor to donate a certain percentage of the contract value to open source projects that the contractor uses. Another possibility is donating to funds that support open source projects, such as the NLnet. In this way you contribute to the sustainability of open source projects and communities. Now, let’s say you agree on a 2% open source donation percentage, €15 million is involved in the contract, and 500 open source components are used, then each component would receive a donation of €600. Donating to 500 different open source projects would already result in a considerable workload, so this can be adjusted. It is up to the contracting authority to be creative in how this requirement is set. An example: > The contracting authority expects the contractor to allocate 2% of the total value of this contract to benefit the open source components that the contractor uses to develop the requested work. The contractor is free to distribute this amount at their judgement. The only additional requirement is that donations be made to at least 10 open source projects supported by a recognized non-profit foundation. In this case, each of the 10 open source projects would receive €30.000. For many open source projects, this would be a significant amount. ## :exclamation: Restrain Strong-Copyleft When choosing a *strong-copyleft* open source license, it is important to keep an eye on the viral effect of this license type. It is wise to limit the impact of the license to what you can oversee. Specifically, this means that you try to prevent unforeseen effects that can arise when using this type of license. For this purpose, the following sentence can be used: > In the development of the various architectures, the *viral effect* of the chosen strong-copyleft license should be taken into account. This means that the architectures are designed in such a way that this effect remains limited to the work requested in this procurement and does not influence the use of the works or any services that may be linked to this work. ## :exclamation: Should you use a Contributor License Agreement (CLA) or Developer Certificate of Origin (DCO)? In open source projects, it is common for multiple parties to contribute to the same codebase. It is therefore useful to clarify in advance how these contributions are handled legally. This does not need to be complicated, but it helps prevent misunderstandings about who may do what with the code, and under which conditions. **Contributor License Agreement (CLA)** A Contributor License Agreement (CLA) is a way to formalize the terms between a contributor and the project. The agreement states that the contributor is authorized to make their contribution under the conditions set by the receiving project. Intellectual property of the code always remains with the contributor. A CLA generally covers two key aspects: * It gives the project the flexibility to change licenses in the future without needing to seek permission from every contributor. Without a CLA, such a change would require renewed consent from all contributors, which can lead to so-called *license lock-in* if contributors are unreachable or refuse. * It provides additional assurance against unexpected copyright infringements. The contributor explicitly declares that they are entitled to make the contribution and accept responsibility for it. Important: even without a CLA, the chosen open source license always takes precedence. The CLA is therefore an addition, not a replacement. **Developer Certificate of Origin (DCO)** Another, lighter way to establish the legal framework is the Developer Certificate of Origin (DCO). With a DCO, a contributor declares for each contribution that they have the right to contribute the code and that they agree with the project’s license. This often happens through a simple check when submitting a *commit* or *pull-request*. The advantage is that it is less formal than a CLA — it does not need to be signed — while still providing sufficient assurance that contributions are properly made. **Choosing between CLA and DCO** Projects may choose a CLA, a DCO, both, or neither, depending on the size, complexity, and legal sensitivity of the project. What matters most is that the rules are clear to all contributors. This way, external contributors know exactly under which conditions their code will be accepted, and later disputes about rights or usage can be avoided. **No CLA or DCO** It is also possible to run an open source project without either a CLA or DCO. In that case, contributors are automatically bound by the project’s open source license. However, it can be helpful to state this explicitly in the documentation or in a pull-request template, to ensure it is clear to everyone. **Licenses and ownership** It is important to understand that a project’s license does not automatically apply to all its individual components — especially if you intend to reuse those components separately. The project license defines the conditions under which the project as a whole — the collection of all parts — is distributed. For example, a project may be published under the EUPL, while some individual files or modules can still be reused under MIT or Apache. For the parts of the code where you own the IP rights, you can always change the license. Once the code is combined with third-party contributions, however, you are bound by the terms under which they provided their contributions. A license change can then only be made with their consent. Also note that a license change in one module may affect the license of the project as a whole. For instance, a project cannot remain under the EUPL if a module changes from MIT to GPL — at least not in combination with that specific version of the module. # Rationale At the time of writing of this document, it is not possible to export comments from HackMD. Therefore, it is not easy to make clear which interactions (with whom) led to a particular change. To ensure that this information is not lost, a summary of these discussions, and any changes they led to, will be provided here. ## Ambitions of open source working January 15, 2025 In the initial draft of the ambition ladder, the idea was to vary all requirements on an ascending scale from 1 to 10. Whether there should be 10 ambitions was not predetermined. The idea was mainly to think through the concept together. Ambitions 1, 8, 9, and 10 were already developed. Coming up with good content for the intermediate ambitions proved to be more difficult. The following comments were made by the community regarding this setup: - Are there implicitly axes hidden in the ambitions? In this first draft, variations were made along the axes of transparency and collaboration. - If you can make those axes explicit, you can then create ambitions per axis that, when combined, lead to a set of requirements. - Would it not be more practical to align with the four categories of open source work? We quickly agreed that defining too many axes and ambitions would not be practical. In the current setup of 3 options x 3 ambitions x 3 ambitions x 1 fixed set, there are already 27 potentially different variants. Aligning with the four categories of open source work was a compromise. It allows for enough variation without getting too many different combinations. It also ensures clear communication about open source work from the Dutch government. For three of the categories, 3 ambitions/options have now been formulated from the perspective of the axes. The combination of these ambitions/options will lead to a certain ambition level and, therefore, a coherent set of requirements. ## Why require a Contributor License Agreement (CLA)? January 15, 2025 The following requirement was included in the basic set of requirements: > A Contributor License Agreement (CLA) will be established, ensuring that no contributions are accepted without the underlying legal entity having signed the CLA. This requirement naturally led to discussion. A CLA deters some developers, and some organizations have a policy against developing projects that require a CLA. The reason for still including this requirement in the basic set is multifaceted: - This is a requirement for third parties. To those wishing to contribute to the source code resulting from the contract. It is not a guideline for the internal developers should they contribute to third-party projects. - Understanding the consequences of a licensing choice requires a certain level of expertise, especially regarding the acceptance of third-party contributions. The ambition ladder must be applicable to ICT generalists. Better safe than sorry. - The CLA requirement can be dropped later, but introducing it afterward is pointles, at least if third-party contributions have already been accepted. Once a project reaches a certain level of maturity, it can always choose to remove the CLA requirement. It was decided to provide additional clarification on the application of the CLA under recommendations. September 13, 2025 The CLA essentially serves two purposes: preventing *license lock-in* and avoiding copyright infringements. For the latter, however, there is also a friendlier document: the Developer Certificate of Origin (DCO). A DCO does not need to be formally signed but can simply be approved. This makes the DCO generally more widely accepted by developers and organizations. For this reason, the DCO has been included as an alternative instrument to the CLA, with additional explanation provided in the recommendations. The DCO, however, does not prevent you from ending up in a *license lock-in* situation. ## What level of security can a contractor guarantee? February 2, 2025 The ambition ladder included the following requirements regarding secure code: > 1. The contractor is responsible for delivering secure source code. > 1. If vulnerabilities are discovered, the contractor must take immediate appropriate measures—with minimal impact on the users of the service—to prevent potential misuse. > 1. When a vulnerability occurs, stakeholders must be promptly notified through appropriate channels, including at least the contracting authority. This was responded to with concerns about who is responsible for actually fixing the vulnerability. The original text implied too much responsibility in the phrase *immediate appropriate measures*. The feedback giver correctly raised the question of who should fix the problem and who should pay for it. Should you fully rely on the community? Should the contracting authority resolve it themselves, or can they hire someone to fix it? This can include members of the community itself. As a result, the following rule was added: > 1. The vulnerability must be fixed as soon as possible. This can be done by applying patches already provided by the underlying community or by ensuring the development of a patch to resolve the vulnerability. An additional suggestion was made that the contracting authority also has the option to completely replace the component with another one offering similar functionalities. This was also added. However, it was soon concluded that it is impossible to provide an exhaustive list of possibilities. The points under 3 were then translated into suggestions. This clarifies what measures the contracting authority might consider. An abstract discussion arose regarding the entire set of requirements for secure source code. Specifically, you cannot assume that the delivered work will be free from vulnerabilities. With the following text suggestion: > The contracting authority and contractor are aware that there will be unknown vulnerabilities present in the delivered work. The core issue, according to the feedback giver, is that everything always contains vulnerabilities, many of which are still unknown. It’s all about how the contracting authority and contractor together agree on how to deal with this properly. It’s not something that should be solely placed on the contractor but requires joint effort. The feedback giver also emphasized the importance of respectful communication. If software turns out to contain vulnerabilities, it should not lead to a blame game or accusations of failure. The question of blame only arises if the contractor has failed in fulfilling their (agreed) professional responsibility. February 13, 2025 The final conclusion is that security is not within the scope of open-source procurement requirements. Information security is responsible for specifying the standards and tools directly related to source code security. What open source contributes is the relational aspect. When using free software components, you also have a duty to contribute back where possible. This contribution can take various forms. From reporting a bug to offering a solution, making a financial contribution, or becoming part of the community. Ultimately, this was translated into the term supply chain responsibility. > 1. The contracting authority expects the contractor to be aware that by using open source components, they also take on a supply chain responsibility. This means that they, together with the community, are responsible for the security of the components used. ## Should you develop on a fork or not? February 2, 2025 A question from the community was whether the ambition ladder can only be used for completely new custom developments or also for the development of existing (closed source) solutions. As a result, an informational note was added to the introductory text, stating that when development happens in a fork, it can be considered the development of a finished product. The contractor has full control over the fork and is not dependent on the underlying community in terms of business continuity. Not everyone agreed with this logic. After all, when developing in a fork, it’s uncertain whether the changes will actually flow back into the underlying community. The following text suggestion was made: > It is recommended that when developing on existing open source, this should be done as a contribution to the existing codebase. This strengthens the open source codebase and community by not only using what is already there but also contributing to the existing codebase. The problem is that the underlying communities do not always accept changes to the existing codebase. There can be several reasons for this: 1. The changes are not seen as improvements because, for example, they don't align with the community's vision or are too context-specific. 1. The community lacks the knowledge and expertise to manage the new changes. 1. The community lacks the capacity to assess the improvements at the pace required by the project. Working in a fork provides the greatest certainty that the development will lead to the result the contracting authority had in mind. In the ambition ladder itself, the requirement is stated: > All findings and/or improvements to existing open source components must be reported and/or returned to the relevant communities. Thus, the contracting authority is indeed expected to ensure that these improvements benefit the underlying community. However, this is separate from how the community itself assesses these improvements. Nevertheless, the ideal of open source work is, of course, to collaborate harmoniously on software, ideally with the underlying community. The original text was expanded based on this ideal, with the fork as a second option. 12 februari 2026 Following the previously mentioned conclusion that this does not necessarily fall within the scope of open source procurement requirements, it is also the case that the Cyber Resilience Act (Regulation 2024/2847/EU), in Chapter II, addresses many of the issues concerning the interaction between the “manufacturer” (i.e., the Contractor) and open source communities after vulnerabilities are discovered. Many of the above requirements have therefore been replaced in the text with a reference to this part of the Cyber Resilience Act (Regulation 2024/2847/EU). ## Reusability of the development September 22, 2025 Open source is widely valued for its reusability, also on other platforms. Because open source solutions aren’t tied to a single vendor, they usually don’t lock users into one ecosystem. If a solution isn’t yet available on another platform, it can generally be adapted easily to work there. A clear example is cloud tools. Cloud-native tooling can lock you into a single provider, whereas open source technologies such as PostgreSQL, NGINX, Terraform, and containers enable you to switch between providers. Reusability, however, isn’t only about the final solution. It also applies to the knowledge that are needed to build it, including source code, assets, and documentation. In custom tenders, the initial contractor naturally builds a head start in knowledge. Without proper measures, this knowledge advantage can discourage others from continuing the development work, creating a form of vendor lock-in—also when the software itself is open source. To prevent this, tenders should ensure the reusability of both the solution and the underlying knowledge. By making all relevant code, assets, and documentation accessible and understadable, other contractors or internal teams can contribute, take over, or continue development without disadvantage. For this reason, an additional requirement was introduced: > The contractor guarantees continuously, the full portability of the development work and deliverables by providing all assets and documentation required to enable others to continue the development. # Projects This ambitionladder is been succesfully used in the following procurements. | Project | Organisation | Procurement value | | -------- | -------- | -------- | | Persoonlijke Gezondheidsomgeving | Dutch Ministry of Health, Welfare and Sport | € 15,- million | | CumuluZ subsidy for the Landelijk Dekkend Netwerk | Dutch Ministry of Health, Welfare and Sport | € 11,- million | | PoC's en Pilots for the Generieke Functies | Dutch Ministry of Health, Welfare and Sport | € 10,- million | | Elektronisch Kandidaatstellingssysteem (e-KS) | Dutch Election Counsil | € 3 tot 5,- million | # Contributors [Go to top](#content) Thanks to everyone mentioned by name here, as well as all the contributors who wish to remain anonymous. * Maurice Hendriks (Main author; Ministerie van Volksgezondheid, Welzijn en Sport) * [Marc van Andel](https://www.linkedin.com/in/marcvanandel) (Kadaster) * Joeri Bekker (Maykin) * [Mike Gifford](https://www.linkedin.com/in/mgifford/) (CivicAction) * Johan Groenen (Tiltshift) * Mitch Hak (Ministerie van Volksgezondheid, Welzijn en Sport) * Rutger Haagsma (Ritense) * David Heijkamp (Naturalis) * Michael Meagher (Open Ireland Network) * Marlena van Ooijen (Logius) * Nico Rikken (Alliander) * Eva van Sloten (Ministerie van Binnenlandse Zaken en Koninkrijksrelaties) * Job Spierings (Amsterdams Fonds voor de Kunst) * Manfred Zielinski (Ministerie van Binnelandse Zaken en Koninkrijksrelaties) --- This text is available under the CC-BY-4.0 \ [![hackmd-github-sync-badge](https://hackmd.io/Fhj24cTRRm2FKjhuUyN3Xg/badge)](https://hackmd.io/Fhj24cTRRm2FKjhuUyN3Xg) >[!Note] License > > {%hackmd NM4kkB6ESKuQ1pIJFKmYzA %}

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.