In the News

Open Collaboration Changes Everything…including SPDX

By In the News

Submitted by Phil Odence on April 1st, 2014

The theme of the Linux Collaboration Summit was: Open collaboration changes everything. (You would know this if you saw the back of my new hoodie.) It will sound sappy, but I was never prouder to be associated with SPDX as I was during the cross function legal discussion on Friday morning, one that can only be characterized as collaboration at its best.

We’ll publish the output of the session, but in essence we were formulating the new license expression language. Mark Gisi, the standard-bearer for the idea, led the discussion and did a terrific job facilitating, and left plenty of room for inputs from virtually every one of the twelve or fifteen folks in the room.

As is often the case, this one seemed completely straight-forward to me at the outset. And, in fact, we quickly got to agreement on making “+” an operator rather than a part of license names. When we got onto handling exceptions, however, we started identifying manifold dependencies and implications, and it became clear that tradeoffs would be required.

To inform our decision-making we really needed every perspective represented in the room: Lawyers, developers, practitioners, theorists, tool developers, SPDX users, etc. The discussion was spirited and there was occasional talking over one another, but all were highly respectful of others positions. I myself was, at one point, completely convinced of the “right” approach and advocated it passionately, only to later pulled a 180 as I better understood all the implications. And, I’m confident was not the only one who found themselves digging out of having been dug in.

With about 25 minutes to go, I bit my tongue when it was my turn to talk and Jilayne elbowed me out of the way to summarize where we were. It was obvious to me at that point, that we would have consensus in a number of important areas, though clearly not complete consensus on the complete answer. And then somehow, magically, a minute and a half before lunch, the approach about which we’d been circling came into sharp focus for everyone in the room and we agreed. We took a pole to verify, and there it was, we had complete consensus on this very gnarly issue. I lead a chorus of Kumbaya as we exited the room. OK, not really.

Lessons learned: 1. We rock. 2. Periodic face-to-face meetings are really good. 3. We rock.

Ring in the new

By In the News

If I’d gotten to this a few days ago, I might be looking back on an eventful year, but here we are in 2014 looking forward. And, actually, it turns out we did some good reflecting in the blog I posted in November. If that wasn’t enough, please check out the International Free and Open Source Software Law Review (IFOSSLR) publication of an article that Jilayne, Scott and I wrote on the status of SPDX.

In the first half of the 2014, we should expect to see a continuing ramp of company adoption as last year’s internal experimentation evolves into a real vehicle for communication between supply chain partners. I want to quantify this by following up on the industry survey we did last Spring, but my sense is that the spec and supporting materials are to the point that users are able to run with it without a lot of questions. Thus, we are continuing to uncover companies “doing stuff” with SPDX.

The other thing I expect to see in the first half of the year is the first wave of open source projects beginning to incorporate SPDX into their work. We’ve seen U-Boot incorporate SPDX short-name tags in every file. We will see other projects doing the same and facilitating license communication in other ways.

The second half of the year should be about the 2.0 release—actually this work will consume the technical team for the first half of the year, enabling a release in the second half.  The dot 1, and 2 release have both enhanced our initial stab, incorporating feedback from users and tool makers, to make SPDX more usable. Version 2.0 will be a fairly major change taking us from the paradigm of self-standing SPDX docs to systems of related SPDX docs, enabling definitions of hierarchy and other relationships between pieces of software.

Another sign of  progress with SPDX is recognition by the Object Management Group (OMG) standards consortium. The OMG is now looking at other aspects of standards for managing open source licensing across supply chains and, as a starting point, recognizes SPDX as a key element of addressing this issue (and a well-crafted wheel they have no interest in  re-inventing). My prediction is that the initial focus for OMG will be on a component naming standard. Think GAV (Group, Artifact, Version) from Maven, but much broader. We will want to stay close to this work as it greatly will aid component identification in SPDX docs.

I’m amazed by what we have accomplished in the last year as a 100% volunteer organization. Congrats and thanks to all who have contributed in any way. And, for anyone who has been considering getting more involved, it’s not too late to make that your New Year’s resolution. Just a few additional hands spending a couple of hours a week could make a big difference in our velocity across all teams.  Please drop me a note if you’d like to discuss how to get yourself or colleagues more involved. ( Happy New Year.

SPDX…how are we doing?

By In the News

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.


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.

SPDX Releases version 1.2 of the Specification

By In the News

The Linux Foundation’s SPDX Workgroup Releases New Version of Software Package Data Exchange Standard By linuxfoundationblank – October 22, 2013 – 12:34am

 Version 1.2 improves interoperability and is being adopted by U-Boot project

EDINBURGH – LinuxCon and CloudOpen – October 22, 2013 – The SPDX® workgroup, hosted by The Linux Foundation, today announced the release of version 1.2 of its Software Package Data Exchange (SPDX®) standard, which includes new features and is being adopted by U-Boot, a popular open source boot loader for embedded devices.

The new release addresses issues identified during interoperability testing. The SPDX workgroup held a “bake off,” or interoperability testing session, during the 2013 Linux Foundation Collaboration Summit in April, comparing the output of several tools as well as some manually generated SPDX documents. The extensive analysis uncovered opportunities for further clarity in the spec. SPDX Version 1.2 and its updated guidelines address these opportunities and ensure more consistency in SPDX documents.

“The interoperability testing we did at the Collaboration Summit was very valuable in checking the spec in use by a diverse group of users,” said SPDX Technical Team Lead, Kate Stewart, one of the founders of SPDX. “Version 1.2 is a great step forward in achieving consistency across SPDX tools, which is key to adoption.”

The SPDX workgroup is also announcing that U-Boot, a popular open source boot loader for embedded devices, is using SPDX license names as its standard for specifying licensing in files. This kind of adoption by open source projects greatly simplifies the creation of SPDX documents and reduces cost of compliance across the software supply chain.

“SPDX license identifiers enable us to unambiguously capture all license information in a single line,” says U-Boot creator Wolfgang Denk. “This avoids a variety of problems for us including bloated source code, breakdown of automated processing due to variations in the way licenses are specified, and difficulty in generating License Clearing Reports. At the same time this makes U-Boot easier to maintain and for organizations using SPDX to adopt.”

New features in SPDX 1.2 include:

  • A field to specify license list version and one to describe file dependencies
  • More flexibility in locally naming non-standard licenses
  • Clarity with respect to case sensitivity for existing fields
  • Fields to document notices, project homepage and author credits
  • The ability to identify and map standard license headers

SPDX version 2.0 is expected in 2014 and will support hierarchy.

“With its latest release, the SPDX workgroup continues to improve the process for license compliance across multiple industries where Linux and open source software are dominant,” said Jim Zemlin, executive director at The Linux Foundation. “Investments in this area are important for increasing Linux and open source adoption, and we are happy to see these community contributions to SPDX.”

SPDX is developed with participation by a wide range of industry and open source community heavyweights, including: Alcatel-Lucent, Antelink, Black Duck Software, Cisco, HP, Linaro, Micro Focus, nexB, OpenLogic, Palamida, Protecode, Source Auditor, Texas Instruments, University of Nebraska Omaha, University of Victoria, and Wind River.

Currently the workgroup maintains a set of tools that complement community tools from University of Nebraska Omaha and commercial tools from Black Duck and Wind River. See: To learn more about SPDX and participate, please visit:

About The Linux Foundation

The Linux Foundation is a nonprofit consortium dedicated to fostering the growth of Linux and collaborative software development. Founded in 2000, the organization sponsors the work of Linux creator Linus Torvalds and promotes, protects and advances the Linux operating system and collaborative software development by marshaling the resources of its members and the open source community. The Linux Foundation provides a neutral forum for collaboration and education by hosting Collaborative Projects, Linux conferences, including LinuxCon, and generating original research and content that advances the understanding of Linux and collaborative software development. More information can be found at


Trademarks: The Linux Foundation, Linux Standard Base, MeeGo, OpenDaylight, Tizen and Yocto Project are trademarks of The Linux Foundation. OpenBEL is a trademark of OpenBEL Consortium. Linux is a trademark of Linus Torvalds