Re: License of an open source license text


Richard Purdie
 

On Thu, 2020-06-18 at 14:31 +0200, Philippe Ombredanne wrote:
On Thu, Jun 18, 2020 at 12:37 AM Richard Purdie
<richard.purdie@...> wrote:

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?
I think there may be a different perspective to consider: Why
include the GPL text if it does not apply (or for that matter for any
license)?

A license id that is trying to convey more or less that "we included
this license text in this package but it really does not apply to
anything, so please ignore it" may not be the best approach.

Instead, what about correcting the Yocto packaging and include only
the licenses that apply to this package?
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.

If we went for one of the other approaches, we'd be able to remove
license texts that were not "active" but I suspect the implementations
are extremely complex, fragile and overkill. Its also not what we've
been asked to fix.

You also wrote:

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.
IMHO that's the root of the problem, you are including and mixing
licenses that may not apply and trying to convey with some id that
these included licenses may not apply.
No, we're not. We're trying to convey that the package contains license
texts under whatever license the license text is under, not binaries
under a specific license. We need an identifier that says "this is all
the license information about piece of software X". We could have a
single identifier however I think its clear that there are going to be
different licenses for different license texts (where they are even
known!).

Cheers,

Richard

Join Spdx-legal@lists.spdx.org to automatically receive all group messages.