mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Dave Hansen <dave.hansen@linux.intel.com>
Cc: linux-kernel@vger.kernel.org, dan.j.williams@intel.com,
	h.peter.anvin@intel.com, tglx@linutronix.de, corbet@lwn.net,
	linux-spdx@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH] Documentation: clarify driver licensing rules
Date: Wed, 12 Aug 2020 10:23:50 +0200	[thread overview]
Message-ID: <20200812082350.GB851575@kroah.com> (raw)
In-Reply-To: <20200811171748.F22CD85A@viggo.jf.intel.com>

On Tue, Aug 11, 2020 at 10:17:48AM -0700, Dave Hansen wrote:
> 
> Resend. Something appears to have eaten this on the way to LKML
> (at least) the last time.
> 
> --
> 
> From: Dave Hansen <dave.hansen@linux.intel.com>
> 
> Greg has challenged some recent driver submitters on their license
> choices. He was correct to do so, as the choices in these instances
> did not always advance the aims of the submitters.

And, to be honest, they were totally dumb attempts at doing things that
ended up not doing what they thought they were doing.

> But, this left submitters (and the folks who help them pick licenses)
> a bit confused. They have read things like
> Documentation/process/license-rules.rst which says:
> 
> 	individual source files can have a different license
> 	which is required to be compatible with the GPL-2.0
> 
> and Documentation/process/submitting-drivers.rst:
> 
> 	We don't insist on any kind of exclusive GPL licensing,
> 	and if you wish ... you may well wish to release under
> 	multiple licenses.

Both of these are find, but maybe you need to put:
	"don't try to do stupid things just because you can!"
somewhere in here instead?

> As written, these appear a _bit_ more laissez faire than we've been in
> practice lately. It sounds like we at least expect submitters to make
> a well-reasoned license choice and to explain their rationale. It does
> not appear that we blindly accept anything that is simply
> GPLv2-compatible.

That is correct, we shouldn't.

> Drivers appear to be the most acute source of misunderstanding, so fix
> the driver documentation first. Update it to clarify maintainer
> expectations.
> 
> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: H. Peter Anvin <h.peter.anvin@intel.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: linux-spdx@vger.kernel.org
> Cc: linux-doc@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
> 
>  b/Documentation/process/submitting-drivers.rst |   12 +++++++-----
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff -puN Documentation/process/submitting-drivers.rst~clarify-dual-licensing Documentation/process/submitting-drivers.rst
> --- a/Documentation/process/submitting-drivers.rst~clarify-dual-licensing	2020-08-11 09:35:55.493109636 -0700
> +++ b/Documentation/process/submitting-drivers.rst	2020-08-11 09:35:55.496109636 -0700
> @@ -59,11 +59,13 @@ What Criteria Determine Acceptance
>  ----------------------------------
>  
>  Licensing:
> -		The code must be released to us under the
> -		GNU General Public License. We don't insist on any kind
> -		of exclusive GPL licensing, and if you wish the driver
> -		to be useful to other communities such as BSD you may well
> -		wish to release under multiple licenses.
> +		The code must be released to us under the GNU General Public
> +		License. While there are no kernel-wide rules, some maintainers
> +		may insist on exclusive GPL licensing by default.

Maintainers should not do that, it is not their place to do so.  They
_can_ push back on, again, stupid things, but in the end, they should
accept anything that is a compatible license with the kernel as it is
really up to the copyright owner as to what license they wish to use.

So while I like the intent here, I don't think this wording change is
good as-is.

As it stands, the text makes sense, but as always, if you have legal
questions, you should be talking to a lawyer, not a kernel developer :)

thanks,

greg k-h

  reply	other threads:[~2020-08-12  8:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-11 17:17 Dave Hansen
2020-08-12  8:23 ` Greg KH [this message]
2020-08-12 14:45   ` Dave Hansen
2020-08-12 14:58     ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200812082350.GB851575@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=corbet@lwn.net \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=h.peter.anvin@intel.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-spdx@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®