On the USA’s Independence Day, 2020, the Open Source Initiative posted an announcement about the formation of at least one new committee to examine the current list of OSI-approved open source licenses. As at least initially presented, this committee does not have specific outcomes it is expected to achieve, although the announcement indicates that the committee might very well:
· Reevaluat[e] the criteria for approving licenses, potentially setting different standards for licenses in use versus new licenses
· Reevaluat[e] the process for considering licenses for approval, including whether the OSI should itself nominate licenses for approval
· Reevaluat[e] the current categories for licenses, including how they are used and their usefulness
· Evaluat[e] whether there should be a process for decertifying licenses, and what the process and standards would be for the process
For those unfamiliar with the long (now 20 year) history of the OSI and the long-standing debate about the issue of “license proliferation,” the formation of this committee looks to be directed to tackling that issue – at least in part – for the second time. In 2004-2006, this issue was raised – and a committee was formed – to look into the ever-increasing number of licenses being submitted and approved by the OSI. At the time this committee was formed in 2004, there were about 50 OSI-approved open source licenses; today, in 2020, there are over one hundred.
I was a member of the 2004-2006 committee, and the history of that committee, its deliberations, its initial conclusions, and the ultimate report accepted and published by the OSI, would make a fascinating historical study (or oral history). Many of the people on the committee are still around and active in open source (or open source adjacent) activities, although a few of the participants have disengaged – sometimes in rather public ways – from the OSI and its activities.
Whether “license proliferation” is a problem is one I’ve been of two minds of over the years. When I joined the license proliferation committee in 2004, it seemed like a problem that really needed to be tackled (and I personally felt the end result of that committee’s work didn’t adequately tackle the issue). As more and more initiatives were put in place within the tech industry – OpenChain, SPDX, REUSE, and the Linux Foundation’s efforts to create an industry-developed Automated Compliance Tooling – the proliferation “problem” seemed like one that could be soluble using technology. For larger companies who have the resources to commit to developing a robust Open Source Program Office (OSPO), this very well may be the case. But for smaller companies without an OSPO or struggling to set them up, seeing an OSI-approved list of over 100 different licenses can be quite daunting.
It is not just the license list and the process for approving licenses that may ultimately be reviewed by the OSI – they have also indicated that:
"This Working Group will not be investigating or evaluating whether the Open Source Definition should be revised. That project is likely to require a different assortment of participants than this proposed Working Group, so a review of the OSD is more appropriately undertaken separately."
I have been on record – and in fact made it a part of my (unsuccessful) candidacy for the OSI Board earlier in 2020 – as saying that the OSI ought to relook at not only the license approval process, and the full list of licenses that have been approved – but the Open Source Definition itself. As a personal matter, I’m pleased to see the OSI look into tackling these questions (or tackling them again), as in the 15 years since the License Proliferation Committee upon which I sat, much has changed, much has been learned, and the fundamental understandings of what are and aren’t “open source” licenses are being tested as never before. It will be healthy for the OSI to reexamine some of the language currently in the OSD – which contains certain ambiguities, in my opinion, that has caused frustrations for some license submitters – as well as the current list of licenses – to see if some of the assumptions that were made in approving them may no longer be operative anymore.
For those of you who work with these licenses frequently – as developers, attorneys, or businesspeople – I encourage you to support this effort by the OSI, and if you are so inclined, to volunteer for the committee (or committees) being formed to confront these fundamental questions.