Interesting discussion - we happen to be discussing the license expressions in the tech call for a different use case. In those discussions we discussed whether the package concluded license was for the target executable or for all files (including documentation).
Of course, if there are more than one target executable with different licenses (as in Philippe's example), the concluded package license could get even more complex. Another approach to express the documentation license is to use the relationship property for the documentation files themselves as the documentation files relate to the package. There is a relationship defined for documentation of and the license for the documentation could be recorded in the documentation files. A topic worthy of a discussion. Gary > -----Original Message----- > From: spdx-tech-boun...@lists.spdx.org [mailto:spdx-tech- > boun...@lists.spdx.org] On Behalf Of Philippe Ombredanne > Sent: Wednesday, May 11, 2016 3:13 PM > To: Wheeler, David A > Cc: spdx-tech@lists.spdx.org > Subject: Re: Proposal: Add "(IF <Condition> THEN <License-Expression> > [ELSE <License-Expression>])" to License expressions > > On Wed, May 11, 2016 at 11:56 PM, Wheeler, David A <dwhee...@ida.org> > wrote: > > In the Linux Foundation CII “best practices” badge effort I’m > noticing > > an interesting problem. Some projects have *different* license > > situations for their source code and documentation, but there’s no > > simple way to express that using SPDX License expressions. > > Furthermore, there is common pattern to have CLI tools under the GPL, a > library under the LGPL (and somtimes examples in the public domain or > BSD-licensed. ) > > > Examples of projects where the license isn’t easily expressed with > > SPDX expressions are: > > > > https://bestpractices.coreinfrastructure.org/projects/1 > > > > https://bestpractices.coreinfrastructure.org/projects/137 > > > > > > > > I propose adding a new construct: > > > > "(IF <Condition> THEN <License-Expression> [ELSE > > <License-Expression>])" to License expressions. > > > > For starters, <Condition> can be: > > > > DOCUMENTATION = True if & only if (iff) documentation > > > > SOURCE = True if & only if (iff) source code > > > > > > > > So “Source code under MIT, everything else under CC-BY-3.0 or later” > > becomes this license expression: > > > > "(IF SOURCE THEN MIT ELSE CC-BY-3.0+)". > > > > > > > > If there’s no “else” and the condition is false, it’d be interpreted > > as the empty set of rights (“no rights”), so these would mean the > same thing: > > > > "MIT OR (IF DOCUMENTATION THEN CC-BY-3.0+)" > > > > "(IF DOCUMENTATION THEN (MIT OR CC-BY-3.0+) ELSE MIT)" > > > > I imagine Condition could be beefed up to allow AND/OR/NOT, file > > matching, jurisdiction matching, and comparisons with the current > date > > (for timed releases in the future). But that’s for a later > discussion. > > Could this be simplified? > > I can see two use cases: > 1. at the file or directory level, this is unlikely needed: just > provide the expression that applies there only e.g. to a doc or source > directory in an SPDX doc or a simple expression. > > 2. for a top level package, would a notion of "licensing scope" be > simpler than a full conditional construct? > e.g. something like: > > scope:doc GFDL and MIT > scope:tools GPL-2.0+ > scope:library LGPL-2.1+ > > And if no scope is defined it defaults to global and is overridden if a > scope is defined? > So IMHO this would not be a single expression but an array of > expressions. > And we might not need a full if then else to express this. > -- > Cordially > Philippe Ombredanne > _______________________________________________ > Spdx-tech mailing list > Spdx-tech@lists.spdx.org > https://lists.spdx.org/mailman/listinfo/spdx-tech _______________________________________________ Spdx-tech mailing list Spdx-tech@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-tech
