Submitted by Phil Odence on November 14th, 2013
SPDX is healthy. It’s early to be popping champaign corks, but the party is in full swing and the doors are open so come on in.
Awareness is building and, especially recently, we are discovering more companies working with the standard. A survey the Business Team conducted last Springindicates that people felt SPDX is addressing a real market need, even those not aware of SPDX per se. Linux Foundation continues to support and, in fact, is putting more emphasis on SPDX and compliance in general. For example, Jim Zemlin has talked about SPDX in his last several keynotes and will stress it central to the Open Compliance Program at the upcoming summit in Yokohama. The standard is evolving more slowly than some would like but is currently in a usable state. The groups tools are still immature, but useful, and there are a few commercial tools available as well. All we need to move faster is a few more active participants on the team.
Release Status
With the recent release of v1.2, we are now in our third generation. Most of the changes in this latest release came out of a bake-off we held at the Collaboration Summit early last Spring. Some inconsistencies between tools pointed to problems and ambiguities in the spec, which were tightened up in 1.2. Wind River, the most active early adopter, feels that with v1.2, SPDX is highly usable and is delivering SPDX docs to customers in lieu of large piles of paper.
Work now continues on v2.0. This major release has been under development for more than a year. The main new feature will be hierarchy. Today, SPDX files are fairly flat with package level and file level info and nothing in between. 2.0 will allow SPDX files to incorporate other SPDX files following the hierarchy of the packages they describe.
Adoption
Awareness and adoption are still light but seem to be accelerating. What’s become clear is that many companies who have no active involvement in the SPDX work group, are finding enough publicly available information (from this site) to start to work with it on their own.
License List
The license list is a key component for SPDX. It includes a standardized short identifier, full name for each license, vetted license text, other basic information, and a canonical permanent URL. By providing a short identifier, users can efficiently refer to a license without having to redundantly reproduce the full license. An easy first step for organizations adopt SPDX is to utilize the license list.
A number of companies have adopted the license list for internal use (e.g., TI, Wind River, MicroFocus, Siemens) and tools companies are utilizing as well (Black Duck, nexB, Protecode, etc.) OSI has adopted the SPDX short names and Debian has done so for their licenses (with the minor difference that they don’t like “.0” at the end of some license versions. Additionally, several OSS projects (e.g., U-Boot) are inserting SPDX short names in every file header and some very major projects and foundations are considering doing so.
Using SPDX
Only a handful of companies have, so far, publicly talked about their SPDX use. We are discovering a number of others who have had very little involvement with the working group that are experimenting with and using SPDX internally without our knowledge. In fact a large auto manufacturer is starting to require SPDX from suppliers and they’ve never been on a call or commented on a mailing list! Wind River is the most active early adopter and are delivering SPDX files to customers as their licensing documentation. TI and Alcatel-Lucent are also using internally. Samsung has put a process in place to manage their public licensing notices, all based on SPDX—another example of a company that went off and did something without any direct participation in the SPDX group. In the OSS world, the Yocto project has also adopted SPDX and started making SPDX files available to the users. OpenMama is talking about providing SPDX files.
