Audio plugins are usually erivateistributed as dynamic libraries. But what about GPL and dynamic linking? Is a plugin part or derivative work of host or vice versa? In what situation the plugin is part of host and when not? Well this is quite a topic. Lets discuss that! And I recall that IANAL!

Problem of derivative works

FSF opinion is provided at GPL FAQ:

Does the GPL have different requirements for statically vs dynamically linked modules with a covered work? (#GPLStaticVsDynamic)
No. Linking a GPL covered work statically or dynamically with other modules is making a combined work based on the GPL covered work. Thus, the terms and conditions of the GNU General Public License cover the whole combination. See also What legal issues come up if I use GPL-incompatible libraries with GPL software?

In article Sticks, Stones and the GPL Phil Albert comments:

Forgive me if I repeat myself. Eben Moglen’s interpretation of the GPL, regardless of how good a lawyer he is, means nothing for GPLed works not owned by the FSF, Moglen or his other clients.

No matter how good a legal document purports to be, interpretation is almost always necessary because of the limitations of language and the inability to predict all possible uses of a legal document. Don’t take my word for it. Even Richard Stallman and Linus Torvalds disagree on the exact interpretation of the GPL when it comes to derivative works and dynamically loaded kernel modules.

Which is actually true. In GPL paragraph 1. there is:

a. ‘work based on the Program’ means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language.”

This is a very important note “under copyright law”. The FSF point of view is irrelevant (unless the program is GNU). In wikipedia article about GPL there are mentioned different views how derivative work can be defined:

• Point of view: dynamic and static linking violate GPL (Richard Stallman)
• Point of view: static linking violates GPL but unclear as of dynamic linking (Linus Torvalds)
• Point of view: linking is irrelevant

Our main question is about linking open-source – GPL – plugin into commercial, thus proprietary, closed-source, non-free, non-GPL host. Wikipedia agrees:

This key dispute is whether or not non-GPL software can legally statically link or dynamically link to GPL libraries. Different opinions exist on this issue. The GPL is clear in requiring that all derivative works of code under the GPL must themselves be under the GPL. Ambiguity arises with regards to using GPL libraries, and bundling GPL software into a larger package (perhaps mixed into a binary via static linking).

GPL FAQ speaks about plugin to non free program this way:

Can I apply the GPL when writing a plug-in for a non-free program? 
If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them. So you can use the GPL for a plug-in, and there are no special requirements.
If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means that combination of the GPL-covered plug-in with the non-free main program would violate the GPL. However, you can resolve that legal problem by adding an exception to your plug-in’s license, giving permission to link it with the non-free main program.

Once more, definition of derivative works defines copyright law. Howewer as a first author of the plugin you can give an exception or releasing plugin under LGPL. But what about using other GPL code in our plugin? It seems that FSF’s use case considers only program specific plugins – in this case all makes sense. In case of audio plugins however situation of defining derivative work can be different.

Audio Plugins

Victor Lazzarini sent a question to Linux Audio Developers mailing list:

A simple question: can GPL plugins be loaded into non-free hosts? This may appear a stupid question, but given the fact that non-free code can’t link to GPL binaries, what is the story with dynamic modules?

This is one of many answers. This one by Paul Davis (author of Ardour):

the key distinction is that plugin APIs generally have a definition that is independent of any particular host. there are exceptions for a few hosts that provide their own plugin API (Note of article author: this would be AAX). but in general, something like VST or LADSPA or AudioUnit or LV2 cannot be said to be related to any host or plugin in particular.

This means that the host or plugin is undoubtedly a derived work of the plugin **API**, but its very hard to argue that the host or plugin is a derived work of the other, at least not when they are distributed independently and the host shows no reliance of any kind on the plugin. If you can load a plugin into Ardour and you can load the same plugin into Logic, its pretty hard to argue that the plugin is a derived work of Ardour or Logic. The most hosts a plugin can be loaded into, the more clearly this lack of derivation becomes clear.

On the other hand, if you could only use a particular host if you have a particular plugin available, and the host is distributed in a way so as to automatically load that plugin, then I think that even if the relationship between them is based on a 3rd party plugin API, one could quite easily argue that the host is a derived work of the plugin, in the FSF/GPL sense.

And he continues:

but i think, in fact, i ADAMANTLY believe that run-time linking of an object module as a result of explicit user action (i.e. not part of the predestined lifetime of the process) is semantically distinct from dynamic linking. put another way, if you cannot look at the executable and determine that it will link a particular object module during its lifetime, it is very, very hard for me to see how the plugin can be considered a derivative work
of the host (assuming the APIs are not host specific etc etc etc). if the host will run and function normally whether or not the plugin is present, its very hard to see how the host can be a derivative of the plugin.
The idea that because a particular host can load my plugin, my plugin becomes a derivative work of that host is frankly just absurd. Which license would a VST plugin fall under, given that it can be loaded into Ardour, Cubase, Sonar or Samplitude? Which host is it a derivative of? If I write a GPL’ed VST plugin (they do exist), at what point does the run time linkage change the licensing of either the plugin or a host that loads it?

Fortunately Audio Units are part of operation system.

As part of Core Audio and being integral to OS X, audio units offer a development approach for audio plug-ins that excels in terms of performance, robustness, and ease of deployment. With audio units, you also gain by providing a consistent, simple experience for end-users.

Audacity has no problems of including Audio Units because of that.:

For those who don’t know, Audio Units are Apple’s Mac-only answer to VST plug-ins. Now that most plug-in developers have switched over to AUs, there’s little reason to support VST on the Mac anymore – the VST plug-in enabler was just a hack and it never worked very well. AUs can have really slick custom UIs, and when they don’t, Apple provides a very nice “default” UI. There’s also no legal reason not to include this code directly in Audacity, since Audio Units are part of the operating system.

That is what Apple documentation says:

In iOS and in OS X, host applications use functions in Audio Unit Services to discover and load audio units.

Audio Units are instantiated using Core Audio:

Because audio units are Component Manager components, a host application must call the Component Manager to load them.

Conclusion

Talking about VST it is actually clear that as a first author you can provide exceptions for VST SDK and linkage to host – situation is clear. The second exception is not probably needed when using LGPL. However when using other GPL libraries situation can get tricky. But it is obvious that FSF view on derivative/linkage topic according to audio plugins with public API is not so appropriate and even among open source community there are different views how linkage and derivative works are connected. It seems that FSF’s use case considers only program specific plugins – in this case all makes sense. At this point of view after all points being discussed it seems to me to be appropriate that GPL audio plugins do not violate their licence when they are distributed separately and when they are not automatically loaded to host. And argumentation that in the time of run-time linkage the host and plugin became a one program is almost the same as that the plugin at that time becomes part of operation system. But you still need exception for VST SDK for your 3rd party GPL code.

In case of Audio Units situation can be much clearer since AU as part of Core Audio is integral part of operation system. However, I am not a Core Audio expert in any way. But if anybody is not convinced, currently exists at least 2 GPLed hosts which can load AU: Ardour and JUCE Host. Since Garage Band is free and is provided by Apple it could be also considered as a part of OS. There is no doubt then that it is user’s choice whether he/she doesn’t want to load plugin to proprietary host. Since GPL main focus is on distribution developer is out of this problem.

PS: The last argument is also relevant for Windows and VST (Audacity, LMMS, etc)

Tom. Developer and Musician. The man behind Virtual Analogy and its products.