News

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!

Our own Jilayne Lovejoy, Co-Chair for the legal team, gave a talk at FOSSDEM earlier this year on SPDX. Her talk was entitled “Debunking the Myths and Misunderstandings”. Take a look, you might learn something new!

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.

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.

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: http://spdx.org/tools. To learn more about SPDX and participate, please visit: http://spdx.org

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 www.linuxfoundation.org.

###

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