From: John Hubbard <jhubbard@nvidia.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: <john.hubbard@gmail.com>, Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
Ingo Molnar <mingo@kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/1] refcount: restore kref_get and kref_put to non-GPL status
Date: Wed, 8 Mar 2017 02:52:42 -0800 [thread overview]
Message-ID: <6b0551c9-dc34-9e87-c8c9-7bdfea85e1f6@nvidia.com> (raw)
In-Reply-To: <20170308101215.GA15198@kroah.com>
On 03/08/2017 02:12 AM, Greg Kroah-Hartman wrote:
> On Wed, Mar 08, 2017 at 01:59:33AM -0800, John Hubbard wrote:
>>
>>
>> On 03/08/2017 01:48 AM, Greg Kroah-Hartman wrote:
>>> On Wed, Mar 08, 2017 at 01:25:48AM -0800, john.hubbard@gmail.com wrote:
>>>> From: John Hubbard <jhubbard@nvidia.com>
>>>>
>>>> Hi,
>>>>
>>>> Say, I'm 99% sure that this was just an oversight, so
>>>> I'm sticking my neck out here and floating a patch to
>>>> Put Things Back. I'm hoping that there is not some
>>>> firm reason to GPL-protect the basic kref_get and
>>>> kref_put routines, because when designing some
>>>> recent new (open-source, yay!) device drivers, we relied
>>>> on this being available, even for MIT-licensed code.
>>>
>>> MIT-licensed code should be just fine with GPL symbols, just use the
>>> correct MODULE_LICENSE() setting and all is good.
>>
>> Actually, we're still using this license string:
>>
>> MODULE_LICENSE("MIT");
>>
>> which I understand does *not* grant access to GPL symbols. So I guess we'd
>> have to switch over to "MIT/GPL", if I understand correctly, in order to be
>> all correct here.
>
> You need to write this as:
> MODULE_LICENSE("Dual MIT/GPL");
> for the linker to handle this properly as that is the string it is
> looking for.
Yes, understood. I thought from your previous response that maybe "MIT" alone was
*intended* to provide access, but this makes sense and matches what I'd thought
earlier. And of course, your other point (about the header itself being licensed)
overrides this, but it's nice to get clarification on this detail, as long as I'm
stuck--for now--on "MIT".
Appreciate your time and quick responses on this, I know it's probably tiresome to
answer these sorts of questions.
thanks again,
john h
>
> thanks,
>
> greg k-h
>
prev parent reply other threads:[~2017-03-08 12:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-08 9:25 john.hubbard
2017-03-08 9:25 ` [PATCH] " john.hubbard
2017-03-08 9:50 ` Greg Kroah-Hartman
2017-03-08 9:53 ` John Hubbard
2017-03-08 16:03 ` Christoph Hellwig
2017-03-08 9:48 ` [PATCH 0/1] " Greg Kroah-Hartman
2017-03-08 9:59 ` John Hubbard
2017-03-08 10:12 ` Greg Kroah-Hartman
2017-03-08 10:52 ` John Hubbard [this message]
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=6b0551c9-dc34-9e87-c8c9-7bdfea85e1f6@nvidia.com \
--to=jhubbard@nvidia.com \
--cc=gregkh@linuxfoundation.org \
--cc=john.hubbard@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/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®