standards: Dynamic Plug-In Interfaces

1 
1 4.8 Standards for Dynamic Plug-in Interfaces
1 ============================================
1 
1 Another aspect of keeping free programs free is encouraging development
1 of free plug-ins, and discouraging development of proprietary plug-ins.
1 Many GNU programs will not have anything like plug-ins at all, but those
1 that do should follow these practices.
1 
1    First, the general plug-in architecture design should closely tie the
1 plug-in to the original code, such that the plug-in and the base program
1 are parts of one extended program.  For GCC, for example, plug-ins
1 receive and modify GCC's internal data structures, and so clearly form
1 an extended program with the base GCC.
1 
1    Second, you should require plug-in developers to affirm that their
1 plug-ins are released under an appropriate license.  This should be
1 enforced with a simple programmatic check.  For GCC, again for example,
1 a plug-in must define the global symbol 'plugin_is_GPL_compatible', thus
1 asserting that the plug-in is released under a GPL-compatible license
1 (⇒Plugins (gccint)Plugins.).
1 
1    By adding this check to your program you are not creating a new legal
1 requirement.  The GPL itself requires plug-ins to be free software,
1 licensed compatibly.  As long as you have followed the first rule above
1 to keep plug-ins closely tied to your original program, the GPL and AGPL
1 already require those plug-ins to be released under a compatible
1 license.  The symbol definition in the plug-in--or whatever equivalent
1 works best in your program--makes it harder for anyone who might
1 distribute proprietary plug-ins to legally defend themselves.  If a case
1 about this got to court, we can point to that symbol as evidence that
1 the plug-in developer understood that the license had this requirement.
1