views:

339

answers:

5

I'm working on a C++ gStreamer 'like' engine that, at some point in the future, I'd like to make some money out of (wouldn't we all!). After many hours reading up on the GPL licence, I still can't find a real answer to the implications of 'supporting' a plugin that is covered under the GPL.

Since I'm only producing an engine that does not actually require the GPL'd plugin to work, I'm guessing my code is not covered by the GPL if the plugin is only used by the end-user?

i.e I don't supply the plugin, only the framework to allow it to be used.

+1  A: 

You'll have to talk to your lawyer.

But as a non-lawyer, I'm inclined to say that the GPL will not affect your code if someone produces and distributes a GPL'd or LGPL'd plugin for it, since it's not a derivative work, nor part of your standard distribution.

greyfade
+2  A: 

Why don't you e-mail [email protected] and ask them? The Free Software Foundation (who are the stewards of the GPL) would be the best authority on this, since they wrote the license. You can also try contacting the SFLC, but I'd try the FSF first.

Some things to include in your e-mail:

  • Is your engine going to be licensed with a license that is compatible with the GPL? If the answer to this is no, don't bother contacting them. If yes, indicate which license.
  • Is the license for the library/API to interface with your engine going to be GPL compatible? Will you require static linking, or other things that result in a combined work?

Try to be as descriptive as possible without writing a book about everything that your program will do.

Again, if you wish to make your program non-free, you'll be better off talking to a lawyer. If your core engine uses an OSI approved license, the FSF will likely help you to understand any possible hassles / entanglements.

If plug-ins can be distributed independently of your core engine and the library used to interact with your core engine is GPL compatible, you'll probably be OK. However, IANAL, they are, try contacting them.

EDIT:

Make sure you remain the SOLE copyright holder to the engine. This allows you to use a dual licensing scheme. Projects such as the Cherokee web server have employed this with great success, not to mention MySQL AB. A quick Google search on copyright sign-off should turn up all you need to know.

Your business model appears smart, asking questions this early makes it seem smarter. If your product is good, you'll do well :)

There are some fundamentalists that argue about dual licensing, most of them have rather high paying jobs and aren't supported by the code that they produce. Using an OSI approved license for your core helps your neighbor as well as your wallet. In this day and age, that's as good as its going to get.

Tim Post
Thanks for the e-mail address. I'm thinking that the engine will start open (as a framework) and then I'll try and make some money out of it.
James Fisher
@James You'll make some money, just ensure you are the sole copyright holder to the engine. I'll update my post as such.
Tim Post
+3  A: 

The usual IANALBMGI (I am not a lawyer but my girlfriend is) disclaimer.

However, I find this quite interesting and would like to speculate a bit.

You can draw a parallel to the commercial/non-open-source applications and frameworks that allow people to write plug-ins and add-ons. E.g., Internet Explorer, Adobe Photoshop, Microsoft Visual Studio, Microsoft Office, etc, etc.

You can't really force them to adopt any other license by simply releasing a GPL:ed plug-in/add-on for their application/framework.

So I would say that as long as you don't include any GPL:ed source code in your framework you wouldn't need to worry about what licenses your users are using. As you say, your code it is not a derivative work of any GPL:ed code.

UPDATE: Please take a look at Is it legal way to get use gpl code in close source application through plugin for further useful information and clarifications.

Subtwo
This was my line of thinking too, but GPLv3 does try and cover linked objects (both static and dynamic), but just ends up being more confusing.
James Fisher
This scenario really has nothing to do with linking objects, but rather what is to be considered derivative work. It would be like saying that you can't write GPL(v3) programs for Windows because it does not have a compatible license!?
Subtwo
Reading GPLv3, it does try to say that even if you use dynamic linking of GPL'd objects, you must use/follow the GPL. What's not clear is the whole 'plugin' area, hence the original question.
James Fisher
The key point is that it is not YOU who are using dynamic linking of GPL'd objects to implement your functionality. It is the users of your framework who are doing the "linking". It would be a completely different thing if you shipped your framework with said plugins...
Subtwo
A: 

If your app does not use any code or libraries licensed under the GPL (or LGPL in some circumstances) and is not itself licensed under the GPL or LGPL, then you have nothing to worry about.

anon
+2  A: 

Your application does not ship under the GPL terms. Therefore, you are not bound by it. You may allow (at your discretion) anyone to dynamically link to your application, and set the terms for that.

If one of such conditions for plugins is that they are GPL-licensed, that still does not impose a condition on your program. It's a condition on the plugin. You do not need to dual-license the program at all.

Remember that GPL works within the copyright regime. It only works because it allows some things disallowed under copyright. It does not add extra restrictions at all. Copyright law does not prevent you from exposing a plugin API, so the GPL doesn't prevent it either.

A good comparison is Linux, a GPL v2 operating system. It offers an API for programs to run within the Linux environment. Linux allows you to use any license you prefer for the program, but that does not change the license on the Linux environment. That remains GPL v2.

MSalters