News

We could use your help

By In the News

These are critical areas where we could use help from the community right now:

  • Describing examples showing how to use  SPDX to document relationships. Work will be done on our wiki. Contact Kate Stewart
  • Contributors to help support the SPDX tools for tag:value format. Contact Gary O’Neall
  • Document how to certify you’re SPDX 2.1 Contact Kate Stewart
  • Document how to install the SPDX tools and set up a development environment as well. Contact Gary O’Neall

There is always lots to do, even if you dont have much time, so let us know if you would like to help on this or something else.

We have a new website!

By In the News

As you can see, the SPDX work group has launched a new website. Working with the Linux Foundation the group’s Outreach Team created the site with a new look and feel and sporting a new logo which aligns with the foundation’s other collaborative projects. The new site is designed to be very easy to navigate for experienced users and those just learning about SPDX as well. Large “How can we help?” buttons on the home page help one to navigate to the content most relevant to their needs.  The site retains all of the content of the previous site plus valuable new content including easy to read, HTML versions of the spec itself and How Tos for those wanted to get started using SPDX. This is the first major overhaul to the site since it was launched five years ago and represents a great step forward in making the SPDX standard accessible.

Version 2.2 of the License List Released

By In the News

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.

Supply Chain Mini Summit at LinuxCon Europe on 8 October

By In the News

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

Our own Jilayne Lovejoy will be speaking at LinuxCon Europe

By In the 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.

SPDX Tool bake off and Talks at LinuxCon 2015 North America

By In the News

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

This is a milestone day for SPDX, the release of Version 2.0. This release is a great step forward and greatly expands the utility and applicability of the spec

By In the News

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!

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.