So I wrote this up the other day with the intent of posting it somewhere near the FSF to encourage a discussion. I couldn’t find a forum that was freely accessible (ironically), so instead of deleting it, I thought I would share it with you. This is LONG, but I hope it is worth reading.
The current GPL text is unclear whether the communication between plugins (audio, video, photo, web) and host programs (music production, video/photo editing, browsers) is sufficiently “at arms length” for the two to be considered separate “programs”.
This raises a question that potentially affects a very large number of plugin and host developers: Does the “aggregate” term apply to plugin/host combinations, or does the technical process of dynamic linking dictate a “combined work” relationship?
In the audio production world, for example, it is common practice that audio plugins and hosts are dealt with as independent entities, because there are thousands of plugins and possibly hundreds of hosts that are freely interoperable and replaceable with each other, thanks to a standardized third-party API (VST, AU, etc). No plugin is tailored to a specific host, and vice versa.
It is worth noting that, at the user’s choice, multiple host programs typically have access to and interoperate with all plugins installed on the same computer. A host can run fine without any plugin, but plugins can’t accomplish anything without a host (unless there’s a standalone version).
An example: Does loading a Photoshop plugin really turn Photoshop into a “combined work” derived off of the plugin? Does this curtail the rights of users to freely use, modify, share, etc. the code of the plugin? Isn’t it actually the other way round: The plugin only makes sense because there’s a Photoshop API in the first place? Wouldn’t this actually make the plugin a derived work off of Photoshop?
It should be noted though, that the Photoshop API is different from the audio world, in that there is only a single “host” available for it (to my knowledge), while for audio hosts there is plenty choice.
At the core of this question are standardized plug-in APIs (VST, AU, AAX as examples for audio plugins) that effectively work more similar to a network protocol, rather than a specific linkage between two parts. It’s the third-party API that enables the free interoperation and arbitrary replacement, not unlike the PCIe standard for expansion cards.
The standardized API ensures the freedom of users to combine plugins and hosts of their choice, while no host is dependent on any specific plugin, or the other way round. IMO, this makes plugins and hosts communicate sufficiently “at arms length” in order to be covered by the “aggregate” condition.
In fact this is even more “at arms length” than, for example, the external execution of ffmpeg by a video converter app through the command line: The video converter depends on ffmpeg. It can’t accomplish much without it.
Conclusion:
In regard to the definition of “at arms length” and “aggregate”, the GPL license should address and clarify the role of standardized APIs and where the line is between free “plug and play” interoperability and program-specific linking.
It seems highly unlikely that a developer intended a plugin to be used exclusively with GPL hosts only. This would be contrary to the purpose of a plugin, especially in the audio world, where the most widely used hosts are non-GPL.
Going LGPL with plugins would probably not be necessary, if this point was stated clearly enough in the GPL terms.
GPLv4 anyone?
