News from the blog

By Pamela Chestek on 26 Jan 2023

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.

Recommendations of the License Review Working Group for discussion.

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.

License submission process

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.

For all licenses, the submission process will:
  • 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).
For new licenses, the license submitter will also
  • 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.

License approval standards New licenses

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.
Legacy licenses

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.

License categories

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.
Work that the OSI will not undertake

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.

By Javier Perez on 25 Jan 2023

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! 

By Simon Phipps on 24 Jan 2023

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.”

OSI’s recommendation

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.

By OSI Staff on 17 Jan 2023
BigBlueButton is an Open Source virtual classroom started in 2007 by OSI sponsor, Blindside Networks. What differentiates...
By Mick Semb Wever on 4 Jan 2023
Apache Cassandra is getting ready for its 5.0 release in spring 2023, together with the Cassandra Summit. Register now.

To promote and protect open source software and communities...

For over 20 years the Open Source Initiative (OSI) has worked to raise awareness and adoption of open source software, and build bridges between open source communities of practice. As a global non-profit, the OSI champions software freedom in society through education, collaboration, and infrastructure, stewarding the Open Source Definition (OSD), and preventing abuse of the ideals and ethos inherent to the open source movement.

Open source software is made by many people and distributed under an OSD-compliant license which grants all the rights to use, study, change, and share the software in modified and unmodified form. Software freedom is essential to enabling community development of open source software.