Difference between revisions of "LicenseExpressionFAQ"

Revision as of 22:10, 5 November 2014

Why was the License Terms Expression Language introduced in the SPDX 2.0 Specification

The SPDX 1.x Specification and earlier versions of the License List had a limited ability to represent more complex license situations typically found in practice. Examples of such complexity can be found at: http://wiki.spdx.org/view/FileNoticeExamples . Additionally, earlier versions of the SPDX License List required the addition of multiple yet similar license identifiers in order to capture combinations of versions, the “or later” license genre (i.e. GPL-2.0 and GPL-2.0+) and the most common exceptions (e.g., GPL-2.0+-with-autoconf-exception or GPL-3.0-with-autoconf-exception). The SPDX Legal working group identified more than 30 additional distinct exceptions. If one tried to accommodate the many different permutations of the different exceptions with the “or later” cases, the license list would become bloated and unwieldy. For additional historical background information you can reference: http://wiki.spdx.org/view/Legal_Team/License_Expression_Review_1. All in all, the introduction of the WITH and ‘+” operators, and the additional of the new license list exceptions section, we are able to represent more sets of license terms found in practice while simultaneously streamlining the SPDX License List.

Why do we need a License Expression Language when projects are available under a single license?

Typically an open source project will start out making their software available under a single open source license but as some projects evolve they may leverage code from other successful projects governed by different licenses. Consequentially many successful projects end up with a diverse collection of files that are available under different licenses. Often programs are built from a diverse collection of files that are available under a composite set of different license terms. The SPDX License Expression language provides a way for one to construct license expressions that more accurately represent the licensing terms are typically found in open source software source code. Also some projects may offer their software under a multi-license choice where a license expression provides a formal way to representing this.

Are there examples of different license expressions found in practice?

Yes, you can find examples here: http://wiki.spdx.org/view/FileNoticeExamples

In the SPDX 2.0 Specification why is GPL-2.0+ no longer a proper license identifier?

The license identifier “GPL-2.0+” will be depreciated in the updated version of the SPDX License List that accompanies the SPDX 2.0 specification release. The license identifier “GPL-2.0” (without the “+”) is still a valid identifier. After using SPDX in practice it was realized that there are several benefits to treating the “+” as an operator. The expression GPL-2.0+ is a valid expression in SPDX and has the same sematic meaning as the deprecated license identifier “GPL-2.0+”. The only difference is that the “+” is an operator that stands for “or a later version”. The “+” can now be used with other licenses in addition to the GPL and LGPL (e.g., EPL-1.0+). It reduces license list bloat, that is, we do not need to add every possible license with a “+” for all possible license cases one may encounter. This also applies to license exceptions. By introducing the “+” and “WITH” operators we can more simply and conveniently represent the myriad of special exceptions without needing to clutter the license list with all the different combinations that include the GPL and LGPL and later versions of the license. That is, we wanted to avoid adding the following to the license list: • GPL-2.0-with-autoconf-exception • GPL-2.0+-with-autoconf-exception • GPL-3.0-with-autoconf-exception • GPL-3.0+-with-autoconf-exception Now we just need to add autoconf-exception to the SPDX License List as opposed to the above four identifiers. If a new version of the GPL was released (e.g., GPL-4.0) only one license identifier needs to be added as opposed to one for all the potential special exceptions (e.g., autoconf, bison, classpath, …)