public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Ted Ts'o" <tytso@mit.edu>
To: "Luis R. Rodriguez" <mcgrof@frijolero.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	rusty@rustcorp.com.au, linux-kernel@vger.kernel.org,
	Keith Packard <keithp@keithp.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	David Woodhouse <dwmw2@infradead.org>,
	Stephen Hemminger <shemminger@vyatta.com>,
	"John W. Linville" <linville@tuxdriver.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH] module: Clarify GPL-Compatible is OK
Date: Sat, 7 Apr 2012 17:15:12 -0400	[thread overview]
Message-ID: <20120407211512.GC11295@thunk.org> (raw)
In-Reply-To: <CAB=NE6Wn4w_rmm-9dTjeLCmFBwFUv_R+o05=UW1SODBN2hFH0w@mail.gmail.com>

On Fri, Apr 06, 2012 at 08:01:36PM -0700, Luis R. Rodriguez wrote:
> > I also really don't see how this helps License compliance folks.  If
> > the BSD folks trying to figure out whether or not they can use some
> > piece of code, "GPL-Compatible" is no more useful than as "Dual
> > BSD/GPL".  In fact, Dual BSD/GPL might actually be more useful since
> > at least to me it says it can be used under the BSD or GPL license,
> > which is precisely what the BSD folks need.
> 
> If we are OK with this thread serving as documentation for this then
> so be it, but I still prefer for this to be clarified more. *I* am
> comfortable with this but I know other vendors who did try to achieve
> the same sharing had quite a bit of time trying to validate the
> approach.

I would rather think the obvious clarification would be reading the
d*mn copyright headers.  That's going to have much more weight in a
legal dispute in any case.  If the answer is that the Linux Foundation
needs to have a bit more basic training about what a Dual License
means in its license compliance services, maybe that's the right thing
--- although if a lawyer doesn't understand how dual licenses work,
I'd suggest that the company find a better lawyer....

> I rather speed help clarify this is a reasonable approach
> and also avoid flamewars like the ones we faced when developers eons
> ago though that we *had* to GPL the OpenBSD ar5k HAL when we ported it
> to Linux for use in ath5k.

So this is a different issue.  I assume you are referring to the fact
that include/linux/license.h's license_is_gpl_compatible() doesn't
have a pure BSD option?  If that's the issue, then lobby for adding
the line:

+	|| strcmp(license, "BSD") == 0

If you are really worried about people being upset that currently, you
have to explicitly add a GPL license to BSD-licensed driver code
before it gets imported into the kernel, and you are trying to
sidestep the issue by adding a "GPL-Compatible" license (on the
grounds that a BSD-only license qualifies as GPl-Compatible), let's
have that debate openly, instead of trying to side-step it by adding
"GPL-compatible" to include/linux/license.h and allowing BSD-only
modules to use GPL-only symbols via a back door.

Regards,

							- Ted

  reply	other threads:[~2012-04-07 21:15 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-07  0:11 [PATCH] module: Clarify GPL-Compatible is OK Luis R. Rodriguez
2012-04-07  0:27 ` Greg Kroah-Hartman
2012-04-07  0:28 ` Al Viro
2012-04-07  0:57   ` Luis R. Rodriguez
2012-04-07  0:36 ` Linus Torvalds
2012-04-07  0:51   ` Luis R. Rodriguez
2012-04-07  1:02     ` Luis R. Rodriguez
2012-04-08 12:42       ` Arend van Spriel
2012-04-07  2:49     ` Ted Ts'o
2012-04-07  3:01       ` Luis R. Rodriguez
2012-04-07 21:15         ` Ted Ts'o [this message]
2012-04-08  0:52           ` Luis R. Rodriguez
2012-04-08 14:57             ` Alan Cox
2012-04-08 16:06               ` Luis R. Rodriguez
2012-04-08 17:12                 ` Alan Cox
2012-04-08 20:23             ` Ted Ts'o
2012-04-07 19:03 ` Alan Cox
2012-04-08 12:49   ` Arend van Spriel
2012-04-08 22:50 ` Dan Williams
2012-05-07  2:39 ` Rusty Russell

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=20120407211512.GC11295@thunk.org \
    --to=tytso@mit.edu \
    --cc=dwmw2@infradead.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=keithp@keithp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=mcgrof@frijolero.org \
    --cc=ralf@linux-mips.org \
    --cc=rusty@rustcorp.com.au \
    --cc=shemminger@vyatta.com \
    --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