From: Bernd Petrovitsch <bernd@petrovitsch.priv.at>
To: doug@easyco.com
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
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: Thu, 15 Sep 2011 12:20:47 +0200 [thread overview]
Message-ID: <1316082049.7273.24.camel@thorin> (raw)
In-Reply-To: <CAFx4rwR2LgMZ8x8aCPa=FnPF0yCOH+7=HbX8OENdbZoMUzO59g@mail.gmail.com>
Hi!
On Mit, 2011-09-14 at 14:34 -0700, Doug Dumitru wrote:
[....]
> This does not change the GPL nature of the kernel. It does change how
> non GPL modules can interact with the kernel. There are some (and I
> am not sure if this includes you), that believe that all commercial
> license kernel modules violate the GPL. Other believe that they are
You wrote "commercial" but actually meant "proprietary".
And yes, there are fully GPLv2 modules out there which are
"commercial" (whatever that actually means) - even in the sense that
people and companies live (also) directly from it.
You may rewrite the whole mail with s/commercial/proprietary/. It is
then (more) correct and IMHO very probably also more clear where you are
heading.
And please don't mix license issues (what can I do with it and what not)
with commercial issues (how and how much money can I make out of it) -
these are two totally different and independent things.
[...]
> entry into an existing, published API, and the API keeps caller/called
Is there a "published API" apart from the pragmatic one: look into
the .h (and .c) files and find it but beware, it may change with the
next release?
I don't think so. And no, generated (or other) documentation does not
change that.
> at "arms length" (which the block IO layer does), then it is possible
> to create a work that uses the API but is not a derivative, and
> hopefully the new symbol will be declared accessible to everyone.
That's the big wish of the proprietary folks - have an in-kernel API
which allows proprietary kernel modules.
Google for it to find lots of discussions about this topic and opinions
on what's OK and what's not OK.
[...]
> 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.
That has IMHO next to nothing to do if the module is a derivative work
of the kernel or not if you are a lawyer.
And there are several companies which play this game so you might want
to look how they try to handle that.
Bernd
--
Bernd Petrovitsch Email : bernd@petrovitsch.priv.at
LUGA : http://www.luga.at
next prev parent reply other threads:[~2011-09-15 10:20 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-11 14:50 [PATCH 1/2] block: export __make_request 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
2011-09-14 22:48 ` Doug Dumitru
2011-09-15 10:20 ` Bernd Petrovitsch [this message]
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=1316082049.7273.24.camel@thorin \
--to=bernd@petrovitsch.priv.at \
--cc=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;
as well as URLs for NNTP newsgroup(s).