Re: SPDX: Appletalk FW license in the kernel
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
Re: SPDX: Appletalk FW license in the kernel
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
Re: SPDX: Appletalk FW license in the kernel
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
Re: SPDX: Appletalk FW license in the kernel
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.
