Licensing discrepancies or ambiguities

[Tom Rini]

On Sat, Nov 25, 2023 at 02:39:53PM -0800, Vagrant Cascadian wrote:
> On 2023-11-21, Tom Rini wrote:
> > On Tue, Nov 21, 2023 at 11:10:57AM -0800, Vagrant Cascadian wrote:
> >
> >> I've been reviewing the copyright and license information for Das U-Boot
> >> in preparation for uploading to Debian, and found a few surprises.
> >> 
> >>  tools/libfdt/fdt_rw.c: /* SPDX-License-Identifier: GPL-2.0+ BSD-2-Clause */
> >
> > This comes from the kernel and has been clarified there:
> > // SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
> 
> That's much better! Thanks for looking into it! I suspect there are
> quite a few that get pulled in from linux or elsewhere that might have
> similar issues.
> 
> 
> >> I *think* according to the SPDX spec this needs an OR or an AND. I also
> >> see no copyright declaration, although maybe there is a standard
> >> interpretation for this.
> >> 
> >> Similar issue with (though thankfully they include copyright
> >> declarations):
> >> 
> >>  include/bloblist.h:/* SPDX-License-Identifier: GPL-2.0+ BSD-3-Clause */
> >>  common/bloblist.c:// SPDX-License-Identifier: GPL-2.0+ BSD-3-Clause
> >
> > Simon?
> >
> >>  doc/README.ubispl:# SPDX-License-Identifier: GPL 2.0+ BSD-3-Clause
> >
> > Should be an OR as well, yes, but it's also out of date and we could
> > just delete if a problem.
> 
> Ok.
> 
> >> This one has a non-existent license:
> >> 
> >>   test/lib/strlcat.c: // SPDX-License-Identifier: GPL-2.1+
> >> 
> >> No such license exists, though thankfully it references the exact file
> >> in the original glibc sources it came from, which is listed as
> >> LGPL-2.1+.
> >
> > Since you did the research would you mind sending the patch? Thanks.
> 
> Will do eventually!
> 
> 
> 
> Also found some more ambiguous ones where the license text is in
> conflict with the SPDX identifiers:
> 
>   arch/sandbox/cpu/u-boot-spl.lds-/* SPDX-License-Identifier: GPL-2.0+ */
>   arch/sandbox/cpu/u-boot-spl.lds-/*
>   arch/sandbox/cpu/u-boot-spl.lds- * Copyright (c) 2011-2012 The Chromium OS Authors.
>   arch/sandbox/cpu/u-boot-spl.lds: * Use of this source code is governed by a BSD-style license that can be
>   arch/sandbox/cpu/u-boot-spl.lds- * found in the LICENSE file.
>   arch/sandbox/cpu/u-boot-spl.lds- */
> 
> The referred to LICENSE file does not appear to exist in u-boot, and
> exactly what the text of this BSD-style license is ... a mystery.
> 
> And lib/zstd includes many entries in a similar situation:
> 
>   lib/zstd/Makefile-# Copyright (c) Facebook, Inc.
>   lib/zstd/Makefile-# All rights reserved.
>   lib/zstd/Makefile-#
>   lib/zstd/Makefile:# This source code is licensed under both the BSD-style license (found in the
>   lib/zstd/Makefile-# LICENSE file in the root directory of this source tree) and the GPLv2 (found
>   lib/zstd/Makefile-# in the COPYING file in the root directory of this source tree).
>   lib/zstd/Makefile-# You may select, at your option, one of the above-listed licenses.
> 
> This seems like it would be "GPL-2.0 OR BSD-*something*", but it is unclear
> what BSD-style maps to, as the LICENSE file is not present where it
> claims.
> 
> Many similar discrepancies can be found with:
> 
>   git grep -B4 -A3 'BSD-style'
> 
> 
> I probably have mroe to dig up, but these are the ones that leapt out at
> me for now!

So, with my project maintainer hat on, U-Boot is essentially a GPLv2
project. We have a large amount of source code borrowed directly from
the Linux Kernel and that is GPL-2.0 (and not or later), and today
there's no feasible way to do not use that code. So everything in use
must be something that is compatible with GPL-2.0, and anything with an
incompatible license is worrisome and needs to be addressed.

In general, some of our inconsistencies should match the Linux Kernel
(zstd is another one), and it might be best to file issues at
https://source.denx.de/u-boot/u-boot/-/issues/ for these as you find
them so that they can be tracked, if you aren't able to submit patches
correcting them. There are a few cases, such as the sandbox one that are
U-Boot specific and I assume can be fixed by the author once noted (and
in that specific case I know Simon also likes issues to be filed).

Thanks again for looking in to these kind of issues, I appreciate it.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20231127/e798d016/attachment.sig>