Ross Walker wrote:
On Aug 18, 2010, at 10:43 AM, Bob Friesenhahn <bfrie...@simple.dallas.tx.us>
wrote:
On Wed, 18 Aug 2010, Joerg Schilling wrote:
Linus is right with his primary decision, but this also applies for static
linking. See Lawrence Rosen for more information, the GPL does not distinct
between static and dynamic linking.
GPLv2 does not address linking at all and only makes vague references to the "program". There is
no insinuation that the program needs to occupy a single address space or mention of address spaces at all.
The "program" could potentially be a composition of multiple cooperating executables (e.g. like
GCC) or multiple modules. As you say, everything depends on the definition of a "derived work".
If a shell script may be dependent on GNU 'cat', does that make the shell script a
"derived work"? Note that GNU 'cat' could be replaced with some other 'cat'
since 'cat' has a well defined interface. A very similar situation exists for loadable
modules which have well defined interfaces (like 'cat'). Based on the argument used for
'cat', the mere injection of a loadable module into an execution environment which
includes GPL components should not require that module to be distributable under GPL.
The module only needs to be distributable under GPL if it was developed in such a way
that it specifically depends on GPL components.
This is how I see it as well.
The big problem is not the insmod'ing of the blob but how it is distributed.
As far as I know this can be circumvented by not including it in the main
distribution but through a separate repo to be installed afterwards, ala Debian
non-free.
-Ross
Various distros do the same thing with patent/license encumbered and
binary-only pieces like some device drivers, applications, and
multimedia codecs and playback components. If a user wants that piece
they click 'yes I still want it'.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
