Re: [OE-core] [meta-oe][PATCH 3/4] libgcrypt: made libgcrypt-lic license "GPLv2+ & LGPLv2.1+"

["Matthias Schoepfer" <matthias.schoepfer@googlemail.com>]

Hi Richard,

thanks, that does help maybe a little. Personally, I find the license / 
compliance topic one of the most annoying things in embedded development 
*by far*. I also wonder, why nobody else has stumbled across this, since 
I guess it is quite common to rule out GPLv3, because most project 
managers I have seen are very worried about this. Nobody (at least not 
our lawyers can) can say, how you can safely use GPLv3ed software. 
Starts out with standard template library. It really is only headers. 
Are they subject to the linking exception? My favorite solution would be 
to open source everything. But my company does not like this very much...

Anyhow: There are 4 recipes affected. These are somewhat special, 
because GPLv3 is only applicable on certain packages that are not 
commonly installed on the target.

If I got you right, we should set:

LICENSE_${PN}-lic = "FSF-license-text"

If that is correct, I will happily prepare a patch set...

Regards,

     Matthias

On 7/6/20 6:26 PM, Richard Purdie wrote:
> I did eventually get a response from the people on the SPDX-legal
> mailing list. There wasn't a 100% clear consensus but for Yocto
> Project/OE's situation, I think the LICENSE for these packages needs to
> be:
>
> XXX-license-text
>
> which for SPDX identifiers would be exported as:
>
> LicenseRef-XXX-license-text
>
> The idea here is to spell out that it is the license text. People can
> then process that accordingly in output data from the build system but
> its clear its different from the license itself. It avoids us making
> any claims as to what this license actually is, for the FSF licences
> its relatively clear, for others it may not be.
>
> We could factor all of the *GPL licenses into "FSF-license-text" since
> they're all common as far as I know, but that isn't easily automated so
> is probably not worth doing.
>
> Does that help move things forward?
>
> Cheers,
>
> Richard