mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: doug@easyco.com
Cc: Boaz Harrosh <bharrosh@panasas.com>,
	Christoph Hellwig <hch@infradead.org>,
	Jens Axboe <axboe@kernel.dk>,
	linux-raid@vger.kernel.org, dm-devel@redhat.com,
	linux-kernel@vger.kernel.org, nab@linux-iscsi.org,
	ryanh@us.ibm.com
Subject: Re: [PATCH 1/2] block: export __make_request
Date: Wed, 14 Sep 2011 23:01:04 +0100	[thread overview]
Message-ID: <20110914230104.51c03fa6@lxorguk.ukuu.org.uk> (raw)
In-Reply-To: <CAFx4rwR2LgMZ8x8aCPa=FnPF0yCOH+7=HbX8OENdbZoMUzO59g@mail.gmail.com>

> I agree with you, in part.  What you are saying implies that no new
> EXPORT can ever happen.  If you wrote this function, then obviously,

No.

> you can choose to export it GPL only.  Likewise, if you wrote this
> function, considering it's location in the block IO layer, I would ask
> that you consider exporting it generally.

The kernel is GPL, any work that is derivative is subject to the licence,
any work which is not is generally not subject to the licence.

> I don't think this is true, at least from a practical point.  If you
> develop a commercial module, you can link to the kernel through public
> symbols.  These symbols, and the kernels header files, define a public

You can create commercial modules but their licence must be GPL
compatible including source etc if they are derivative in any way. At
least that is what my lawyer advises me.

Possibly you mean "proprietary" here. The GPL welcomes people making
money out of things, it just rejects theft of freedoms given by other
parties.

> API that is usable from commercial modules.  Provided that the
> techniques used inside of the commercial module were not "derived
> from" the rest of the kernel, using the API is acceptable.

I'm not sure derivative works law is quite so clear cut, but then
'provide a clear concise definition of derivative works' appears to be
the legal version of The Goldbach Conjecture.

> When a symbol is not exported publicly, then, pretty much by
> definition, it is not a part of the public API.  This creates kernel

Not the view of the legal advice I have

> Again, I was not trying to create a contentious issue.  I was just
> asking that new exports consider what is around them, and try to
> maintain some consistency of GPL vs open exports.  A function that
> submits a block IO request seems to be a good candidate for an open
> API which implies an open export.

It's a GPL kernel, so to me the question is really moot.

I'm not trying to create contention. The reason I reply now and then to
these kinds of discussions is that I've been advised by my lawyer to do
so, because anyone who then produces a violating module who has seen this
message either as a recipient or if it turns up in a trawl can them be
subject to triple damages for wilful infringement - should it turn out
that the work is violating and they do not in turn have a good legal
assessment with which to show they did in fact take good care (and which
of course might well happen because derivative works are such a grey
fuzzy mess)

Whether it says EXPORT_SYMBOL, EXPORT_SYMBOL_GPL or RUBBERIZED_BANANA is
to my understanding irrelevant. If it does turn out to be relevant
however you are correct I'd make all my symbols _GPL....

Alan

  reply	other threads:[~2011-09-14 22:02 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-11 14:50 Christoph Hellwig
2011-09-11 14:51 ` [PATCH 2/2] block: remove support for bio remapping from ->make_request Christoph Hellwig
2011-09-12  3:25   ` NeilBrown
2011-09-12  9:59   ` Jens Axboe
2011-09-12 12:25     ` Christoph Hellwig
2011-09-12 12:26       ` Jens Axboe
2011-09-12  9:59 ` [PATCH 1/2] block: export __make_request Jens Axboe
2011-09-12 12:25   ` Christoph Hellwig
2011-09-12 12:26     ` Jens Axboe
2011-09-12 13:38       ` Christoph Hellwig
2011-09-12 18:04         ` Jens Axboe
2011-09-13 21:19           ` Christoph Hellwig
2011-09-14 17:17             ` Boaz Harrosh
2011-09-14 17:53               ` Doug Dumitru
2011-09-14 18:40                 ` Alan Cox
2011-09-14 21:34                   ` Doug Dumitru
2011-09-14 22:01                     ` Alan Cox [this message]
2011-09-14 22:48                       ` Doug Dumitru
2011-09-15 10:20                     ` Bernd Petrovitsch
2011-09-14 20:16               ` Nicholas A. Bellinger
2011-09-12 13:42 ` [PATCH 3/2] block: refactor generic_make_request Christoph Hellwig
2011-09-12 15:09   ` Vivek Goyal
2011-09-12 15:13     ` Christoph Hellwig
2011-09-15 11:55       ` Christoph Hellwig
2011-09-15 11:56         ` Jens Axboe

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=20110914230104.51c03fa6@lxorguk.ukuu.org.uk \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=axboe@kernel.dk \
    --cc=bharrosh@panasas.com \
    --cc=dm-devel@redhat.com \
    --cc=doug@easyco.com \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=nab@linux-iscsi.org \
    --cc=ryanh@us.ibm.com \
    /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®