I’m not complaining, but any of us involved in SPDX have learned how long and time-consuming standards work can be. Luckily we’ve got a great team and the work does have its rewards. We’ll all pop the corks when Version 1 is finalized, but there’s reason for a little celebration now, as well: The Open Source Initiative (OSI) has just adopted the SPDX short form license names, yippee!
Of course the exchange standard is our focus, but an underrated subproject has been the license list, and this move by OSI truly endorses the value of that asset. The license list is pretty simple, just what it says: A list of licenses. The value is twofold: A standard list of short names makes it easy to reference a particular license and the pointers to perpetual URLs for the license text ensure that there is no ambiguity in the reference. So, a lawyer reviewing the use of code under CPL-1.0 who has previously reviewed the text at http://www.spdx.org/licenses/CPL-1.0#licenseText, knows exactly what legal language governs the use of the software in question.
This opens up the opportunity for compacting license language in code without introducing the ambiguity. It all may sound trivial, but addresses the classic problem that happened when the Free Software Foundation changed http://www.gnu.org/licenses/gpl.html from pointing to version 2.0 to version 3.0 of the license. So code that referenced the URL with the intent of being licensed under 2.0 was put into an ambiguous license state.
Of course for all this to be valuable, the list had to be adopted. The OSI is the defacto standard for approving open source licenses. They have been involved from the outset in SPDX and there is no group’s endorsement that would represent a greater vote of confidence. According to OSI Director, Karl Fogel:
It's best if we all use the same names when talking about the same things, and SPDX did the hard work of coming up with a good set of names. OSI should help reinforce that set -- it makes things easier for everyone who has to work with open source licenses (including us).
It’s also worth noting that we built the list on the good work of and with welcome support from Debian and Fedora projects and the team has worked to synch with their existing lists. Black Duck (my employer) will also standardize on the list and OpenLogic and Protecode have said that their products will support SPDX, as well, so we are establishing some critical mass.
Here’s to us and thanks to the OSI, Karl, and Mark Radcliffe for your support.



congrats
In the context of Eclipse and its installer / update solution, I have been looking forward to the completion of this effort (http://bugs.eclipse.org/255075 or http://bugs.eclipse.org/324219). Congrats on this milestone.
Now some pragmatic questions, where is the list of short name? Will the OSI expose its own list (meaning on an osi server)? Has it already been discussed whether the simple mention of this reference will suffice to replace the need for having the complete license text in the software artefact.
Pascal Rapicault
Reply
Here's the list: http://www.spdx.org/licenses/
Here's the OSI list: http://opensource.org/licenses/alphabetical
I think that the SPDX list could become the canonical reference and used as you suggest. There have been some inforamal discussions with the Software Freedom Law Center on this.
CC licenses
A few comments on the Creative Commons licenses:
I agree that it's sensible to list all the CC licenses here. However, it needs to be made clear in some way that the ND and NC variants are not open source, perhaps by marking them in the list with an asterisk.
CC0 is missing, as is Public Domain itself.
The jurisdictional variants are also missing. Keeping up with them all is probably too big an undertaking, but a blanket statement to the effect that the South African variant of CC-BY-2.5 is tagged CC-BY-2.5-ZA, using ISO 3166 codes (as CC itself does), would be reasonable. Note that Scotland is a separate jurisdiction but not an ISO 3166 country, so it needs its own subtag such as CC-BY-SA-2.5-SCO.
John Cowan