Hi Steve,

Thanks for the reply, it matches my first take on understanding this
situation and is what we do today, however, we're seeing some push back
from our users and I do think they have a point to some extent. I had
hoped there was an existing solution/convention we could follow but it
appears not. I'm going to play devils advocate and put a case for why
this matters to users and may be something SPDX needs to think about.

For better or worse there are legal departments who tell engineers that
products must contain "no GPL-3.0". I'm not getting into whether that
is a good thing to do or not, its mandated in companies and engineers
are being asked to solve the problem. I'm picking on GPL-3.0 but it
could be any license.

In YP, a single piece of software can generate multiple binary
packages. We can put non-GPL-3.0 components in one package, the GPL-3.0
in another and the end user can select to install only the non-GPL-3.0
packages into their image. Binary packages have an associated license.
We also generate a "license text" package which contains the license
texts this piece of software is under. There is only one license text
package per piece of software, its impractical to split those apart.

There are licenses which require the license texts to be included with
the binaries. For this reason, some legal departments require the
license text package be included in the image in all cases. They audit
their compliance by looking at the licenses of the packages installed
into a given image.

If we set the license of the licence text package to include GPL-3.0,
the legal department blocks the release since they said "no GPL-3.0".
If you tell them its only the license text, they tell you the license
is not GPL-3.0 and the license is incorrect. What should the license
be though?

To handle this, I think YP is going to have to identify these cases as
something like "GPL-3.0-license-text". It will then be up to the end
users to decide whether they can include such a thing in their images
or not. YP has been tentatively moving toward using SDPX license
identifiers where we can. It would be nice if we could standardise
this, if not, we would just accept that YP use SDPX as a guide but has
to handle cases like this which SPDX doesn't.

The thing I like about this approach is we have no need to make any
claim about what license "GPL-3.0-license-text" is actually under, just
that it is the license text alone.

Hopefully that gives a bit more insight into the challenges our users
are running into. I guess the question is therefore whether such a
convention is something SPDX could/should support? I'm equally open to
other ideas but I think we (YP) will have to do something one way or
another.

Cheers,

Richard



On Wed, 2020-06-17 at 17:11 -0400, Steve Winslow wrote:
> Hi Richard,
>
> Thanks for your email. A couple of thoughts, speaking just for
> myself:
>
> When it comes to the question of "what license applies to a license
> text," I think this is something that has typically been seen as
> outside the scope of the SPDX License List. The licenses on the list
> cover those used for software as well as other types of open
> collaboration (e.g. open hardware, data, etc). But I don't think the
> license list has gotten into (or has plans to get into) including
> identifiers for which licenses apply to licenses themselves.
>
> I'm not sure if I followed the specifics of the Yocto use case you
> described. I think that in most cases where I've seen folks
> associating SPDX license identifiers with files, they would generally
> just use the license that is reflected by the license text itself. So
> for instance, when seeing a file containing the text of MPL-2.0, in
> an SPDX document they would note the license for that file as MPL-2.0
> -- rather than whatever the license of the MPL-2.0 license text might
> hypothetically be. I don't know that I'm describing it well, but
> that's how I'd think of it, since that conveys the information that
> is really relevant to users of that code.
>
> Looking at REUSE (
> https://reuse.software/spec/#copyright-and-licensing-information), it
> looks to me like they take a different but similar approach, where
> license files themselves do not have meta-licensing information
> associated with them. I know there are some REUSE folks on this list
> so I hope they'll speak up if I'm mischaracterizing this.
>
> Not sure if I've answered your question... but basically I would just
> recommend associating the license's own identifier with the license
> text file, since that will be the most comprehensible to folks who
> are looking to understand the software package's license.
>
> Hope this helps,
> Steve
>
> On Tue, May 26, 2020 at 3:25 PM Richard Purdie <
> richard.purdie@...> wrote:
> > Hi,
> >
> > I work on the Yocto Project and we use SDPX identifiers when
> > working
> > with open source licenses. An issue has come up and it was
> > suggested I
> > ask about it here.
> >
> > The question is quite simple:
> >
> > Which licence are we using when we share just the license text?
> >
> > The background is more complex:
> >
> > YP has some software which is under "LGPL-2.1 and GPL-3 and GPL-2"
> > where one source file is v3, the rest are under other licenses.
> >
> > When we build that software, multiple binaries result, we group
> > them
> > into different packages and can be specific about which licences
> > each
> > binary is under. If no GPLv3 code is in there, it can be under the
> > other licenses.
> >
> > We also put the license texts into its own package. Right now that
> > package is licensed as "LGPL-2.1 and GPL-3 and GPL-2", the same as
> > the
> > overall license.
> >
> > The problem is if someone excludes GPL-3 from their images, they
> > can
> > exclude specific packages but they also exclude the license package
> > which isn't what they want.
> >
> > If the license text is under GPL-3 then this is unfortunate but we
> > could just have to tell people to live with that. If it isn't but
> > is
> > under a different license (or a subset of it), what license do we
> > put
> > down for that package? I don't believe there is no SPDX identifier
> > we
> > can use?
> >
> > To be clear, we don't want to modify the license itself but want to
> > list something in the license field of our binary package which
> > says
> > what its license is.
> >
> > Another way of putting is what is the license identifier for:
> >
> > "Everyone is permitted to copy and distribute verbatim copies of
> > this license document, but changing it is not allowed."
> >
> > (quoted from the GPL)
> >
> > Cheers,
> >
> > Richard
> >
> >
> >
> >
>
>