The SPDX License List is just one part of a larger effort to make reporting open source software licensing information more efficient and thus ease license compliance. As an active member of the SPDX legal work group, it began as a simple matter of raising my hand that I took on the task of 'keeper of the list.' Or so it seemed.
When I began working at OpenLogic, my first task was to read all the most commonly used open source licenses, analyze the license requirements, and help create the framework which would become the OLEX Open Source License Compliance module to our scanner
. This necessarily brought up some tangential questions. Do we have this license already in our database and, if so, is it truly the same license? At what point does it become a different license? What is considered part of the license text and what isn't? What should the license be called? How should the formatting look when the license is displayed on the page? Later, my role would evolve to include using our product to perform open source audit services for our customers. There is nothing like drinking your own Kool-Aid to encourage improvements at the macro and microscopic level.
Now, let's just be clear; I am not a developer. I managed to teach myself basic html and css to round out my interest in graphic design and support a side business building static websites for the small businesses of friends and relatives in a previous life. This means I have just enough knowledge of website coding to make me dangerous. Combined with a strong opinion about the way things should look and a meticulous eye for detail (some people refer to this as perfectionism, but one look at my garage would disqualify me from that classification) means I have spent more time than I wish to admit thinking about things like whether to use bullets or numbering as the list-style for the clauses of the BSD license and making up "rules" to ensure that all the red-headed step-children that are open source licenses are treated equally and consistently in order to make our tool reliable, predictable, and practical. So, it is really quite appropriate that I fell into the role of the keeper of the SPDX License List
What is the SPDX License List?
First you may be wondering, what is SPDX? The Software Package Data Exchange® (SPDX™) specification is a standard format for communicating the components, licenses, and copyrights associated with a software package
. The idea began as a way to reduce redundant work across the software supply chain. By creating a common format to report data about software licenses and copyrights, license compliance is then also facilitated. Software, systems, and tool vendors; foundations; open source services companies; and systems integrators work side by side to develop the specification as a collaborative effort under the SPDX work group, which is hosted by the Linux Foundation. The first version of the specification was released in August of last year
, with version 2.0 in the works as you read this.
In the early days of the specification development process, it became apparent that a way to refer to common open source licenses by a short reference would be very helpful and reduce the amount of information contained in an SPDX file. Thus, the SPDX License List was born. The license list contains the full name of the license; a standard identifier; a url to the official version of the license and to the Open Source Initiative (OSI) website if the license is OSI approved; the license text itself; and any official license header as suggested in the license. Then there is the need for some kind of matching guidelines to make sure that when one SPDX user identifies a license as "Foo,” it is indeed the same license as what someone else identifies as “Foo” and the same license as what is listed on the SPDX License List.
Of course this is not the first list of its kind or endeavour to reach such goals. Increasing feedback and participation in the SPDX legal work group indicates that many others either have their own such similar effort or would appreciate being able to adopt a list already created. Because the thing is, creating such a list and its attendant guidelines is not nearly as easy as it sounds. Yet, wouldn't it be nice if we got to a point that when someone says "BSD 3-clause," we all - the collective and sometimes cacophonous world of open source software - would know exactly what that meant?
What's in a name?
That which we call a license by any other name may smell as sweet, but how does one decide what to call it to begin with? Let's take the BSD License for example. If a file states, "This file is licensed under the BSD License," do you really know which one? There are three different BSD licenses: the original 4-clause license that included the advertising clause; the "revised" 3-clause license, which is probably most used today; and the simplified 2-clause version. Then there is the fact that the University of California rescinded the problematic advertising clause
, thus effectively turning the 4-clause license into the 3-clause version for any UC Berkeley copyrighted code. FreeBSD
both use a 2-clause version, but with additional text included at the end or beginning, respectively. And while there may be some who say, "who cares?" the difference can be material, and moreover, where accuracy is the goal, such differences cannot be ignored. These are some of the questions that need to be confronted and decisions that need be made.
What better group to work on such a task than a collaborative collection of players from across the open source software space? In the same way that Linus Torvalds' harnessed the collective intelligence of many developers to create Linux, so too can we for creating a way of referring to licenses that addresses all the detailed considerations. The SPDX License List, due to its inherent nature of filling the needs of many, could just prove to be the gateway drug to overall adoption of the full SPDX specification.
If you have yet to, get involved! Join one of the SPDX work groups and mailing lists (general, technical, business, or legal) here: http://spdx.org/wiki/spdxLet me take this opportunity to give a huge thanks to the tireless participants of the SPDX legal work group (you know who you are!) - while there is much more work to do, we have come a long way in a short time. Cheers!Subscribe to The Enterprise Open Source Blog via emailView Jilayne Lovejoy's profile
This work is licensed under a Creative Commons Attribution 3.0 Unported License