GPL и «закрытый» модуль

нет, модули ядра подпадают под действие GPL -> могут распространяться под своей лицензией, но код должен быть открыт [доступен].

// wbr

Интерфейс связи модуля с модифицированной программой?

Если это через /proc или /dev, то проблем, думаю, не будет, достаточно распространять модуль отдельно от проги. А в документации к проге дать ссылку и описание.

> нет, модули ядра подпадают под действие GPL -> могут распространяться под своей лицензией, но код должен быть открыт [доступен].

Да ты что? И где взять код карточек нвидии и ати?

к nvidia - в пакете драйвера есть исходный код модуля ядра

Детсад, блин. Выходит, нвидийный ядерный модуль раздаётся по лицензии GPL? Если кто не видел, "исходный код" модуля ядра состоит в основном из файла nv-kernel.o, а в README написано так:

Since the Linux kernel does not support a binary driver interface for use by kernel modules, NVIDIA maintains a thin interface layer that can be built against supported Linux kernels and linked with a closed source, kernel independent component into a loadable NVIDIA Linux kernel module.

Интерфейс через /dev, но правда там еще и звук через alsa сделан.

klalafuda, ты ошибаешься

> klalafuda, ты ошибаешься

внимательно читаем содержимое файла COPYING и коментариев к ним от комрадо Торвальдса COPYING.modules в корне с исходниками ядра. например:

--- cut ---
Date: Wed, 3 Dec 2003 16:00:21 -0800 (PST)
From: Linus Torvalds <torvalds@osdl.org>
To: Kendall Bennet
cc: linux-kernel@vger.kernel.org
Subject: Re: Linux GPL and binary module exception clause?

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.

Now, the "derived work" issue in copyright law is the only thing that
leads to any gray areas. There are areas that are not gray at all: user
space is clearly not a derived work, while kernel patches clearly _are_
derived works.

But one gray area in particular is something like a driver that was
originally written for another operating system (ie clearly not a derived
work of Linux in origin). At exactly what point does it become a derived
work of the kernel (and thus fall under the GPL)?

THAT is a gray area, and _that_ is the area where I personally believe
that some modules may be considered to not be derived works simply because
they weren't designed for Linux and don't depend on any special Linux
behaviour.

Basically:
- anything that was written with Linux in mind (whether it then _also_
works on other operating systems or not) is clearly partially a derived
work.
- anything that has knowledge of and plays with fundamental internal
Linux behaviour is clearly a derived work. If you need to muck around
with core code, you're derived, no question about it.

Historically, there's been things like the original Andrew filesystem
module: a standard filesystem that really wasn't written for Linux in the
first place, and just implements a UNIX filesystem. Is that derived just
because it got ported to Linux that had a reasonably similar VFS interface
to what other UNIXes did? Personally, I didn't feel that I could make that
judgment call. Maybe it was, maybe it wasn't, but it clearly is a gray
area.

Personally, I think that case wasn't a derived work, and I was willing to
tell the AFS guys so.

Does that mean that any kernel module is automatically not a derived work?
HELL NO! It has nothing to do with modules per se, except that non-modules
clearly are derived works (if they are so central to the kenrel that you
can't load them as a module, they are clearly derived works just by virtue
of being very intimate - and because the GPL expressly mentions linking).

So being a module is not a sign of not being a derived work. It's just
one sign that _maybe_ it might have other arguments for why it isn't
derived.

Linus
--- cut ---

-> so в принципе, все не так однозначно. но проблемы с binary only модулями вполне могут иметь место и в случае чего придется доказывать свое право на binary only distribution.

// wbr