Hey davem,
There has been a request in Fedora to confirm that the License field of
all the RPMs is correct [1]. We've made some recent changes to the
Fedora kernel [2] to correct the License field [3]. This License field
reflects the license of the *source* code and does not reflect the
license of the final binaries.
During our investigation we discovered two files in the kernel
drivers/net/appletalk/cops_ffdrv.h
drivers/net/appletalk/cops_ltdrv.h
which from their descriptions imply that the code contained is not GPL,
and seem to be in conflict of the kernel's overall license GPLv2.
To be clear, I am not asking for their removal, however, I do think a
better license should be issued for these files. The files were
trivially modified in 2006. It could be that the code in question is now
unused and it is just easier to remove them.
Is there anyone you know of that we could approach to determine a proper
SPDX License for these files?
P.
[1] https://docs.fedoraproject.org/en-US/legal/update-existing-packages/
[2] https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2648
[3] License: ((GPL-2.0-only WITH Linux-syscall-note) OR BSD-2-Clause)
AND ((GPL-2.0-only WITH Linux-syscall-note) OR BSD-3-Clause) AND
((GPL-2.0-only WITH Linux-syscall-note) OR CDDL-1.0) AND ((GPL-2.0-only
WITH Linux-syscall-note) OR Linux-OpenIB) AND ((GPL-2.0-only WITH
Linux-syscall-note) OR MIT) AND ((GPL-2.0-or-later WITH
Linux-syscall-note) OR BSD-3-Clause) AND ((GPL-2.0-or-later WITH
Linux-syscall-note) OR MIT) AND BSD-2-Clause AND BSD-3-Clause AND
BSD-3-Clause-Clear AND GFDL-1.1-no-invariants-or-later AND
GPL-1.0-or-later AND (GPL-1.0-or-later OR BSD-3-Clause) AND
(GPL-1.0-or-later WITH Linux-syscall-note) AND GPL-2.0-only AND
(GPL-2.0-only OR Apache-2.0) AND (GPL-2.0-only OR BSD-2-Clause) AND
(GPL-2.0-only OR BSD-3-Clause) AND (GPL-2.0-only OR CDDL-1.0) AND
(GPL-2.0-only OR GFDL-1.1-no-invariants-or-later) AND (GPL-2.0-only OR
GFDL-1.2-no-invariants-only) AND (GPL-2.0-only WITH Linux-syscall-note)
AND GPL-2.0-or-later AND (GPL-2.0-or-later OR BSD-2-Clause) AND
(GPL-2.0-or-later OR BSD-3-Clause) AND (GPL-2.0-or-later OR CC-BY-4.0)
AND (GPL-2.0-or-later WITH GCC-exception-2.0) AND (GPL-2.0-or-later WITH
Linux-syscall-note) AND ISC AND LGPL-2.0-or-later AND (LGPL-2.0-or-later
OR BSD-2-Clause) AND (LGPL-2.0-or-later WITH Linux-syscall-note) AND
LGPL-2.1-only AND (LGPL-2.1-only OR BSD-2-Clause) AND (LGPL-2.1-only
WITH Linux-syscall-note) AND LGPL-2.1-or-later AND (LGPL-2.1-or-later
WITH Linux-syscall-note) AND (Linux-OpenIB OR GPL-2.0-only) AND
(Linux-OpenIB OR GPL-2.0-only OR BSD-2-Clause) AND
Linux-man-pages-copyleft AND MIT AND (MIT OR Apache-2.0) AND (MIT OR
GPL-2.0-only) AND (MIT OR GPL-2.0-or-later) AND (MIT OR LGPL-2.1-only)
AND (MPL-1.1 OR GPL-2.0-only) AND (X11 OR GPL-2.0-only) AND (X11 OR
GPL-2.0-or-later) AND Zlib AND (copyleft-next-0.3.1 OR GPL-2.0-or-later)
On 9/26/23 1:34 AM, Christoph Hellwig wrote:
> On Fri, Sep 15, 2023 at 09:39:05AM -0400, Prarit Bhargava wrote:
>>
>> Is there anyone you know of that we could approach to determine a proper
>> SPDX License for these files?
Answering this question generally, even though it sounds like it wasn't
needed for this particular situation:
YES! If you find a license in the kernel that does not match a license
already on the SPDX License List and want to submit the license for
inclusion on the SPDX License List (which, if accepted, means the
license will get an SPDX id assigned), please follow this process:
https://github.com/spdx/license-list-XML/blob/main/DOCS/request-new-license.md
By the way, people on the linux-spdx list may be interested to know that
Fedora has adopted the use of SPDX license ids in the license field of
Fedora package metadata. There has been close collaboration between the
two projects, which has resulted in 95 licenses or exceptions added to
the SPDX License List so far. I think this is a great thing (even if a
lot of work) as it is making the SPDX License List more reflective of
the reality of open source software licensing (including all the
variations on old permissive licenses).
Jilayne
On 9/26/23 04:02, Greg KH wrote:
> On Tue, Sep 26, 2023 at 12:34:03AM -0700, Christoph Hellwig wrote:
>> On Fri, Sep 15, 2023 at 09:39:05AM -0400, Prarit Bhargava wrote:
>>> To be clear, I am not asking for their removal, however, I do think a better
>>> license should be issued for these files. The files were trivially modified
>>> in 2006. It could be that the code in question is now unused and it is just
>>> easier to remove them.
>>>
>>> Is there anyone you know of that we could approach to determine a proper
>>> SPDX License for these files?
>>
>> The code contains firmware that is downloaded to the device. The proper
>> thing would be to convert them to separate binary files in the
>> linux-firmware packages. But given that the driver has seen nothing
>> but tree wide cleanups since the dawn of git I suspect there is no
>> maintainer and probably no user left. The best might be to indeed just
>> remove it and see if anyone screams, in which case we could bring it
>> back after doing the above.
>>
>
> We should just remove them for now, I have no objection to that at all.
>
> Want me to send the patch?
Yes, that would be appreciated. Thanks :)
P.
>
> thanks,
>
> greg k-h
>
On Tue, Sep 26, 2023 at 12:34:03AM -0700, Christoph Hellwig wrote:
> On Fri, Sep 15, 2023 at 09:39:05AM -0400, Prarit Bhargava wrote:
> > To be clear, I am not asking for their removal, however, I do think a better
> > license should be issued for these files. The files were trivially modified
> > in 2006. It could be that the code in question is now unused and it is just
> > easier to remove them.
> >
> > Is there anyone you know of that we could approach to determine a proper
> > SPDX License for these files?
>
> The code contains firmware that is downloaded to the device. The proper
> thing would be to convert them to separate binary files in the
> linux-firmware packages. But given that the driver has seen nothing
> but tree wide cleanups since the dawn of git I suspect there is no
> maintainer and probably no user left. The best might be to indeed just
> remove it and see if anyone screams, in which case we could bring it
> back after doing the above.
>
We should just remove them for now, I have no objection to that at all.
Want me to send the patch?
thanks,
greg k-h
On Fri, Sep 15, 2023 at 09:39:05AM -0400, Prarit Bhargava wrote:
> To be clear, I am not asking for their removal, however, I do think a better
> license should be issued for these files. The files were trivially modified
> in 2006. It could be that the code in question is now unused and it is just
> easier to remove them.
>
> Is there anyone you know of that we could approach to determine a proper
> SPDX License for these files?
The code contains firmware that is downloaded to the device. The proper
thing would be to convert them to separate binary files in the
linux-firmware packages. But given that the driver has seen nothing
but tree wide cleanups since the dawn of git I suspect there is no
maintainer and probably no user left. The best might be to indeed just
remove it and see if anyone screams, in which case we could bring it
back after doing the above.