GPL, LGPL licencing [closed]

Question

My application uses 2 libraries (not modified). First one is under GPL and second one under LGPL. This means that my application needs to be released under GPL and LGPL because both libraries will be shipped along with my application. That's fine. Now, application exposes plugin infrastructure so anyone can write plugins for it. Plugins will not be able to communicate directly with those 2 libraries mentioned at the start of the text because they have no idea what is behind application. Plugins will not be shipped with application. Users will be able to choose which plugin they want to install from open/public plugin list thru application.

Questions:

1. Will plugins also need to be released under GPL?
2. Is there any way to release some plugins under closed source code licence? Which one?
3. What would be the best licence approach to prevent companies to write plugins that are free on the client (application) side and not free on the server side without commercial licence? (plugin calls web service that charges for service usage). In this case i would like company to pay some fee as in one hand this goes to commercial usage. For instance/example, someone has a web service that converts images between various formats. That someone writes plugin that requires user account information ( login ). Plugin connects to his web service, authenticates, convert image and charge user account for some amount. In this example plugin is free for installation and usage. It's users choice will he use it completely or not.

Is something like this possible?

Thanks.

Answer 1

1. Is a hot debate. Specifically, if the API the program provides serves to forward calls, plugins do basically logically depend on said library, and thus are considered by some to be bound by GPL. At the very least one has to reasonably establish that said plugins can function on "their own"/"independently" and do not depend on the code - from a legal point, not a technical one. Hard to formulate, IANAL, and so on, best practice is not to stay in gray areas; better release code: that is cheaper than a lawyer, and keeps users happy too.

2. If said plugins are reasonably independent of the library used (see point 1), you may choose any license of your liking.

3. You cannot realistically stop someone from writing a plugin for your program that interfaces with a non-freebeer service. You may prevent users from using such plugins by using technical measures such as digital signatures et al., but that would also trip up on the authors of freebeer services and freefreedom code authors.

Answer 2

You're making some unwarrented assumptions.

For instance, you assume that your app must be LPGL licensed because one of its libraries is. That's untrue. If your app is GPL licensed, you may use LPGL libraries. This is logical because the GPL license effectively is a superset of the LGPL.

The GPL isn't viral, either. The copyright owner of the GPL library cannot demand that you impose the GPL on a third party plugin. (He could demand that you distribute your own plugins under such terms. The GPL doesn't. Libraries that are packaged as plug-ins but function like mandatory libraries are a grey area.)

So, Q1: No. Q2: Yes, keep those plug-ins optional and the interface well-defined. Q3. You can't, really. Many countries have exceptions in copyright law that restrict the scope of copyright law when it would be used to restrict interoperability. Since the plugin described exists precisely to enable interoperability between your program and his web service, copyright law would be restricted for you. Secondly, and this applies globally, the GPL license forbids you to place restrictions on your program. It therefore cannot reject such a commercial plugin.