SPDX License List: The year in review
by Jilayne Lovejoy, Legal team Co-Chair
Version 2.2 of the SPDX License List is now available and it seemed like a good opportunity to provide a summary of updates that have occurred over the last few releases and other related news.
In case you are new here, the SPDX License List is a list of commonly found open source licenses and exceptions for the purposes of being able to easily and efficiently identify such licenses and exceptions in an SPDX document (or elsewhere). The SPDX License List includes a standardized short identifier, full name for each license, vetted license text, other basic information, and a canonical permanent URL for each license and exception. The master files for the license list comprise of a spreadsheet and text files. From this data, the HTML web pages at spdx.org/licenses are generated. There are other ways to access this data, including RDFa machine readable access and a JSON file. For more information, check out the tech report, Accessing SPDX Licenses.
As of version 2.2, the SPDX License List contains 306 licenses and 24 license exceptions. The spreadsheet in the master files includes columns indicating changes for each release, but here are some highlights of the last four releases:
Version 1.20 saw the biggest single increase in the number of licenses added at 87. 77 of these new licenses were a direct result of the SPDX legal team going through the Fedora license list to attempt to provide more cross-list representation. Although not every license on the Fedora list is on the SPDX License List, this was a huge step in the right direction. A cross-reference of short identifiers is available, as well as a list of Fedora licenses that are not (yet?) on the SPDX License List. If you want to see something added from here or help further this work, please let us know!
Version 2.0 was a big change for both the SPDX specification and the license list. The addition of the license expression syntax now allows greater flexibility in representing licenses or license combinations. This included the + operator to indicate an “or later” license and the “with” operator to indicate a license exception. Consequently, some licenses were deprecated and exceptions were moved to their own list to allow for this new expression language in v2.0.
Also as of version 2.0, the legal team decided to implement a quarterly release of the license list to provide more predictability. Of course, if circumstances warrant a sooner release or if there are no changes during a quarter, then we will adjust that schedule as needed.
Version 2.1 added 5 new licenses and 12 new license exceptions. A lack of exceptions was always been a weak point for the SPDX License List. A couple members of the Legal team scoured the internet for as many license exceptions as they could find, with the goal of adding more license exceptions post-2.0 release. As such, we added 12 licenses exceptions in version 2.1 and 3 more in version 2.2 from this research and will continue to explore other additions.
Version 2.1 and 2.2 also saw 5 new licenses added each. These licenses included a few more from the Fedora list review that needed clarification.
So, now you are up-to-date with changes to the license list. A huge thanks to the participating members of the SPDX legal team who come together every couple weeks to make this all happen, as well as other work in between! Look for the 2.3 release just in time for the New Year.
The Supply Chain Mini-Summit aims to bring together researchers, implementers and assurance professionals from supply chain, license compliance and security domains to explore ways we can improve the automation of information to create a more efficient and accountable software supply chain. We will be looking at ways to make compliance information more transparent, accurate and accessible; as well as how we can link it in to the security vulnerabilities and weaknesses in a more effective manner. For more information go here: Supply Chain Summit
Jilayne will be giving a talk at LinuxCon Europe entitled “Developers Care About the License: Using SPDX to Describe License Information“. Adoption of open source software is dependent on being able to communicate license information. With some of the open source packages and distributions containing hundreds of contributions and a wide variety of licenses, having a consistent and precise way of communicating the licenses is a challenge that the SPDX workgroup has taken on….
For date and time and more information check out the schedule.
There will be an SPDX tools bake-off for the 2.0 specification on Monday the 17th. Here are the details and feel free to drop by:
Virginia Room (located on the 4th floor, Union St side of hotel)
9:00am – 1:00pm
Our own Gary O’Neall, tools maintaner for SPDX, is giving a talk on SPDX entitled “Describing License Information in SPDX – It’s Easier Than You Think“. Donit miss it!
Gary’s talk will be on Tuesday at 10:30am: http://sched.co/3YJ1
SPDX 2.0 brings with it a number of features, but the ability to represent relationships and hierarchy is the biggest enhancement. We starting planning in earnest for this capability and 2.0 in 2012, but actually had considered building hierarchy into the original 1.0 work. Early on decided it was too big a chunk to bite off as a first step, though we always knew it would eventually be a requirement. Version 2.0 makes this all a reality. And, in parallel with Version 2.0 comes a version of the license list leveraging the elegant new syntax for license expressions.
A number of companies have gotten great value from both the SPDX 1.X and the SPDX License List without which the project would have fizzled years ago. There’s an apt old joke: “God created the heavens and earth in seven days…but he didn’t have an installed base to worry about.” We did have to worry about the SPDX early adopters. Kudos to the technical team for deftly balancing the needs of existing users with the aspirations and requirement a brave new spec. In the end, the capabilities of SPDX have been immensely expanded, but it its language remains 90% common with the previous version and 1.2 docs remain compatible with the new version.
Surely there will be incremental improvements going forward, but 2.0 is the biggie and addresses the needs of the majority. Time to cross the chasm!