Specifically, it seems to me that the rise of the Postnuke API may provide certain benefits or opportunities for using non-GPL code within PostNuke. I am finding that there are quite a few non-GPL scripts out there, and a cleaner licensing landscape may help adoption of PostNuke and at the same time add to the number of 'components' available for it.
First, let me state that I'm no lawyer, am new to open source, and don't do C or C++ level development. The GPL and the FAQs are full of jargon that I may not have a proper understanding of definitions. That said, here are some important FAQ issues:
If I add a module to a GPL-covered module, do I have to use the GPL as the license for my module? In short, Yes, or some other compatible free license.
If a library is released under the GPL (not the LGPL), does that mean that any program which uses it has to be under the GPL? In short, Yes.
If a program released under the GPL uses plug-ins, what are the requirements for the licenses of a plug-in. It depends on how they 'talk' to each other. read this one. It's important.
You have a GPL'ed program that I'd like to link with my code to build a proprietary program. Does the fact that I link with your program mean I have to GPL my program? Yes.
How can I allow linking of proprietary modules with my GPL-covered library under a controlled interface only? Include special verbage in the license.
I find it interesting that there are different consequences for a script depending on whether it is a 'module' or a 'plugin'. I've always used the word interchangeably. Could someone please supply a reasonable definition of each? If the component is defined as a module, then it seems that the GPL requires that it be GPL as well. This could have dire consequences for some of the great non-GPL components already in in use with PostNuke, such as Gallery.
If they are plugins, it's a whole other thing. In fact, this seems to be a recogized grey area in the GPL. The FAQ says:
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.
Now, I haven't a clue what "fork" and "exec" are, but can guess that the intent of the license is if it's called by it's 'own' URL, then it's a 'seperate program'; this would be like the old-style modload URLs. The FAQ continues:
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, so plug-ins must be treated as extensions to the main
program. This means they must be released under the GPL or a
GPL-compatible free software license.
we believe!?!? I guess that means it's their position and intent, but has never been tested in court or otherwise. But according to their intent (at least), if a module uses variables instantiated by PostNuke or access SQL data created by PostNuke, the module would need to be GPL. But it seems a grey area. The FAQ continues:
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.
This sounds suspiciously like the new PostNuke API. The new module format strongly discourages the use of globals, data is accessed through function calls rather than directly querying SQL, and other parts of PostNuke access the component's data by defined API, not by querying it's tables.
Now, here's where the rubber meets the road: Suppose someone wanted to convert a very useful script that has a commerical license, or even write one from scratch. Here are the important questions:
1) Is it a module, or is it a plugin, in terms of the GPL license? If it's a module, then it appears there is no way to do it without compromising one of the licenses. It truely is viral.
2) If it is a plugin, is it possible to maintain each original license? Are there certain things - methods, etc, that one must not do in order to maintain license integrity?
3) If it is possible, how would one go about creating/converting the commercial script? The practical solution would be to start with the template module and modify it, but GPL says:
2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:
b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
Well, the module template it GPL, isn't it? So you can't start with the module template and modify it, because then you've got a work based on the program and therefore a GPL license. So, maybe you don't start with the template. But the API is defined in such as strict way that a properly written component (module, plugin, whatever) won't look any different than a modified Template! How do you convince a commercial publisher that you are not compromising his license by him granting you permission?
In previous versions of PostNuke, the answer to these questions seemed to be that if the component worked standalone, without PostNuke, then it's own license would stand because it wouldn't be a genuine module then. Since the GPL says:
If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.
That's all well and good for old versions, but we've been warned that in the future modules may not work if they don't conform to the API. And modules written with the new API will not really be functional without PostNuke.
4) As for future versions, will be it technically possible to create a conversion module (for each non GPL module) that serves as an interface between PostNuke and the non-GPL module? For example, to load the user interface, PostNuke calls function user_main in the interface module, then user_main calls some function or URL in the standalone script? Presumably that would preserve the non-GPL license of the script; only the PostNuke API "interface" module would have to be GPL.
5) There seems to be various ways around thorny licensing issues by putting exceptions into a GPL license. Under the FAQ
How can I allow linking of proprietary modules with my GPL-covered library under a controlled interface only? :
Linking FOO statically or dynamically with other modules is making a combined work based on FOO. Thus, the terms and conditions of the GNU General Public License cover the whole combination. As a special exception, the copyright holders of FOO give you permission to link FOO with independent modules that communicate with FOO solely through the FOOBAR interface, regardless of the license terms of these independent modules, and to copy and distribute the resulting combined work under terms of your choice, provided that every copy of the combined work is accompanied by a complete copy of the source code of FOO (the version of FOO used to produce the combined work), being distributed under the terms of the GNU General Public License plus this exception. An independent module is a module which is not derived from or based on FOO. Note that people who make modified versions of FOO are not obligated to grant this special exception for their modified versions; it is their choice whether to do so. The GNU General Public License gives permission to release a modified version without this exception; this exception also makes it possible to release a modified version which carries forward this exception.
If I understand this correctly, all of the licensing issues can be dealt with with if this exception is included in the GPL. Yet this clause is not (yet) in the GPL for PostNuke. Can it be?
There's a lot to think about here, and I've tried to digest it since I read it last week, but I still don't know the answers. If someone else has sorted this stuff out, I'd be pleased to hear about it. Plus, I'd be
really interested in knowing if some of the API changes were made with licensing consequences in mind, one way or the other.