1. Messages
  2. License of an open source license text

Re: License of an open source license text

Till Jaeger
 

Hi all,

I have some remarks from a lawyer's perspective who is scanning source code
and/or has to deal with the results from scanning.

1.
It is helpful if the license text file is differently identified from
licensed source files. There are some reasons for that:
- This license text is not licensed under itself.
- The information can be misleading. The LGPL-2.1 would be LGPL-2.1-only
although all source files might be LGPL-2.1-or-later
- It is good to know whether or not the license text is included in a source
package (and not just referenced). Accordingly, you know if adding the
license text is needed.

2.
Identifiers like "LicenseRef-GPL-3.0-license-text" would be great since you
can see on first view what is in the license file.

3.
I have no interest to know how the license text is licensed itself. All
known FOSS licenses allow copying and distribution. More is not needed.

4.
I have an interest to know whether or not the license text is identical to
the original one (or modified/shortened).

Not sure if this is helpful for you but I hope so.

Best regards,

Till



Am 18.06.20 um 16:32 schrieb Philippe Ombredanne:

Hi Richard:

On Thu, Jun 18, 2020 at 2:57 PM Richard Purdie wrote:

Just to be really clear, the license ID of a given specific
package *is* correct and definitive. What is unclear is the license of
the license information.

The challenge is that one software project can be split into multiple
binary packages and those binary packages can have finer grained
licenses.

For example, gcc which contains libgcc. gcc is GPL-3.0 and libgcc is
the under the runtime license exception. We specifically mark the
binary packages with the correct license.

This isn't enough for some legal departments and some licenses, we have
to have the full license text somewhere. We have options:

a) Include the full license text in every binary package
b) Have a licence package per test and require each binary package to
depend on that license package
c) As per b) but have the package management or tools figure out the
dependencies if requested
d) Have a license package per piece of software containing all the
licensing texts for that piece of software.

There are pros and cons for all of these, some of the issues are very
significant, particularly in a constrained embedded system. Rightly or
wrongly, we have d) implemented today and this is consistent with what
other distros like Debian do (although they merge docs and license
info, we split them).

Also, this assumes the licenses can be split into specific individual
chunks. I suspect in some cases this is not possible.

The question is what license is that package in d) under.
Then in this case you can take the same approach as Debian's
packaging: your package in d) can be under its own license unrelated
to the license of the things it contains.

You could state that the license of the packaging of these license
data is under a CC0-1.0. You are not making any assertion about the
license of the licenses which are under whatever license they may be;
and whatever these may be are self-contained in their own license
texts.

This is the approach I take in scancode.
I bundle thousand license texts and I am not reporting any specific
license for these license texts..
Instead I am only declaring that the license data set is under CC0-1.0

As an aside, this might make scancode's [1] processing a little more
complicated ... but this could be fixed if we know we are looking at
the license of Yocto packages somehow.
Join {Spdx-legal@lists.spdx.org to automatically receive all group messages.