By Mark Gisi
There is only one criterion that determines whether a piece of software is open source software (OSS) - the license from which you receive the software under. If you are granted rights under an open source license such as the BSD, Apache or GPL, it is open source software.
Although the open source movement has other core pillars, which include the power of the community development model, peer recognition, and community review (the many eyeballs affect), there is no movement without the license.
Open source developers do not ask for much for the use of their software. What little they do request is described by a few conditional obligations listed in the license. In exchange for satisfying those obligations, the user is granted certain rights with respect to copying, modifying and/or redistributing the developer’s creation. Obligations may include a requirement to pass along the source code, provide certain notifications (e.g., modification notices) or just simply provide attribution. The task of satisfying the respective license obligations is often referred to as license compliance.
It is not uncommon for embedded software developers to use a subset of files of a given OSS package where each file could potentially have its own distinctive license terms. In order to legitimately redistribute software that includes OSS, one must understand all the license terms of the OSS files from which a program is derived. The effort required is a function of a number of open source files one integrates into their work, which increases in direct proportion to the total number of files.
If a program is derived from just a dozen or so files, determining all the licensing terms often becomes a manageable task. If one leverages the benefits of 100s or potentially 1000s of files, then the task of wading through those source files to determine the license terms can become very costly and is error prone.
To facilitate the license compliance task, the Linux Foundation sponsored the Software Package Exchange (SPDX) working group to produce a standard format for recording all the licensing information found in a package and storing it in a single file or repository. This alleviates the need of rummaging through 1000s, if not 10,000s of source files of an OSS package to determine license terms for a selected subset of files. This also leads to wider more rapid adoption of a given OSS project.
By having a single repository of license information covering all the components found within a OSS package, SPDX 1.0 makes it easier, less error prone and much more cost effective to determine licensing for a given component whether it is a single source file, a library or an entire application. The ultimate goal is to enable the user of any component contained within a package (file, library or program) to be able to honor the license wishes of the respective copyright holders.
The Linux Foundation released the first version of the specification, SPDX 1.0, back in August of 2011. Since then, we have performed various experiments which included creating SPDX files for a number of popular open source packages and we are happy to report that it delivers on much of the promised utility as describe in the 1.0 specification. Although it is the first release, in its current form, SPDX 1.0 offers significant value to the open source community and its users. I encourage you to check it out at www.spdx.org and get involved. Drop me a note/comment and share your thoughts. I would be happy to share mine. That is, after all, the way great things are created within the open source community.
For additional information from Wind River, visit us on Facebook.
Subscribe
Comments