linux-kernel - Re: [PATCH 1/2] block: export __make

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110914230104.51c03fa6@lxorguk.ukuu.org.uk>
Date:	Wed, 14 Sep 2011 23:01:04 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	doug@...yco.com
Cc:	Boaz Harrosh <bharrosh@...asas.com>,
	Christoph Hellwig <hch@...radead.org>,
	Jens Axboe <axboe@...nel.dk>, linux-raid@...r.kernel.org,
	dm-devel@...hat.com, linux-kernel@...r.kernel.org,
	nab@...ux-iscsi.org, ryanh@...ibm.com
Subject: Re: [PATCH 1/2] block: export __make_request

> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/