linux-kernel - Re: [PATCH] mm: replace FSF address with web source in license notices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <969a24d542fbd98ec8badf64e9d1909c@posteo.de>
Date:   Tue, 14 Nov 2017 11:21:49 +0100
From:   Martin Kepplinger <martink@...teo.de>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     catalin.marinas@....com, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm: replace FSF address with web source in license
 notices

Am 14.11.2017 11:02 schrieb Michal Hocko:
> On Tue 14-11-17 10:55:35, Martin Kepplinger wrote:
>> Am 14.11.2017 10:49 schrieb Michal Hocko:
>> > On Tue 14-11-17 10:44:38, Martin Kepplinger wrote:
>> > > A few years ago the FSF moved and "59 Temple Place" is wrong. Having
>> > > this
>> > > still in our source files feels old and unmaintained.
>> > >
>> > > Let's take the license statement serious and not confuse users.
>> > >
>> > > As https://www.gnu.org/licenses/gpl-howto.html suggests, we replace
>> > > the
>> > > postal address with "<http://www.gnu.org/licenses/>" in the mm
>> > > directory.
>> >
>> > Why to change this now? Isn't there a general plan to move to SPDX?
>> 
>> Shouldn't a move to SPDX only be additions to what we currently have? 
>> That's
>> at least what the "reuse" project suggests, see
>> https://reuse.software/practices/
>> with "Don’t remove existing headers, but only add to them."
> 
> I thought the primary motivation was to unify _all_ headers and get rid
> of all the duplication. (aside from files which do not have any license
> which is under discussion elsewhere).

I doubt that this can be fully accieved in the long run :) It'd be nice 
of course in
some way.

But I also doubt that it'd be so easy to remove the permission 
statements.
The FSF who's license we use suggest to have them, but others do too.
And as mentioned, "using SPDX" doesn't imply "not having permission
statements".

But I think that's off-topic actually. Moving to SPDX could still be 
done in
any way whatsoever after this. This change fixes a *mistake* and can 
reduce
confusion or even support license compliance, who knows :)

thanks
                                         martin