Using the SPDX License List for Tagging and Linking

The Software Package Data Exchange® (SPDX™) specification is a standard format for communicating the components, licenses and copyrights associated with a software package. Their website has a lot of detailed information about the specs, format and tools itself.

But in this post I’d like to highlight not the full standard and how to apply it to your software package(s) (that is reveiwing code and writing/creating the RDF/XML files), but only a little detail of it which I think is a great resource for those who write code them-self. 

SPDX License List

In creating the standard, SPDX.org has created a License List. That is a website (and a git source-code repository) that is listing the many standard software licenses you normally run across over. All in one place:

http://spdx.org/licenses/

This list is great for canonicalization. Because not only is each license listed with its full name, license text and alternative places where you can retrieve it, but also with a so called Identifier or Short Identifier. That identifier is a very short string that represents a license, I have created a table with some common ones because this explains it well:

Identifier	Full name
Apache-2.0	Apache License 2.0
BSD-2-Clause	BSD 2-clause “Simplified” License
BSD-3-Clause	BSD 3-clause “New” or “Revised” License
BSD-4-Clause	BSD 4-clause “Original” or “Old” License
GPL-2.0	GNU General Public License v2.0 only
GPL-2.0+	GNU General Public License v2.0 or later
GPL-3.0	GNU General Public License v3.0 only
GPL-3.0+	GNU General Public License v3.0 or later
LGPL-2.1	GNU Lesser General Public License v2.1 only
LGPL-2.1+	GNU Lesser General Public License v2.1 or later
LGPL-3.0	GNU Lesser General Public License v3.0 only
LGPL-3.0+	GNU Lesser General Public License v3.0 or later
MIT	MIT License

These identifiers are just too handy to not to be used within source-code documentation, e.g. within the docblock tags after the human-readable copyright/license header on top of a file as illustrated the following screenshot:

This is an exemplary file under GNU General Public License (the FSFs’ website has an example of a license header so I just adopted it to create the image, this naturally works with any kind of standard license).

Those docblock comments are normally both human and machine readable, so this does benefit a review of your software and can improve acceptance, it is more clear what is meant. If you use some other texts for that @license tag, it’s often just GPL or BSD and then you do not know which license exactly etc. pp..

So what I’d like to highlight here is that those license identifiers introduced by SPDX can be nicely used to tag your files with a license while being precise and concise.

A Link to the License

And this does not stop with the SPDX License Identifier. Each identifier can be expanded to a URI that has the license text and detailed information. That License URI can be built in a very simple fashion:

That means the URI alone already transports the identifier. Added this to the docblock tagging outlined above, it also explains to which “identifier registry” it adheres to. An exemplary usage could look like or similar to the following screenshot:

Summary

Even the overall SPDX Standard is quite big, it has some tools in its chest that are useable straight away for a programmers work. By making use of the SPDX License Identifier and the SPDX License URI a close to perfect description of a source-files software license can be given as long as it is under a single and a standard license that is part of the list which is pretty complete. The organization behind SPDX takes care to garden that list and improve/extend it over time.

Edit: As Jilayne Lovejoy pointed out in comments: “if anyone finds that a commonly used license or a license used by a prominent project is not on the SPDX License List, one may suggest adding a license”

Please take note that SPDX is about identifying and documenting licenses, especially for software packages. It does not give any suggestion of whether the one or other license is “better” (as well as it does not say which license is compatible with each other). So do not misuse the list to “just pick one”. More importantly, picking a license is a decision you still need to do on your very own as a software developer. There are many opinions, if you’re looking for details, I can highly suggest a very thoughtful essay by David A. Wheeler that gives a good insight (and good links, too) about software licensing: Make Your Open Source Software GPL-Compatible. Or Else..

---

Read On: The SPDX License List: The Gateway Drug to Full SPDX Adoption? (by Jilayne Lovejoy; 23 Mar 2012); About a year ago I was blogging SPDX 1.0 is Now Available! (24 Aug 2011)

---

Image Effect: “Zerrissenes Foto” by Gimp Werkstatt