Difference between revisions of "Plug-ins"
(→Status as of 2014: Work is in progress to further extend the plug-in interface.) |
m (more direct link) |
||
Line 2: | Line 2: | ||
<blockquote> | <blockquote> | ||
− | First, the general plug-in architecture design should closely tie the plug-in to the original code, such that the plug-in and the base program are parts of one extended program. (...) Second, you should require plug-in developers to affirm that their plug-ins are released under an appropriate license. This should be enforced with a simple programmatic check. (...) If a case about this got to court, we can point to that symbol as evidence that the plug-in developer understood that the license had this requirement. | + | "''First, the general plug-in architecture design should closely tie the plug-in to the original code, such that the plug-in and the base program are parts of one extended program. (...) Second, you should require plug-in developers to affirm that their plug-ins are released under an appropriate license. This should be enforced with a simple programmatic check. (...) If a case about this got to court, we can point to that symbol as evidence that the plug-in developer understood that the license had this requirement.''" (read [https://www.gnu.org/prep/standards/html_node/Dynamic-Plug_002dIn-Interfaces.html full text]) |
</blockquote> | </blockquote> | ||
Latest revision as of 09:19, 6 February 2014
Adding a plug-ins interface to a free software project can carry the risk that others will develop non-free plug-ins, thus reducing the free software project to a platform for a non-free application. This can be avoided by taking care as described in the GNU Coding Standards:
"First, the general plug-in architecture design should closely tie the plug-in to the original code, such that the plug-in and the base program are parts of one extended program. (...) Second, you should require plug-in developers to affirm that their plug-ins are released under an appropriate license. This should be enforced with a simple programmatic check. (...) If a case about this got to court, we can point to that symbol as evidence that the plug-in developer understood that the license had this requirement." (read full text)
GCC example
GCC has had a plug-in interface since 2009.
Status as of 2014
Work is in progress to further extend the plug-in interface.
In January 2014, Richard Stallman commented: "making available the symbol table (identifiers and their types) would not cause this problem [of proprietary plug-ins]. It just needs someone to write the code."[1]
External links
- Standards for Dynamic Plug-in Interfaces, from the GNU Coding Standards
- Plugins section of GCC Internals manual