linux-kernel - Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

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: <1508159461.6297.134.camel@infradead.org>
Date:   Mon, 16 Oct 2017 14:11:01 +0100
From:   David Woodhouse <dwmw2@...radead.org>
To:     Greg KH <gregkh@...uxfoundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] Documentation: Add a file explaining the requested
 Linux kernel license enforcement policy

On Mon, 2017-10-16 at 11:25 +0200, Greg KH wrote:
> Documentation: Add a file explaining the requested Linux kernel
> license enforcement policy
> 
> Here's a pull request to add a new file to the kernel's Documentation directory.
> It adds a short document describing the views of how the Linux kernel community
> feels about enforcing the license of the kernel.
> 
> The patch has been reviewed by a large number of kernel developers already, as
> seen by their acks on the patch, and their agreement of the statement with
> their names on it.  The location of the file was also agreed upon by the
> Documentation maintainer, so all should be good there.
> 
> For some background information about this statement, see this article
> written by some of the kernel developers involved in drafting it:
> 	http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement/
> and this article that answers a number of questions that came up in the
> discussion of this statement with the kernel developer community:
> 	http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement-faq/
> 
> If anyone has any further questions about it, please let me, and the TAB
> members, know and we will be glad to help answer them.

It's a shame you don't explicitly mention the FSF's / Conservancy's
Principles of Community-Oriented GPL Enforcement:
https://www.fsf.org/licensing/enforcement-principles

I think this approach is a good thing in general, and I know
Conservancy have been talking about it for a while, including
conversations with the TAB on early drafts of this — but I'm a little
concerned that what we've ended up with is a bit one-sided. We're
giving something away, for nothing in return.

In the long period of negotiation with violators, what typically
happens is they keep providing "candidate" source releases which are
ever closer to being compliant, but rarely *actually* compliant.

With a binding promise to forgive them for past violations as soon as
they're fixed, we basically lose one of the few levers we had to
encourage them to come *completely* into compliance. Now I fear some of
them will only ever come close enough that they know we won't actually
take the last resort of legal action, purely for what *remains* to be
fixed.

This would have been better if it specified that it applied to
*unintentional* violations, and also gave a time limit — automatic
reinstatement *only* happens if complete compliance is achieved within
90 days, for example. That would help genuine developers who are only
*accidentally* committing a criminal offence through not paying enough
attention, while not giving succour to those who intentionally do so.
Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (4938 bytes)