[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [dm-devel] [PATCH 1/2] block: export __make_request

On Wed, Sep 14, 2011 at 11:40 AM, Alan Cox <alan lxorguk ukuu org uk> wrote:
> On Wed, 14 Sep 2011 10:53:22 -0700
> Doug Dumitru <doug easyco com> wrote:
>> It would be great if this function were exported, but I would
>> encourage everyone to consider exporting it generally, not just for
>> GPL usage.
> That would require a licensing change for the kernel. The kernel is a GPL
> work. Some of us have not licensed it in any other way.


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,
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.

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
legal, but perhaps not desirable.  Others believe there is no issue.

Again, my request was just a polite request to consider the sub-system
when deciding on whether an EXPORT or EXPORT_GPL was more appropriate.

>> The kernel seems to be pretty clean that some subsystems are GPL only
>> (things like sysfs), and some are open
> The _GPL is meant to make it clear they are internal symbols. The lack of
> an _GPL does not make them usable by non GPL code, it merely indicates
> that its perhaps more likely that you could in some cases shown something
> was not a derivative work.

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
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.

When a symbol is not exported publicly, then, pretty much by
definition, it is not a part of the public API.  This creates kernel
functionality that is unreachable from a commercial module, regardless
of whether the commercial module is derived or not.  As such, the
EXPORT_GPL has the effect of being even more stringent than the GPL
license itself.  With an EXPORT_GPL, the author is saying that this
API is not available to commercial modules even if the commercial
software is not a derivative work.

> The licensing is determined by the license document, and that very
> clearly says the boundary is derivative works. The rest is just vague
> guidance.

I am very careful about what is a derivative work.  I am also careful
about honoring author's "desires" as to how stuff gets exported.
Right now, the block IO layer has a pretty clean, published, API with
adequate public symbols to get real work done, either from GPL or
commercial licensed modules.  If useful functions are walled off,
then this does not change the derivative nature, but just degrades the
usefulness of the kernel.  This would be like exporting kmalloc() as
an open symbol, but exporting kfree() as GPL only.

I guess another way of saying this is that if you are creating a new
entry into an existing, published API, and the API keeps caller/called
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.

> In addition btw please be careful when trying to do this even with non
> derivative code your lawyer is happy with. The kernel contains algorithms
> which are subject to various US software patent mess where GPL use has
> been granted, that may impact you if you use such code indirectly in non
> GPL code.

Understood, but, in all fairness, the US patent mess is far worse and
I suspect that breathing violates someones claim.

> Alan

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.

Doug Dumitru
EasyCo LLC

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]