J Lovejoy wrote:

The issue identified on the call today (and Mark will correct me if I've
misstated) is that when AND is used at the file level (Section 4), it's
clear that both licenses apply to the given file. However, when AND is used
at the package level (Section 3), it could mean, for example:

1) both licenses apply to some files

2) both licenses apply to all the files

3) one license applies to some files and the other license applies to other
files

On Fri, May 15, 2015 at 12:57 AM, Alan Tse <Alan.Tse@...> wrote:

And just to confirm, does "OR" have the same 3 interpretation problem at the
package level?

IMHO yes. This is really left to the SPDX authors to provide the level
of details they want to provide.
More is better but not mandated.

Here's another thought I had for real world practice. When a package takes
in other sub packages, are they leaving the original licenses intact or
converting them to the project license (ignoring potentially compatibility
issues)? I always assumed it's the former but it's not always clear to me
if there's an industry practice to fall back on.

I have seen it done both ways. And quite often this is a combination of both.
Taking Apache as an open source example, you see quite often an
aggregated composite notice and license texts listing every licenses
of non-Apache and Apache components embedded in a given package
(Tomcat is a good example). You also see each individual original
notice and licenses left as-is further down the tree. When translated
to SPDX it would be likely redundant to repeat things ... But it is
convenient to have things in one place summarized. In practice having
a summary report produced from lower level could be a tool-provided
solution IMHO.

--
Cordially
Philippe Ombredanne