Difference between revisions of "Legal Team/License Expression Review 1"

Revision as of 11:59, 14 November 2013

Overview

The SPDX Legal group will be holding a special break out session to review a number of software examples where the SPDX licensing language syntax (i.e., license list + AND/OR operators) may not be sufficient to represent the licensing terms of the software generally. For instance the group will be looking at the various kinds of special exception terms, the use of the ‘+’ in license names and programs derived from multiple source and library files, where each is potentially under a different license. The group will report back to the Legal and Tech working groups with its findings.

The Problem

SPDX data creators utilize an informally defined mechanism to represent the licensing terms of various different copyrightable software items such as source files, programs, libraries, packages, images, fonts, documentation and so forth. The current mechanism informally consists of:

1. a license list with standard short names (e.g., constants such as GPL-2.0, BSD-2-Clause )
2. a mechanism to define custom licenses - i,e., licenses not found on the standard license list (e.g., LicenseRef-23)
3. a simple collection of boolean expression operators (e.g., AND and OR). Potential others may be needed (e.g., WITH-EXCEPTION, +)
4. Use of parenthesis to establish order of precedence - e.g., (MIT AND (GPL-2.0 OR BSD-2-Clause))

Some of these components are define in the SPDX spec (e.g. operators AND and OR, LicenseRefs) while others are maintained in a separate license list (e.g., constants LGPL-2.0, BSD-2-Clause, GPL-2.0+). What is missing is:

• A formal description of a well thought out license expression language with more rigorous consideration and presentation of how the different components (e.g., operators and operands) can be combined to represent the licensing terms of most copyrightable software items (e.g., programs, images, ...). For example, the creation of a single document that presents a holistic overview of the licensing expression mechanism with many insightful examples of source files, libraries and packages.
• A process by which additions, deletions and modifications can be made to the a formal definition over time.
• A process to test (validate) the current (and future) constructs of a license expression language to ensure they are sufficiently expressive to represent most software licensing situations.

Note: The existing informal mechanism currently used largely evolved based on intuition of various anecdotal situations. The objective here is to pursue a more formal and disciplined analysis of what a an effectively expressive licensing mechanism might include.

Observations/Considerations (with Examples)

• what is the GPL-2.0-only issue - Bradley Kuhn's has raised this issue
• Provide a formal definition of what exactly a license on the license list is. For example, does GPL-2.0+ really represent a license constant or is it more representative of as multi license choice such as: GPL-2.0 OR GPL-3.0? Should we allow the + to be applied to any license? For example, EPL-1.0+?
• Although we do want to resist removing licenses from the license list, if may be required under certain circumstances to get to a better place in the medium to long run. The inclusion of the LicenseListVersion field in the SPDX spec 1.2 does allow this to be done in a relatively clean way.

Requirement (Proposal/Draft)

Here we present a list of potential requirements for a licensing expression language should support. We include requirements that are potentially already support in the current informal mechanism for the sake of completeness. Some potential requirements include:

• Define the concept of a license expression operator (e.g., OR and AND)
• Define the concept of a license expression operand as either a single license constant (e.g., LGPL-2.1, LicenseRef-23) or cont
• Define the notion of a license expression. For example, a license expression can consist of a single operand license constant or an expression constructed by applying one or more operators
• Effectively (and potentially elegantly) represent the myriad of different special exception cases (e.g., GPL-2.0+ with Bison Exception, )
• Disjunctive license expression support - ability to define a multiple license choices (currently supported by OR operator)
• Conjunctive License support - ability to o define a situation where license choices (currently supported by OR operator)
• Provide an effective way to allow one to describe custom licenses (e.g., LicenseRef approach).
• Supporting the licensing of images and fonts. For example, does the license list include licenses to cover non source items found in software.
• Need to give the formal mechanism a formal name (e.g. SPDX Licensing Expression Language (SLEL)) so that it has a more formal existence and standing.

Notes/Comments