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