Hi Philippe, Thanks for the context and proposal.
I now understand better where the comma proposal is coming from. The proposal to add commas is reasonable and helps with the Debian community. I am still concerned, however, that having 2 ways to express the same semantics is going to be confusing to those outside the Debian community. In many computer languages, commas usually indicate a set operation rather than AND. If I didn't know the background, I would expect an entirely different semantic if I saw commas in the list (especially if AND was also an operator). In either case, I suggest we include the tech group in the discussion as it does impact the spec and the tools. Is this something we can add to upcoming the joint tech/legal call? Gary > -----Original Message----- > From: spdx-legal-boun...@lists.spdx.org [mailto:spdx-legal- > boun...@lists.spdx.org] On Behalf Of Philippe Ombredanne > Sent: Friday, May 15, 2015 8:04 AM > To: SPDX-legal > Subject: The meaning of "AND" in license expressions [was:Re: call > tomorrow, agenda] > > Here is my understanding of how the "AND" thread started: > > Mark brought up a concern about the meaning of AND. > He felt this could be misleading to have to say AND in a top level > package without details about what each license applies to which file > exactly. And Debian uses a comma to provide a list of licenses in these > cases rather than an AND. > And he pointed out that using AND for something like "GPL 2.0 AND > Proprietary-License" could be puzzling at best. > (Mark please correct me if I am wrong: this is just hearsay.) > > I agree with Sam E., Gary O., Alan T. and Jilayne L.: the current spec > is correct and there are ways to express things precisely using > relationships and other measn. (Thanks Jilayne for your excellent > details). > > I also agree with Mark G. and Dennis C.: some expressions look > surprising and feel contradictory, such as GPL and Proprietary. > > I think both points can be reconciled. > > My take: > On the substance: > ========= > * AND means that all licenses apply. Simple and clear. > In the context of Debian, the comma means exactly the same thing: all > licenses apply. > > * AND can be used at a granular per file or directory level or at a > coarse aggregated level. > When aggregated it identifies all the licenses used, say a single SPDX > document with no details of where each licenses applies. > While not precise and detailed to the tastes of many, this can be an > accurate yet coarse representation of a package licensing. > If I am not provided with more details of what applies to what it does > not imply that all licenses apply to everything. > It just means that all these licenses apply in aggregate at some level. > > Having more details documented would be preferred but this is not a > mandate. > This is a perfectly valid SPDX usage and much better than no SPDX at > all. > > > On the form: > ========= > Say I receive an SPDX doc for a fictitious AirStream RT 12.1 package > that says: > Commercial and GPL-2.0 > The package contains a GPL-licensed kernel module and a commercially- > licensed set of user space utilities. > But AirStream did not provide details in additional SPDX elements or > docs. > This license expression is factually correct but it may be surprising > if you were not provided with more details. > > Surprising is not good: we can do better! > > > My suggestion: > ========= > 1. Do not add anything to the semantics of the license expressions: > AFAIK anything can be documented with SPDX (eventually with > relationships) to add more details if an SPDX author wants to do so. > We can add notes or commentary alright in the spec or outside the spec > to make it easier to understand alright. > > 2. Add the comma as an alternative representation for AND where "AND" > and "," are exactly equivalent and can be used interchangeably. > > The benefit is that AirStream may prefer to provide a single top-level > SPDX doc with no further file details with: > Commercial, GPL-2.0 > > With this alternative form the surprise goes away. Debian does not have > to change its ways either. > And you could even write things like this as a valid expression and > good plain English: > > This package contains code under various licenses: > Commercial, LGPL-2.1, GPL-2.0+, MPL-2.0 and MIT > > This is formally equivalent to this other expression which can be > surprising to some: > LGPL-2.1, Commercial and GPL-2.0+, MPL-2.0 and MIT > > -- > Cordially > Philippe Ombredanne > _______________________________________________ > Spdx-legal mailing list > Spdx-legal@lists.spdx.org > https://lists.spdx.org/mailman/listinfo/spdx-legal _______________________________________________ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal