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]
Date:   Mon, 30 Nov 2020 07:51:37 -0700
From:   Jonathan Corbet <corbet@....net>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     Thorsten Leemhuis <linux@...mhuis.info>,
        Christoph Hellwig <hch@....de>,
        Randy Dunlap <rdunlap@...radead.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH v3 1/3] LICENSES: Add the CC-BY-4.0 license

On Tue, 24 Nov 2020 12:11:09 +0000
Matthew Wilcox <willy@...radead.org> wrote:

> > That's why I came up with the thought "make the text available under more
> > liberal license in addition to the GPLv2 is a good idea here". I considered
> > MIT, but from what I see CC-BY 4.0 is a way better choice for documentation
> > that is more known to authors.
> > 
> > And I hope others pick up the idea when they write new documentation for the
> > kernel, so maybe sooner or later it's not unusual anymore.  
> 
> It's really tricky to make this work when, eg, including kernel-doc from
> files which are unambiguously licensed under the GPL. 

As Thorsten points out, there are no such directives in this particular
document.  I don't really see how any such could come to be introduced; we
could add a comment at the top saying that none should be added if that
would help.

We could also, if we saw fit, take the position that anything that has
been processed through the docs build is a derived product of the kernel
and must be GPL-licensed - any dual-licensing would be stripped by that
act.  That, too, should address this concern, I think.

In general I'd rather see fewer licenses in Documentation/ than more.  But
Thorsten has put a lot of effort into this work; if he wants to
dual-license it in this way, my inclination is to accommodate him.  But
that requires getting CC-BY-4.0 accepted into the LICENSES directory.
(That said, I believe it should go into LICENSES/dual/ rather than
preferred/).

Thanks,

jon

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ