Cisco Cisco IPICS Dispatch Console Licensing Information

So these days, we export many internal interfaces, not because we don't

think that they would "taint" the linker, but simply because it's useful

to do dynamic run-time loading of modules even with standard kernel

modules that _are_ supposed to know a lot about kernel internals, and are

obviously "derived works"..

 

> However we disagree that a plug-in for a GPL'd program falls

> under the GPL as asserted in the GPL FAQ found in the answer:

> http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins.

 

I think you really just disagree on what is derived, and what is not.

Richard is very extreme: _anything_ that links is derived, regardless of

what the arguments against it are. I'm less extreme, and I bet you're even

less so (at least you would like to argue so for your company).

 

> My assertion is that plug-ins are written to an interface, not a

> program.  Since interfaces are not GPL'd, a plug-in cannot be GPL'd

> until the plug-in and program are placed together and run.  That is

> done by the end user, not the plug-in creator.

 

I agree, but also disrespectfully disagree ;)

 

It's an issue of what a "plug-in" is - is it a way for the program to

internally load more modules as it needs them, or is it _meant_ to be a

public, published interface.

 

For example, the "system call" interface could be considered a "plug-in

interface", and running a user mode program under Linux could easily be

construed as running a "plug-in" for the Linux kernel. No?

 

And there, I obviously absolutely agree with you 100%: the interface is

published, and it's _meant_ for external and independent users. It's an

interface that we go to great lengths to preserve as well as we can, and

it's an interface that is designed to be independent of kernel versions.

 

But maybe somebody wrote his program with the intention to dynamically

load "actors" as they were needed, as a way to maintain a good modularity,

and to try to keep the problem spaces well-defined. In that case, the

"plug-in" may technically follow all the same rules as the system call

interface, even though the author doesn't intend it that way.

 

So I think it's to a large degree a matter of intent, but it could

arguably also be considered a matter of stability and documentation (ie

"require recompilation of the plug-in between version changes"  would tend

to imply that it's an internal interface, while "documented binary

compatibility across many releases" implies a more stable external

interface, and less of a derived work)