Difference between revisions of "Plug-ins"
(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 applica) |
m (more direct link) |
||
| (One intermediate revision by the same user not shown) | |||
| 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> | ||
| Line 10: | Line 10: | ||
===Status as of 2014=== | ===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.''"<ref>https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg02071.html</ref> | 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.''"<ref>https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg02071.html</ref> | ||
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
