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: <9a8748490702160614u5f596d12yc98c2a5add9da7b3@mail.gmail.com>
Date:	Fri, 16 Feb 2007 15:14:16 +0100
From:	"Jesper Juhl" <jesper.juhl@...il.com>
To:	"v j" <vj.linux@...il.com>
Cc:	"Trent Waddington" <trent.waddington@...il.com>,
	"David Lang" <david.lang@...italinsight.com>,
	"Scott Preece" <sepreece@...il.com>,
	"Miguel Ojeda" <maxextreme@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: GPL vs non-GPL device drivers

On 16/02/07, v j <vj.linux@...il.com> wrote:
> > It's written in black and white, in the license.
>
> Please point me to where it says I cannot load proprietary modules in
> the Kernel.
>
http://www.gnu.org/licenses/gpl.txt
Section 2.b. :
"
    b) You must cause any work that you distribute or publish, that in
    whole or in part contains or is derived from the Program or any
    part thereof, to be licensed as a whole at no charge to all third
    parties under the terms of this License.
"

Linking with kernel exported symbols in a kernel module is by many
people considered creating a work derived from the kernel.


> >  Apart from that,
> > Greg KH has made his opinion clear, and you have said you understand
> > and don't debate that he holds this opinion, and his code is what you
> > said you were linking to (the sysfs/class stuff), so why do you keep
> > saying that "it is not clear".
>
> I know his opinion. I don't debate his opinion. It is his code. I
> choose not to use his code because of the license issue.
>
> > Do you think that, somehow, Linus' opinion trumps Greg KH's opinion on
> > his own code?
>
> No, just that the trend is disturbing. If enough Kernel Developers
> choose to write their Software in a way that prevents others from
> using it freely, then that is troubling.

They are not preventing people from using it freely **under the terms
of the GPL**.
If you want 'Free' as in 'I want to take this code and be able to do
whatever I want and never open up my source' then what you want is BSD
licensed code.
The freedoms granted you under the terms of the GPL are different -
they grant you the freedoms to run the code, to modify the code etc
but with a restriction that if you modify/derive from the code and
distribute the result you must also distribute your source.

There's actually nothing new here. The kernel has always[1] been under
a GPL license and anyone who wants to use/modify/distribute it have to
do so under the terms of the GPL.

The kernel modules are a little special.
It's quite obvious that a userspace program that simply uses kernel
provided system calls don't have to use the same license as the kernel
- they simply use services provided by the kernel but they don't
derive from it in any way.
The kernel proper is also quite obvious - if you modify internal code
in the kernel you are obviously modifying, and deriving from, the
kernel so if you distribute such changes you obviously have to
distribute your source as well as per the terms of the GPL.
Where all the controversy is at is kernel *modules*. It is not
entirely clear (in a legal sense) if kernel modules can be said to
derive from the kernel, so it's not entirely clear if they are bound
by the terms of the GPL or not. Court cases are needed to determine
that for certain.  One thing is quite clear however; and that is that
a lot of kernel contributors are of the oppinion that closed source
kernel modules are indeed illegal regardless of EXPORT_SYMBOL /
EXPORT_SYMBOL_GPL.  EXPORT_SYMBOL_GPL was simply introduced as a means
for those kernel developers to make their belief explicit - to be able
to tell the world that "I believe using this symbol makes your code a
derived work of the kernel and thus it has to be GPL", but that's all
it is, a message.  If the courts decide that linking with kernel code
in the form of a module makes the module a derived work, then
EXPORT_SYMBOL and EXPORT_SYMBOL_GPL are completely identical and all
kernel modules must be GPL licensed. However, if the courts decide
that a kernel module is not a derived work, then kernel modules may
only need to be GPL if they use EXPORT_SYMBOL_GPL'ed symbols or they
may not need to be GPL whatever they use - there's no way anyone can
know until there have been court rulings on the matter.

The simple fact is that nothing has actually changed with the
introduction of EXPORT_SYMBOL_GPL except that now those kernel
developers who think anything but GPL'ed modules are illegal can now
express that.


> Especially when these Kernel
> Developers are substituting existing interfaces in the Kernel with
> ones that are NEW and require specific licenses.
>
Depending on who you ask, the requirement for a specific license (GPL)
has always been there, it's just that people got a way to make that a
lot more explicit.



[1] Except the first very few versions that used a licence written by
Linus himself.

-- 
Jesper Juhl <jesper.juhl@...il.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html
-
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ