Actually, this is already happing today, whenever dynamic
linking is used to load a propietary application and load it on
a GPLed operating system or whenever a propietary operating
system loads GPLed code.
The GPL allows you to ship propietary code and it allows a user
to link that code against GPLed code and use it - just not to
distribute it in certain situations. Nothing in the GPL prevents
you from providing a mechanism (a script for example) that
enables the user to do this linkage without requiring him to
know about what he is doing. And you may even provide such a
mechanism as part of the operating system. That's ld.so for you
(the same ld.so that is temporarily linking your statically
linked program against a propietary kernel or vice versa to
enable to use functions such as write(), open() and close()
without which it would be quite useless. Who cares about call
mechanisms - trap or jump, it is all the same).
Or look at what happened with Be: They may have infected part of
their system with GPLed code, but since that system is a highly
modular microkernel, this infection is not really relevant,
since the infected component is extremely self-contained. On the
other hand, it's disclosure is of almost no value to the Open
Source community without disclosure of the noninfected rest of
the operating system.
Kristian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html