GPL - Writing an exception for a plugin interface under section 7 of GPLv3

Question

The problem

I've written a application for Android licensed under GPLv3 which needs to use Google Play Services, a proprietary library, as a plugin to the app.

Now I'd also like to add libspotify as a plugin.

For all of the proprietary libraries used I'm providing alternative open source plugins but they are not as good as the proprietary ones, not even close.

The user should then be free to disable all proprietary parts either at compile or runtime.

Possible solutions

The GPLv3 has a section "7. Additional Terms." under which you can add a "classpath" exception. I'd like to use this exception to do the following.

The idea of a classpath exception is explained in the GPLv3 FAQ here:

• Linking over a controlled interface: http://www.gnu.org/licenses/gpl-faq.html#LinkingOverControlledInterface

• http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs

The basic idea

Implement these interfaces:

interface Plugin {}

interface ProprietaryPlugin extends Plugin {}

interface XYZ_1 extends Plugin {
    public void someHook();
    public void someOtherHook();
    ...
}

interface XYZ_2 extends Plugin {
    public void someHook();
    public void someOtherHook();
    ...
}

XYZ_3, 4, ...

The above interfaces are part of the project and are under GPL.

But I'd like to let all code that extend some subinterface of Plugin except ProprietaryPlugin to be able/allowed to be proprietary given that they mark themselves as ProprietaryPlugin.

My intention is to make tight plugin hooks that all proprietary plugins must follow and a way to indicate to the user which plugins that we can remove at runtime.

Also, I want the "bridge" code, the implementation of the plugin interfaces to be open source and under a GPLv3 compatible license. And the source code must provide at least one GPLv3 implementation, hopefully creating a concrete wall between the GPLv3 and proprietary code.

Visual explanation

Is this possible to do? I know that most guys here are not lawyers, but I find asking developers first enlightening.

A suggestion from irc.gnu.org#gnu

The guys at irc.gnu.org#gnu gave me the following suggestion: https://raw.github.com/qcad/qcad/master/gpl-3.0-exceptions.txt

It states that:

As a special exception, the copyright holders of QCAD hereby grant permission 
for non-GPL compatible plug-ins and script add-ons to be used and distributed 
together with QCAD, provided that you also meet the terms and conditions of the 
licenses of those plug-ins and script add-ons.

Is "non-GPL compatible plug-ins and script add-ons" vague / a loophole, or is it clear and does it apply to my case?

A second suggestion

I got a second suggestion at #gnu: http://roundcube.net/license/

It states that:

This file forms part of the Roundcube Webmail Software for
which the following exception is added: 
Plug-ins and Skins which merely make function calls to the Roundcube Webmail Software,
and for that purpose include it by reference shall not be
considered modifications of the software.

If you wish to use this file in another project or create a modified version that will 
not be part of the Roundcube Webmail Software, you may remove the exception above and 
use this source code under the original version of the license. 

What do you think about this one?

My attempt at a "classpath exception"

My first idea was to add the classpath-exception to Plugin with something like the following... does it accomplish my intent or is it filled with loopholes, etc.?

Additional permission under GNU GPL version 3 section 7

0. Definitions

"FSF" means the Free Software Foundation, Inc.

"Compatible License" means any license the FSF 
considers to be compatible with the GNU GPL version 3.

"Plugin interface" means any interface definition file in the Corresponding Source
containing - in the file's header - the words 
"The licensors of this Program designates this particular file as a Plugin interface"

"Proprietary interface mark" means any interface definition file in the Corresponding Source
containing - in the file's header - the words 
"The licensors of this Program designates this particular file as a Proprietary interface mark""

"Allowed library" means any library that is linked or combined with this Program,
 or any covered work that creates a derivative work of a 
subinterface of a Plugin interface not directly linking with the library.
Such a subinterface provides at least the source code 
of one working implementation licensed under This License.
The derivative work of the subinterface linking to the 
Allowed library implements a Proprietary interface mark.
Such a derivative work is referred to as a "Proprietary plugin implementation".
A Proprietary plugin implementation is licensed under a Compatible License.

1. Exceptions

If you modify this Program, or any covered work, by linking or combining it 
with any Allowed library (or a modified version of those libraries),
containing parts covered by the terms of those libraries, the licensors of this
 Program grant you additional permission to convey the resulting work.
{Corresponding Source for a non-source form of such a combination shall include
 the source code for the parts of any Proprietary plugin implementation
used as well as that of the covered work.}

Answer 1

I don't think you can do what you are trying to do. And you would be well advised to contact the FSF or an attorney specializing in intellectual property.

If you look at the FSF FAQ on the GPL and Plugins, they have some relevant comments for your situation.

It depends on how the program invokes its plug-ins. 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.

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 the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed.

If the program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.

---

I don't think your program is going to fall into the first case of using fork or exec. If it did, then you wouldn't have any issues. It's more likely that your program falls into the third category with dynamic linking. But it's not a good sign when the FSF tells you that you're in a gray zone. When it comes to the GPL and the copyleft, you want clear-cut answers.

The key for FSF's determination seems to be this phrase:

If the program dynamically links plug-ins, and they make function calls to each other and share data structures ...

which is repeated in another FAQ answer. If I had to guess, I suspect your program is going to share data structures and the two components (your application plus the plugin) will be making function calls to each other. And it that's the case, then you're squarely within their second example and the plugins will need to be licensed as GPL or a GPL-compatible license.