News from the blog

OSI to contribute to Digital Public Goods Alliance’s mission to address world’s most pressing economic challenges by furthering adoption of Open Source software

BRUSSELS – February 4, 2023–Today, the Open Source Initiative (OSI) announced it has joined the Digital Public Goods Alliance (DPGA) as a new member. The DPGA is part of the response to the United Nation’s call to end poverty, protect the planet and improve the lives and prospects of everyone, everywhere.  The announcement was made as part of the opening keynote at the Free and Open Source Developers Meeting (FOSDEM) and celebration of OSI’s 25 year anniversary.

The DPGA is a multi-stakeholder initiative with a mission to accelerate the attainment of the Sustainable Development Goals (SDGs) in low- and middle-income countries by facilitating the discovery, development, use of and investment in digital public goods. Digital public goods are Open Source software, open data, open AI models, open standards and open content that adhere to privacy and other applicable laws and best practices, do no harm by design and help attain SDGs.

“OSI is the leading voice advancing the policies and principles of Open Source globally,” said Stefano Maffulli, executive director of the OSI. “The OSI helps build a world where the freedoms and opportunities of Open Source software can be enjoyed by everyone, regardless of income and resources. The OSI supports institutions and individuals—from governments and corporations to local economies and individuals—working together to create communities of practice in which healthy Open Source ecosystems thrive. OSI’s work in championing software freedom goes hand in hand with DPGA’s mission.”

Lucy Harris, DPGA co-lead stated, “Welcoming the Open Source Initiative is a milestone for the Digital Public Goods Alliance. OSI’s role as steward of the Open Source Definition, and promoter of Open Source community-building, education and advocacy is of vital importance to digital public goods. The Open Source requirement is a cornerstone of the Digital Public Goods Standard, and OSI’s membership is a manifestation of that importance.”

“The DPGA is already making significant progress on aligning, coordinating and advancing the contributions of its many members and stakeholders, and OSI is eager to lend our advocacy and educational efforts to the cause as well,” said Deborah Bryant, US policy director for OSI. “Our licensing clinics for the public sector, our Deep Dive AI education series, and our State of the Source event—all designed as open content—are three initiatives that are perfectly aligned with the DPGA mission and will be included in the 2023 roadmap. We’re grateful for the opportunity to lend OSI’s expertise to DPGA members and leaders as Open Source software remains a critical strategy to the roadmap’s impact in the future.”

OSI’s work aligns with that of the DPGA in many ways, including these three OSI initiatives that will be included as part of the DPGA’s Annual Roadmap for 2023:

1. Open Source License Clinics (Public Sector): OSI will conduct license clinics in 2023 modeled after a successful clinic in 2012 to educate and prototype a replicable program for additional geographies. This will include emerging topics such as the use of data in AI models.
2. “Deep Dive AI” Education Series: AI training models are predominantly licensed as Open Source software; however, the training data is not necessarily open. It is imperative to foster a deeper understanding of how these elements work together, who may benefit and who may not. Last year OSI initiated its Deep Dive AI podcast series and online panel discussions to illuminate these issues. In 2023 OSI will host additional online conversations to drive awareness and understanding of AI, machine learning and deep learning.
3. State of the Source Summit: OSI produces an annual State of the Source Summit, a broad international platform to mark progress in the advancement of the use of Open Source and open collaboration.

To learn more about DPGA, visit https://digitalpublicgoods.net/ or email [email protected].

To learn more about the news and opinions of the OSI and its stakeholders, visit the OSI blog and sign up to receive the newsletter.

The European Commission’s proposed Cyber Resilience Act (CRA) as drafted may harm Open Source, and perhaps all other non-industrial software.

There were 131 responses to the proposed text that the Commission has sent to the Parliament, including one from the Open Source Initiative. Of those, 18 responses – representing a significant proportion of Europe’s software industry – shared OSI’s concerns to some degree. Here are some sample points from the responses:

• “We recognise that the European Commission has framed an exception in recital 10 attempting to ensure these provisions do not accidentally impact Open Source software. However, drawing on more than two decades of experience, we at the Open Source Initiative can clearly see that the current text will cause extensive problems for Open Source software.”
• “OSI recommends further work on the Open Source exception to the requirements within the body of the Act to exclude all activities prior to commercial deployment of the software and to clearly ensure that responsibility for CE marks does not rest with any actor who is not a direct commercial beneficiary of deployment. Leaving the text as it is could chill or even prevent availability of globally-maintained open source software in Europe.”

• “Replacing the current general freedom to publish software with a new system that imposes a set of CRA requirements constitutes a significant disruption to open innovation in Europe. The current formulation of the CRA interferes with almost every software development model other than the case of a single company developing the entire code-base behind closed doors and making periodical releases. This model was common until the late 1990s, but much less so now.”
• “If a security vulnerability is discovered in software used in Europe, the liability and technical requirements of the CRA, in its current form, would place a hurdle in front of anyone in Europe working on a fix.”

• “On the other hand, the CRA ignores the security risks associated with files created by the software covered by the act itself, which can have even more devastating consequences (according to security expert Kaspersky Labs, in 2018, 70% of all malware worldwide was carried by documents created by the most widely used office suite).”
• “For the purposes of the Cyber Resilience Act, there is a real risk that software based on LibreOffice technology will be considered to be made in the course of a commercial activity, and thus subject to the legislation”

• “when defining a notion of commercial activity regarding open source software, the CRA provides examples of the creation and/or use of open source software that are typically understood as non-commercial but would fall under this definition of commercial activity”
• “This creates legal uncertainty for developers and is bound to result in a chilling effect on the very ecosystems that have often acted more responsibly, by and large, in dealing with security defects in their software than proprietary actors.”

• “While we applaud the efforts of the European Commission to enhance the cyber security of products with digital components, we fear that the CRA could create a series of unintended adverse consequences to the security and stability of Open Source Internet Infrastructure Software – and by extension to the Internet.”
• “We feel that the regulation as applied would impose disproportionate regulatory compliance burdens on developers and curators of “critical products” that will strain their existing capacity while failing to enhance the security or stability of this type of software”

• “It is important to preserve the incentives for software developers to contribute to open-source projects and to continue to utilize such resources and tools in their work, without the pressure of legal liability.”

• “RIPE community members pointed out that the current open-source ecosystem is a complex one in which there is often no clear distinction between commercial and non-commercial products, as product development is an ongoing process that builds upon itself with designs, technologies, standards and code being shared in myriad ways for myriad purposes. This rich interplay and open access are the very features of the open-source ecosystem that allow for innovation — and which strengthen resilience and security.”
• “It is our understanding that the CRA intends to cover any software and hardware product, and its remote data processing solutions, that is connected to the Internet (either logically or physically) and which is placed on the market as an independent product to be distributed for end use. In other words, it is our understanding that software that is connected to the Internet but is not placed on the market as a product with the aim to be distributed to end users — such as, for example, a customer portal — would not fall under the scope of the CRA. However, the proposal is not explicit about this point, and further clarity is therefore needed.”

• “However, it is worth noting that there are many open-source projects that create products that could fall into most categories of critical software products, and open-source software is often incorporated into other products that are sold on the market. This could create uncertainty for open-source developers regarding their obligations related to conformity assessment. Legislators should seek to preserve incentives to develop and maintain open-source software by preventing any possibility that it could be classified as “commercial activity.””

• “However, the recital’s broad interpretation of ‘commercial activity’ does not accurately reflect operational best practices, governance and licensing in an OSS context.”

• “There could be a significant imbalance between open-source ventures compared to commercial software counterparts, with open-source ventures developing very widely implemented software components, but often receiving a fraction of the commercial benefit that commercial software ventures would (when also including the same component). Considering that open-source also drives innovation and rapid advancement in almost all areas of critical products, it is necessary to include additional ringfencing around the specific CRA requirements for open-source products, including those used in “commercial activities” to avoid constraining or burdening essential open source activities and ultimately stifling open-source innovation and contribution within the European Union.”

• “Recital 10 excludes open source software that is not used in the course of a commercial activity but does not define the term or give details on how to assess the intended use and/or the determination of the intended use and/or a default category if no determination was done in advance.”

• “The definitions, while generally sound, are a matter of concern for the developers of open-source software, who see a lack of distinction between open-source software distributed on a not-for-profit basis and commercial software. eco recommends exploring the further implications and harmful effects for the development of open-source software for deployment in the market on a not-for-profit basis.”
• “The definition of “unfinished software” in Article 4(3) is not in line with the current status of product and software development. It specifically contradicts the premises and conditions for the deployment and use of open-source software. eco recommends further exploring the topic so as to avoid unintended detrimental effects on the European software industry.”

• “the Act would discriminate against certain types of software and of software makers for which the main motivations are not economic, but that still generate some form of financial return to support the development of their code, and thus cannot be considered “non-commercial”. For example, this includes software developed by universities and public research centres, including some basic applications that make the entire Internet work; software developed by individual developers, mostly in their spare time; software that is meant to increase privacy and freedom of expression, such as encrypted communication apps, decentralized social media and anonymous browsers; and much more. To this regard, the weak exception for non-commercial open-source software is entirely insufficient to solve the issue.”

• “However, the scope of “commercial activity” is unclear and risks bringing into scope activities that are not placing a product on the market per se.”
• “[paid] services and general financial support do not change the fact that these open source projects and developers are not placing software onto the market as a paid product.”
• “Annex I requires delivery “without any known exploitable vulnerabilities” but this risks an unobtainable objective, as manufacturers regularly learn of new vulnerabilities and make risk-based assessments on the need to prioritize fixes for timely delivery of product updates. … Similarly, the vulnerability handling requirements outlined in Annex I raise concerns. In particular, the requirement to “remediate vulnerabilities without delay” may undermine established practices of coordinated vulnerability disclosure and risk-based assessments from manufacturers on when to push and how to coordinate security updates”

• “As currently drafted – perhaps unintentionally – the text targets  open-source not for profit foundations rather than targeting the organizations that leverage open source for commercial activity.”

• “There is ambiguity resulting from the intersection of OSS with “commercial activity,” both in the context of infrastructure and services provided to open source projects and with regard to activities that open source projects may pursue while building OSS.”
• “the infrastructure and services provided to open source projects should be out of scope, regardless of commercial status.”
• “Commercial services enabling the effective use of OSS, such as technical support and consulting services, should also be out of scope and not bring OSS offerings into scope.”

• “Specifically, various organizations, like Sonatype, maintain and make available FOSS free of charge as a benefit to the FOSS community (including through maintaining publicly accessible projects or repositories), while also charging for optional, ancillary services. The commercial activity qualifier as currently drafted could be read to eliminate the FOSS exemption for these organizations, which would leave them with an unenviable choice: either incur substantial costs and undertake significant effort to comply with the substance of the Regulation in maintaining free FOSS repositories, or shut down the public repositories (either altogether or just to entities originating from the EU).”

Some time ago the Open Source Initiative formed a working group to examine and improve the license review process. The stated purpose of the working group was to:

• Reevaluate the criteria for approving licenses, potentially setting different standards for licenses in use versus new licenses
• Reevaluate the process for considering licenses for approval, including whether the OSI should itself nominate licenses for approval
• Reevaluate the current categories for licenses, including how they are used and their usefulness
• Evaluate whether there should be a process for decertifying licenses, and what the process and standards would be for the process

The OSI has a parallel undertaking investigating how to improve the tooling that will be used for the license review process and also how to best serve the public in the ways we provide information about Open Source licenses. Although the tooling project and the work of the License Review Working Group are intertwined, the below conclusions of the License Review Working Group are focused on the requirements and policy that will inform the tooling project, but do not include the tooling project itself.

The License Review Working Group was originally scoped to discuss the delisting of licenses, but we did not reach the topic. It is a challenging subject because it means that the OSI first needs to learn who is using the licenses that may be considered for delisting and understand what effect it might have on them if their license undergoes a change in status. We therefore eliminated this topic from the mandate of this working group and recommend that it be taken up by a new working group dedicated to this subject alone.

Legacy licenses – A “legacy” license is one that has been in use for at least five years by more than twenty projects maintained by different unrelated entities.

New licenses – a “new” license is any license that is not a legacy license.

We have received feedback that it is very difficult to navigate the review process because it is not clear the role of the license-review email list and its relationship to the OSI. License submitters do not know how much weight to give to the comments made on license-review. The OSI will provide more explanation for the public on the decision making process and in particular the role of the license-review list participants.

• Require that the license submitter affirmatively state that the license complies with the Open Source Definition, including specifically affirming it meets OSD 3, 5, 6 and 9 (the points that historically have been more problematic).
• Identify what projects are already using the license, if any.
• Ask for the identity of the license steward, if known. The OSI will try to get in touch with the license steward if the license submitter is not the steward.
• Provide any additional information that the submitter believes would be helpful for license review. For example, approval of the license by Debian, the FSF or the Fedora Project would be relevant to the review process.
• Provide a unique name for the license (preferably including the version number)
• Identify any proposed tags for the license (see below regarding tagging).

• Describe what gap not filled by currently existing licenses that the new license will fill.
• Compare it to and contrast it with the most similar OSI-approved license(s).
• Describe any legal review the license has been through, including whether it was drafted by a lawyer.
• Provide examples of others’ potential use of the license to demonstrate that it is not a license that is uniquely usable only by the license submitter.

In both categories, approval of a similar license in the past does not bind the OSI to approval of a newly submitted license.

In addition to meeting the OSD, the following standards apply to new licenses:

• The license must be reusable, meaning that it can be used by any licensor without changing the terms or having the terms achieve a different result for a different licensor.
• The license does not have terms that structurally put the licensor in a more favored position than any licensee.
• To the extent that any terms are ambiguous, the ambiguity must not have a material effect on the application of the license.
• It must be grammatically and syntactically clear to a speaker of the language of the license.
• Every possible variation of the application of the license must meet the OSD.
• It must be possible to comply with the license on submission. As an example, given the scope of copyleft in the SSPL, it is not a license that anyone currently would be able to comply with.
• The license must fill a gap that currently existing licenses do not fill.

The license must meet the OSD. No suggestions for changes to the text of legacy licenses will be considered. The license will be approved, or not, as written. The historical context of the license and the common understanding of its meaning will be considered when deciding whether it can be approved.

The Working Group has decided that the current categorization system of popular licenses and all approved licenses, adopted to prevent license proliferation, was very beneficial when it was adopted but is no longer needed for the purpose. Rather than continuing the current categorization of licenses, the OSI plans to adopt a tagging system for licenses. These tags will aid third parties in identifying licenses suitable for their use case. The OSI intends to crowdsource volunteers for both creating a list of tags and adding the tags to the licenses and will be seeking volunteers for that task as the next stage of the project.

In order to continue the success of the anti-proliferation work, the License Review Working Group proposes, in addition to tagging, three categories of licenses:

• Rejected. This category is for licenses that have been considered and rejected.
• Approved. This category is for licenses that meet the minimum standard to be an OSI-approved license.
• Preferred. This is conceptually what the category “popular and widely-used or with strong communities” was designed to fill. The intent is that this category will be objectively created from data using adoption metrics and also a quality filter that is tagging-based. For example, a required forum provision in a license is not a disqualifier, but it is disfavored. A license with a required forum provision might not pass the filter.

The OSI will not recommend licenses, other than categorizing as above, and will not try to provide advice on what licenses should be adopted for any particular use case. It would require resources that the OSI does not have to create and maintain this complex information. It is also an area that generally requires the services of lawyers or open source advisors, who can engage more deeply with projects or companies in order to provide them with advice specific to their needs and desires

To collect feedback on this proposal, we’re going to use annotations on the wiki. You will need to register to leave a comment. Highlight the text, hit CTRL-M, type your comment, save the annotation. More information on Xwiki help. The OSI will keep the discussion open for four months.

For the second year in a row, the Open Source Initiative and OpenLogic by Perforce collaborated to launch a global survey about the use of Open Source software in organizations. We drew hundreds of responses from all over the world, and once again, the results are illustrative of the Open Source space as a whole, including use, adoption, challenges, and the level of investment and maturity in Open Source software. 

The 2023 State of Open Source Report presents key usage, adoption, and trend data that paints a complete picture of Open Source software in organizations today. The report also includes a breakdown of the most important technologies by category, and across demographics and firmographics. 

The world of technology is constantly changing, and it can be hard to stay up to date on the latest software. The report features more than 160 of the most popular Open Source technologies and tools, as well as insights into how organizations are investing in Open Source and the most desirable technologies.  

We encourage you to read sections of interest or the whole report, which covers every major category including Linux distributions, infrastructure software, cloud-native, programming languages and runtimes, frameworks, data technologies, SDLC and build tools, automation and configuration tooling, and of course, CI/CD. 

Some of the key findings: 

• Open Source continues to grow in prominence; 4 in 5 survey respondents, a whopping 80%, indicated that they increased the use of Open Source software in their organizations in the past year, with 41% reporting a “significant” increase.  
• Open Source technologies play an integral role in all types of operations. Respondents listed Linux, Apache HTTP, Git, Node.js, WordPress, Tomcat, Jenkins, PHP, and NGINX as the most business-critical software for their organizations.  
• Container technology and software development lifecycle (SDLC) tools ranked as the most used technologies. Container and container orchestration jumped from 18% to 33% of respondents’ usage, and they also received the highest amount of investment by organizations. 
• Cost reduction is no longer a key reason for Open Source adoption. In the 2022 report, the lack of license cost and overall cost reduction was the second most common reason for using Open Source, but this year it has dropped to ninth place.  
• The top Open Source adoption driver remains access to innovations and the latest technologies, illustrating how users value being on the cutting edge and see this as a competitive advantage. Organizations also choose Open Source due to the ability to contribute to, and influence the direction of, projects.  
• Security is top of mind. Maintaining security policies or compliance is the top support challenge for organizations using Open Source. Over 46% of organizations are performing security scans to identify vulnerabilities. 
• Technical support is needed for installations, upgrades, and configuration issues. Notably, personnel experience and proficiency again this year is highly ranked as a support concern across organizations of all sizes.  
• End-of-life (EOL) Open Source software remains in organizations for a long time. Nearly 12 months after AngularJS became EOL, 15% of organizations are still using it, the exact same percentage we saw in the 2022 report. In larger organizations, it’s up to 20%. As expected with EOL CentOS Linux, there was a decline in usage; it’s now at only 15.14%, while CentOS Stream and Rocky Linux became more widely adopted.  
• 36.79% of organizations contribute to Open Source, which includes contributions to projects or to organizations (code or other activities). This is a 5% increase from last year, so it’s trending in the right direction and is a good sign for many communities. 
• Over 25% of respondents in most industries are generating software bill of materials (SBOMs). Retail, government, banking, insurance, and financial services lead this category with the highest implementation of SBOM generation. 
• OSI’s membership has grown over the last year; 17% of respondents already sponsor OSI. We are encouraged by growing community participation and excited for all upcoming OSI initiatives and events in 2023. 

The 2023 State of Open Source Report clearly demonstrates how many organizations are moving from being merely consumers to engaging with Open Source communities and gaining expertise in full technology stacks. In some cases, they are even becoming leaders — driving and influencing the direction of new projects. Be sure to download the report and stay tuned for more content, analysis, and webinars in the coming weeks and months from OSI and OpenLogic by Perforce! 

The Cyber Resilience Act (CRA) is an interesting and important proposal for a European law that aims to drive the safety and integrity of software of all kinds by extending the “CE” self-attestation mark to software. And it may harm Open Source. The proposal includes a requirement for self-certification by suppliers of software to attest conformity with the requirements of the CRA including security, privacy and the absence of Critical Vulnerability Events (CVEs).

OSI has submitted the following information to the European Commission’s request for input on its proposed Cyber Resilience Act text.

We recognise that the European Commission has framed an exception in recital 10 attempting to ensure these provisions do not accidentally impact Open Source software. However, drawing on more than two decades of experience, we at the Open Source Initiative can clearly see that the current text will cause extensive problems for Open Source software. The problems arise from ambiguities in the wording and a framing which does not match the way Open Source communities actually function and their participants are motivated.

First, for those distributing software as a community function to confidently rely on the exclusion, this absolutely must be inserted as an article and the “should” must be changed to “shall”.

Second, since the goal is—or should be—to avoid harming Open Source software, which the European Commission is working hard to support, this goal should be stated at the start of the paragraph as the rationale, replacing the introductory wording about avoiding harm to “research and innovation” to avoid over-narrowing the exception.

Thirdly, the reference to “non-commercial” as a qualifier should be substituted. The term “commercial” has always led to legal uncertainty for software and is a term which should not be applied in the context of open source as specific commercial uses of open source projects by some users are frequently disconnected from the motivations and potential compensation of the wider community of maintainers. The software itself is thus independent of its later commercial application.The problem is not the lack of a taxonomy of “commercial”, it is the very act of making “commercial” the qualification rather than, for example, “deployment for trade”. Thus adding a taxonomy of commerciality is not a solution. OSI would be pleased to collaborate over better approaches to qualifying an exception.

To illustrate the concern our community feels, we wish to highlight an analysis by OSI affiliate Eclipse Foundation, based in Brussels. While they note that, with staff and financial resources, they are “in a better position than most” to deal with such requirements, they conclude that “we fear that the obligations set forth by the legislation will cripple the Eclipse Foundation and its community.”

The Open Source Initiative assumes the Act is not intended to negatively impact the communities that make Open Source software or burden the non-profit foundations that support them.

Therefore OSI recommends further work on the Open Source exception to the requirements within the body of the Act to exclude all activities prior to commercial deployment of the software and to clearly ensure that responsibility for CE marks does not rest with any actor who is not a direct commercial beneficiary of deployment. Leaving the text as it is could chill or even prevent availability of globally-maintained open source software in Europe. We also support the more detailed analysis we have co-signed with Open Forum Europe.