[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20120423001306.040c512b@pyramind.ukuu.org.uk>
Date: Mon, 23 Apr 2012 00:13:06 +0100
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: Mike Snitzer <snitzer@...hat.com>
Cc: James.Bottomley@...senpartnership.com, linux-scsi@...r.kernel.org,
Hannes Reinecke <hare@...e.de>,
Chandra Seetharaman <sekharan@...ibm.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] [SCSI] scsi_dh: change scsi_dh_detach export to
EXPORT_SYMBOL
> Anyway, your no compromises approach is admirable but it doesn't erase
> the fact that all proprietary Linux drivers use EXPORT_SYMBOL code.
People still steal from shops. It doesn't mean we should abolish the idea
of theft.
> So what you're really saying is no proprietary drivers are allowed to be
> loaded into a Linux kernel.
The GPL defines the boundary. Whether it is possible for a work to be
non-derivative and a kernel module is a matter for the lawyers to debate.
If it is derivative however I don't think there is quite so much doubt.
Linus wrote the following
|>"On Wed, 3 Dec 2003, Kendall Bennett wrote:
|>
|> I have heard many people reference the fact that the although the Linux
|> Kernel is under the GNU GPL license, that the code is licensed with an
|> exception clause that says binary loadable modules do not have to be
|> under the GPL.
|
|Nope. No such exception exists.
|
|There's a clarification that user-space programs that use the standard
|system call interfaces aren't considered derived works, but even that
|isn't an "exception" - it's just a statement of a border of what is
|clearly considered a "derived work". User programs are _clearly_ not
|derived works of the kernel, and as such whatever the kernel license is
|just doesn't matter.
|
|And in fact, when it comes to modules, the GPL issue is exactly the same.
|The kernel _is_ GPL. No ifs, buts and maybe's about it. As a result,
|anything that is a derived work has to be GPL'd. It's that simple.
(and then goes on to discuss further his own personal opinion)
http://kerneltrap.org/node/1735
But you still misunderstand the fundamental problem, and this really
needs to be discussed with Red Hat legal.
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/
Powered by blists - more mailing lists