Slashdot Mirror
License for Open-Source Software w/ Plugins?
ThiagoHP asks: "I have developed MultiMAD, a rapid application development and prototyping for for mobile devices in my master's course, and now I want to share it with the community. It's written in Java and it has a plugin architecture in order to support different mobile device platforms (WAP, J2ME, PalmOS, etc). I want to give the freedom to anybody write their plugins, even closed-source, as long as the tool itself is not modified for them to run. This implies that GPL cannot be used. At the same time, I do not want any closed-source tool based in MultiMAD code, so licenses such as the Apache one cannot be used. Am I right in my assumptions regarding licenses? What license do you suggest?"
Even better is to split the program into two parts. LGPL the core, and GPL the interface.
badness 10000
The poster wants to deny users the freedom to modify the MultiMAD program ("[...] as long as the tool itself is not modified for them to run"). Thus, MultiMAD is to be licensed under a non-free license.
The GNU GPL is a free software license; it allows users to modify the licensed program and to distribute those modified versions.
The GPL is not anti-commercial software development, it's pro-free software development and distribution. The moment a GPL'd program is used in a business context (such as distributing copies of GPL'd programs for a fee), that program becomes "commercial". Commercial and non-free are not the same thing. Not being able to change MultiMAD means denying users a freedom they ought to have. The GPL denies users the ability to distribute non-free derivatives. These are not the same issues and there's a good reason why the GPL does this--in order to preserve software freedom for derivatives, there had to be a choice between what was valued more and the FSF values giving more users software freedom.
Digital Citizen
license your code under the GPL, and grant an additional exception that plugins can be proprietary. It would work, too... supposing the GPL really forbids dynlinking to proprietary modules, which is disputed.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
Uhm, the GPL doesn't control your app, YOU do. Here's what you can do.
#1) place the GPL in a file called "GPL".
#2) Place the following text in a file called "COPYING":
This program is copyright XYZ and can be distributed under the terms of the GPL (see the file "GPL") plus the following exception: any plugins written for this application are expressly exempt from any obligations required by the GPL. You must include this entire paragraph in any copies you make of this application.
Jeezuz people, it's YOUR application, you can license it any way you want! You can make it GPL on Tuesdays and MIT on Saturdays. This isn't rocket science, RMS doesn't control your app, you don't assign copyright to the FSF, a little bearded man doesn't pop out of your screen if you choose not to sue people who make closed-source plugins. The GPL doesn't enforce your copyright, YOU DO!
If you specifically say that use of the plug-in API does not make the plug-in a derived work, then you should be alright. A similar case is, interestingly enough, the linux kernel. While modifying the kernel is derived work, making syscalls from userspace does not make the user program a derived work. Besides the kernel/user space barrier, there's also a subset of kernel functions that are effectively GPL barriers (so some modules don't need to be GPL)
The Raven
I work on a Network Management application where the core is open source and the plugins can be any variation of license. We went through this same process and found GPL and LGPL to be more viral than beneficial for this same reason. We don't care, as you don't, that propriatary plugins (heck even extensions) are created and/or sold with our product, and they can have any license they want. However, we retain rights to our code, and any direct source code modifications to our files must be under our license.
Here's the problem with LGPL: (from opensource.org) " However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License."
If any plugin 'links' to your library, it's derivitive. That's crap in my opinion, and since you are using Java, some could argue that 'run-time linking' is still linking since it's running in the same JVM.
Use the BSD or CPL - you'll be much better off.