Plugins used in both Foswiki and TWiki
I believe there is no barrier to a plugin being considered part of whatever program it is plugged into in a given installation, be it Foswiki or TWiki, for licensing purposes. The plugin must meet the licensing requirements of all programs it is extending.
--
IsaacLin - 14 Nov 2008 - 00:02
After following this discussion for many years in the Linux arena, I'm pretty certain that the 'viral' nature of the GPL license only applies to such modules that are written specifically for that one program. Given that post re-branding, a plugin could be written to extend just Foswiki, just TWiki (and thus work on Foswiki via our compatibility layer), or both (via explicit coding), this viral situation becomes a little less definite. (its like writing a kernel module that works on both BSD and Linux).
Its not a big deal however, as most contributions are made using the same license as TWiki - ie
GPLv2 or later.
I see the anti-tivoisation and anti-patent clauses in GPL3 compelling enough, as I want the users of my code to always be able to rescue their systems from closed boxes and Virtualmachines.
--
SvenDowideit - 14 Nov 2008 - 00:20
The question is not so much if the extension is for one program, but if the extension is interacting with the host program only through a clearly defined interface and the extension's capabilities, logic, and data are clearly separable. (Linux kernel modules have been given an explicit pass by Linus Torvalds, so GPL does not apply to them.) The GPL FAQ says the following:
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, which must be treated as an extension of both the main program and the plug-ins. This means the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed.
It seems to me that the TWiki API being inherited by Foswiki is not so clear cut (e.g. data structures from the core software are accessed by the plugins), and through the natural course of invoking registered callbacks, the flow of control can go back and forth between the core and a plugin.
--
IsaacLin - 14 Nov 2008 - 00:36
I think you're pushing the extreme onto the majority - TWiki API being inherited by Foswiki is quite clear cut for most plugins - while there is always the possibility of breaking encapsulation, most plugins don't.
Can does not extend to
must or
do.
--
SvenDowideit - 14 Nov 2008 - 01:11
Fair enough that many/most plugins probably can be separated from Foswiki by those who understand the code. I do know that in the corporate world, companies are quite reluctant to treat plugins as anything other than derivative works. Without at least a clear memory barrier in place, it is far from clear that a court would agree that a plugin is not a derivative work. Now, the Foswiki project could make a statement saying that they do not consider plugins using the specified extension API to be a derivative work. I assumed though that the team was content with requiring plugins to follow the same license terms as Foswiki.
--
IsaacLin - 14 Nov 2008 - 01:19
This is a moot point. As you already pointed out, the GPL license states that
This means the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed.
If we change the license for the project to GPLv3 (which we can do), plugins that are supposed to work on both platform must be release under GPLv3, which is GPL-compatible by design. No loopholes, no poison pills, no nothing.
I'm with Sven, we should change to GPLv3 if just to prevent tivoisation.
--
RafaelAlvarez - 14 Nov 2008 - 02:14
Sven seems to be suggesting that Foswiki plugins are not necessarily derivative works and so those that are not would not have to be licensed with terms compatible with Foswiki's licence. Not sure what "poison pills" you are thinking of.
--
IsaacLin - 14 Nov 2008 - 03:21
Ah.. I misunderstood the point then. Yes, plugins are considered derivative work, they are the same case as if you wanted to reuse just one perl module from TWiki into your application: Your application license must be GPLv2 compatible.
In our case, we're moving in a grey area. Suppose we relicense using GPLv3:
- If a plugin is made for Foswiki it must be released using a GPLv3-compatible license. This means that it can also be distributed alongside TWiki.
- If a plugin is made for TWiki (and thus can run in Foswiki via a compatibility layer), and it is licensed using GPLv2, it cannot be distributed with Foswiki. But, AFAIK, anyone can mix GPLv2 and GPLv3 plugins in an installation, as long as it is not redistributed.
IANAL, so take this with a grain of salt.
--
RafaelAlvarez - 14 Nov 2008 - 05:30
GNU Affero GPL - Web Applications User Freedom
May we should use
GNU Affero GPL as
Noosfero does.
The GNU Affero GPL is the GPL v3 with user freedom protection for the web.
Today is possible to use a GPL software for a web public application, add some private features, and do not distribute the added code.
I think, who uses FOSWiki may not make the user a hostage, and who uses a great community work, must pay back with your appended work.
--
AurelioAHeckert - 22 Nov 2008 - 17:35
I believe this may be unduly restrictive for users. For example, a company may wish to deploy a Wiki for its customers, but have privileged access for its employees, and so have to implement its own login manager and user mapping manager to integrate with its internal authentication system. As it would be difficult at the moment to implement a clean room implementation of these managers, and also following
RafaelAlvarez's assertion above, the managers would be derivative works of Foswiki. Another example is skinning: companies commonly wish to maintain a specific look-and-feel across their web site and would accordingly skin their Wiki installation to match. As one of the selling points of Foswiki is its adaptability for custom uses, I believe the project should do its best to avoid hindering deployment of installation-specific customizations. --
IsaacLin - 22 Nov 2008 - 18:07
I'm going to remove the suggestion of Affero GPL in a day or so - simple reality, you cannot convert from GPL2 or later to Affero - its not compatible (as far as i understand the atrix on the GPL FAQ.
--
SvenDowideit - 22 Nov 2008 - 22:22