I do have a use case where being able to represent partial conclusions would be useful.
As a provider of audit services, I am often confronted with unclear documentation on licensing where there is some information present, but not enough documentation to confirm a specific license expression. In a majority of the situations, I can determine the specifics through related websites, contacting the author, or other methods. In some situations, however, determining the precise license entails a very high effort where determining the specifics will not change the actionable results of the audit. For example, if someone has a policy to not include any GPL in their shipping products and I find a GPL-Only or possibly a GPL+ license, I don't really need to determine which applies to notify the reader of the audit report there is a policy violation. Today, I can represent the situation in SPDX with a License-Ref containing the exact text and a license comment describing the ambiguity. It would, however, be much more convenient to the consumer of the SPDX document if I could express at a high level what the range of possible interpretations are. To use the GPL example, being able to describe 'GPL-Only OR-MAYBE GPL+' would make it clear to the reader, there is definitely something GPL here and, depending on the policy, this may not be allowed regardless of how the license version is concluded. Tools which look for license conflicts could also use this information to automatically flag issues (e.g. https://github.com/librariesio/license-compatibility). Is this worth changing the spec to cover this case? Possibly. In my audit scenario, all SPDX documents are accompanied by a written report which clearly expresses any issues. If there is any downstream consumers (human or tools) of the audit results which just use the SPDX document without the associated report, I would argue we should extend the spec to cover this case. If everyone who receives the SPDX document also read the associated report, there is not as much value. I am also quite sensitive to not making the spec any more complex. In gathering feedback on SPDX documents, the number one issue I've heard is the spec is just "too complex". If we want to pursue a solution to the above use case, I am in favor of the "OR-MAYBE" proposal (see https://lists.spdx.org/pipermail/spdx-legal/2017-September/002233.html for Trevor's original proposal). My only concern is that it could also be used in a declared license scenario where "OR-MAYBE" really shouldn't be used. IMHO, if you're the copyright owner declaring a license you should not be able to use a partial conclusion in your declaration. Perhaps we could make it illegal to use this operator for declared licenses. David - I'm curious if the "OR-MAYBE" proposal solves the issue you are raising as well. Gary > -----Original Message----- > From: spdx-legal-boun...@lists.spdx.org [mailto:spdx-legal- > boun...@lists.spdx.org] On Behalf Of W. Trevor King > Sent: Saturday, November 25, 2017 10:56 PM > To: Wheeler, David A <dwhee...@ida.org> > Cc: SPDX-legal <spdx-legal@lists.spdx.org> > Subject: Keep partial conclusions out of license expressions (was: update on > only/or later etc.) > > On Fri, Nov 24, 2017 at 09:33:23PM +0000, Wheeler, David A wrote: > > Many package managers use SPDX license expressions to indicate the > > package license. E.g., NPM does: > > https://docs.npmjs.com/files/package.json > > by using the "license:" field - which is *NOT* a SPDX license file. > > According to <http://modulecounts.com/>, *just* the NPM ecosystem has > > 550,951 modules as of Nov 24, with 535 new packages a day on average. > > I don't know what percentage of modules have a "license:" > > entry (is someone willing to find out?) - but for discussion, I'll > > guess it's at *least* 10%.. That would mean that there are 55,095 NPM > > packages that use SDPX license expressions. > > But how many of those authors would use a partial-conclusion syntax if it > existed? > > I expect most npm package authors are also core developers for the packaged > software and know the package license. They won't need to be able to express > a partial conclusion. > > Distibution-specific package managers, on the other hand, seem more likely to > be third parties who are not directly related to the development team. They are > more likely to need to express partial conclusions. Project developers who > inherit an ambiguously-licensed package from some previous authors would be > in the same boat. In those cases, ideally they'd track down the copyright holders > and get to the bottom of the licensing. In the absence of that, they'd want > some way to express their partial conclusions. > > I'm fine with the SPDX deciding that structured partial conclusions are out of > scope, and leaving it to packaging systems, etc. to define their own (e.g. an > array of SPDX license expressions with confidence scores). Folks who extract > license claims from those packages would have to write per-packaging-system > tooling to convert the partial conclusion into their own format, but that's ok. > And if it turns out to be a problem, anyone can try to talk folks into whatever > partial-conclusion model they prefer. > > I'm also fine with the SPDX defining it's own partial-conclusion model and > syntax, and trying to talk folks into using it where appropriate. > But I don't think the SPDX needs to take that up if it doesn't want to. > > Cheers, > Trevor > > -- > This email may be signed or encrypted with GnuPG (http://www.gnupg.org). > For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy _______________________________________________ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
