Interfacing with GPL applications from MIT licensed code - is a dual-license unavoidable?

Question

I know this is going to be long but I felt like I needed to explain the whole situation and my concerns in detail. Thanks in advance for reading and answering this question!

I'd like to write an application that depends on GPL licensed libraries or applications. However, I'm not keen on licensing my own code under GPL alone because I think it's too restrictive. Instead I would prefer choosing MIT/BSD-license for my own code, but the modules interfacing with GPL code give me a headache. They are accessed either by linked libraries (where GPL definitely applies) or just piped as a frontend to STDIN/STDOUT/STDERR to control the GPL application. (To be more specific: It's going to be an audio player/collection using xine-lib, mplayer and VLC as backends for playback; mplayer --slave and vlc -I rc enable control through pipes, xine-lib needs to be linked against.)

AFAIK GPL2 allowed interfacing with other licensed code through a hole in that license. Therefore AGPL and later GPL3 introduced some clause that defines any interaction (through a web service for example) to be also covered by (A)GPL. If I understood it correctly, I should be fine interfacing through command lines or pipes with GPL2 (but not GPL3) licensed applications. Unfortunately most projects did not fix the GPL version but instead left the notice "or [...] any later version" in their license, so this could become a dead end sooner or later if the projects change to GPL3.

MIT license includes the right to "sublicense" as long as you keep the original copyrights and permission notice. (see license)

Considering all that above, I see 4 options:

1. License everything just MIT - GPL should "automatically" sublicense where needed. However I should include some warning somewhere in my code and I need to display the GPL license + disclaimer in some "about" dialog if the interfacing modules are used. In fact, I am already dual licensed at that point, except I don't have to include GPL into my code but just the compiled application.
2. License my interfacing modules GPL, all the rest MIT - if GPL applies it should (from a legal point of view) automatically apply a more restrictive sublicense to my MIT code and I don't have to care about anything (except displaying license text and disclaimers in some "about" dialog or similar; well I should probably do the same in 1st case)
3. Dual-license my project MIT/GPL everywhere except for interface modules that need to go GPL exclusively. GPL is safe, I have my non-interfacing code separated under MIT and can use both. Shouldn't be a problem, but dual-licenses are generally considered "bad style"? I consider relicensing MIT licensed code to GPL nonsense except for the legal perspective.
4. License everything GPL2. I wouldn't choose that last option unless it's really necessary. It's sad because I would be stuck in the GPL grave but shouldn't have much negative effects on an audio player frontend. I'd like to fix the version to GPL2, not 3 - is it possible that I run into any incompatibilities between those two versions at some point?

Long story short, my questions are basically:

1. Can I use GPL code in MIT code without having to (dual-)license everything that's not interfacing directly? (Unfortunately GPL would apply transitive, so if I use some module to interface with GPL, it infects all code at once, no matter if it's a module or not, even if it's just some very far away part of my application?)
2. Can I write a frontend to a CLI or pipe interface to a GPL2 (and 3?) application under some other, less restrictive license than GPL, such as MIT?

My point is that I want to release an application depending on restrictive but free code that - itself, without the restricted modules - would be even less restrictive, more free than the original code. Since I only interface to it I am binding to GPL code but I am not modifying it. I would pass responsibility for checking legal compliance of my modules to anyone who is to relicense or fork the tricky parts of my code (should apply only to the backend interfaces).

On distribution I would either

• not include GPL dependencies at all (user needs to install xine-lib/mplayer/VLC himself) or
• include GPL dependencies with a separate install routine displaying all license information.

I should be safe on that side.

The big question remains:

Can I avoid dual-licensing on code level and which of the above licensing options are not permitted?

I know that FFMPEG determines whether it's GPL or LGPL on compile time from the list of selected modules; maybe my case can be compared to FFMPEG? My application is going to be implemented in Java and distributed as a JAR file whereas the interfaced applications/libraries are written in C if that changes anything to my situation. (only for xine-lib I use real bindings from libxine-java)

Edit: Maybe it wasn't clear enough that I can separate backend classes into different modules. All backends implement the same interface class which resides in the main module. An interface class does not contain any code, so this part could also be dual-licensed. The particular backend implementation however is some tiny subproject and may be compiled into a separate JAR so it is only linked into code base at runtime. That's why I mentioned Java at the end of my question and compared my case to FFMPEG. However, these JARs should ship together with some notice and license information to their particular parts on first use or installation (like FFMPEG does on compile time). All interfaced projects will be properly credited including a small reference to their license (named/linked). They are not included in the standard distribution so I do not bundle it. (bundles go GPL by dual or sublicense if needed) Modules can be optional, so if xine-lib is the only problem but mplayer and VLC are not, this should not enforce GPL globally.

Maybe there are any cases of other frontends that had the same issue?

Edit 2: Yet another idea: Can the main code base be MIT and at runtime change its license according to the active backend (all of which have the respective license they are interfacing with)? Distribution would need to contain a proper notice, that the player is a changeling and dynamically sublicenses from MIT as the broad base to some other OS license (GPL2/3) as needed and back to MIT or something else if the backend module is being switched. This should be possible with MIT? (After all, MIT permits more rights.) However, this is kind of absurd since I simply could have dual-licensed the code from the beginning (MIT would be distribution/runtime specific and may only apply to the main codebase without backend classes).

Answer 1

I would shun GPL code since it sounds as restrictive as many closed source licenses. BSD license is much more flexible, and can even be profitable. Look what Apple has been able to do with OS X.

Answer 2

As long as you own the copyrights to all the code in your project, there's nothing stopping you from releasing your whole project as dual MIT and GPL licensed. Dual licensing means that your users get a choice of what license to take your code under (so you're not restricting them at all - actually just giving them more options than straight-MIT-licensed).

The GPL code you're linking to just says "you have to let your users have the option of licensing your code under GPL". That's satisfied by a dual-license.

What would stop you from pursuing a dual license was if you had actually pasted slabs of GPL code into your project, since you couldn't re-license that code to people as MIT.

Make sense?

EDIT: See here

Answer 3

IANAL.

1) You cannot relicense code you did not write. Anything that's GPL has to stay GPL, ownership intact; same with MIT-licensed code.

2) Any changes you make to third-party code should use the same license as the original. Maintain these in the form of patches. Submit them upstream; matching licenses will make it much easier for them to be accepted.

3) To prevent viral effects on your own code, treat problematic third-party projects as discrete black-box entities. Write bare-bones wrappers (GPL-licensed) instead of linking against GPL libraries. Interact with these components solely via files, pipes, IPC, etc.

4) If you follow the above rules, any other code that you write can be licensed as you see fit.

A release is a collection of code which can be subject to multiple licenses. OS X is a great example: a collection of proprietary code, BSD/MIT code, and GPL code. Their docs have the phrase "Portions of this system are distributed under the [blah] license".

Your overall release must abide by the terms of all licenses. Your startup screen, about screen, and/or docs must contain relevant disclaimers and notices for all applicable licenses. If you are (re)distributing GPL code in binary form, you must provide links to or copies of the GPL source.

There is no need for the complications of runtime, dynamic, or even dual licenses as long as your program and code are structured such that there is no license cross-pollution.

Answer 4

You can put all code you write under any license you want.

When you distribute your code linked to GPL code, you have the obligation of also putting your code under the GPL (or a compatible license). Dual licensing is perfectly fine, as the recipient can choose to ignore the non-GPL license. They can also choose to ignore the GPL, e.g. if they prefer your MIT license.

You can safely distribute your own code under a non-GPL license, even if that has a command-line interface to a GPLv2 application. There is no risk involved in that application going to GPLv3. At that point, the command-line interface is shared by the GPLv2 and GPLv3 forks of the application. Since it's shared, the GPLv3 fork cannot claim "exclusive ownership" of that interface, if such a principle could even be recognized in your jurisdiction.

Answer 5

Actually I found a seemingly complete official note about my issue on FSF's website while searching for something else.

There is a list of GPL compatible licenses that also approves MIT (X11) license as "compatible". Their FAQ explains what that means:

It means that the other license and the GNU GPL are compatible; you can combine code released under the other license with code released under the GNU GPL in one larger program.

All GNU GPL versions permit such combinations privately; they also permit distribution of such combinations provided the combination is released under the same GNU GPL version. The other license is compatible with the GPL if it permits this too.

GPLv3 is compatible with more licenses than GPLv2: it allows you to make combinations with code that has specific kinds of additional requirements that are not in GPLv3 itself. Section 7 has more information about this, including the list of additional requirements that are permitted.

As far as I understand this, it approves that I may even use my first option "License everything just MIT". However, if I distribute GPL licensed code along with it, I need to sub-/relicense my code as GPL of the same version. Since MIT allows that silently, it would work without dual-licensing my project's source code; placing the license note into the binary would be sufficient.

I would place a note about that topic in my source file headers or some file explaining that issue. Also, licensing my interfacing classes explicitly as GPL could help to avoid later confusion on compile or run time and may even toggle some license flag to automatically "downgrade" to the correct license on binaries (if not always shown). That way I would make clear that the main code is no longer MIT when compiled/distributed.

Separating the compromising sections of my codebase into modules helps avoiding GPL even further.

So I think I can answer my own question with "Yes, I can avoid dual-licensing my source code." (because GPL sublicenses my code silently on linking although it may cause confusion) and "all licensing options are valid" (because I distribute in modules; provided that each module has the correct license - if not bundled with or containing parts of GPL code like messages to search for in STDOUT, MIT license should be sufficient).

Also, when using modules not being shipped with the official release, it's up to the user to show a proper sublicense on (re)distribution of that bundle, even if the original codebase still shows "MIT" as the sole license in its about dialog etc. Basically there would be no need to mention that it needs to be downgraded to GPL in that case.

Answer 6

If GPL is too restrictive for you why not just release it under LGPL?