Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Staging Plugin
TheEric wrote:
The second part is false.
Generally speaking: No.
The key point from Sam’s argument is “Also, I believe that the mere fact that the plugin is designed to be loaded by Textpattern’s loading mechanism [..] and executed by Textpattern also subjects the plugin to the requirements of the GPL.”
The GPL FAQs are perfectly explicit about this:
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.
Textpattern dynamically links plug-ins by its loading mechanism and shares data structure with any plugin (otherwise it wouldn’t even be visible in the admin-side’s plugin tab).
Anyway, this thread is quickly getting off track.
This discussion relates to pieman’s concerns. Not so off-track at all, I think.
Offline
Re: Staging Plugin
wet wrote:
Generally speaking: No.
The key point from Sam’s argument is “Also, I believe that the mere fact that the plugin is designed to be loaded by Textpattern’s loading mechanism [..] and executed by Textpattern also subjects the plugin to the requirements of the GPL.”
The GPL FAQs are perfectly explicit about this:
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.
Translated, because some people have difficulty with the above concept : GPL If they share code, memory space. Remember the whole SCO fiasco? Don’t be Darl.
Let’s say that Adobe created an application that did whimsical wiz-bang stuff and allowed one to play games online. Of course, at the invocation it had a variable passed to it (user) and returned a final score. One could write a plugin that started this application and passed the txp_user variable to it, and upon it’s closure, returned a value to the plugin to post on the scoreboard. (Wow — This anology reminds me of old BBS door-games. What fun that was back when.) That plugin would be GPL, yes. No matter what. Always, GPL. It shares code and memory space. However, the Adobe Game wiz-bang stuff would not be bound by Textpattern’s license. It is its own entity, even if the application was stored in a database cell as a binary blob.
And again, the Linux filesystem Anology. Files designed to run on Linux aren’t bound by Linux’s license. You seemed to gloss over this one in your reply.
Offline
Re: Staging Plugin
The key part of my argument is the executed by Textpattern part.
In your example, the Adobe application is not a plugin. It is an application. All Textpattern plugins are GPL by definition. If Textpattern can load it and display it in the Admin, it is a plugin and is covered by GPL. You may create a separate application that does something Textpattern-related, and design it in such a way that it does not interact directly with Textpattern and therefore is not subject to the GPL. But then, that would not be a plugin either.
Offline
Re: Staging Plugin
TheEric wrote:
And again, the Linux filesystem Anology. Files designed to run on Linux aren’t bound by Linux’s license. You seemed to gloss over this one in your reply.
May I ask you to rather assume that I deliberately chose not to respond to this analogy because in general it really doesn’t apply to the Textpattern core plus plugin situation?
Offline
Re: Staging Plugin
Umm, I think (correct me if I’m wrong) that pieman was referring to the situation where one has, for example, EBL_Upload on the staging server and wants to deploy it to a live server without having the #2038 error appear because the plugin is not licensed for the target domain. Might have got the wrong end of the stick, but that’s something that happened to us when we pushed our stage server to live the other day (minor oversight on our part *cough*)
Last edited by Bloke (2009-09-14 08:24:55)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Re: Staging Plugin
@Eric, any thoughts on the other questions? Namely: could you specify which tables are (and aren’t) copied across; and if you’re updating content tables like images/files, would you also need to manually update the file system?
@Stef, that is indeed what I was thinking about when I mentioned the licenses thing. Although afterwards I realised that depending on Eric’s answers to the other questions it might not be relevant in this case. If with this new plugin you could select which tables to update, it might be wise to keep non-Publishers out of the Live CMS to avoid them updating the wrong site (in which case you wouldn’t need ebl_upload to work on the Live site).
Offline
Re: Staging Plugin
Calling a generic 3rd party library from GPL code does not make that library GPL. EBL_Upload consists of a generic image processing and uploader written in flash and a standard txp plugin that uses this library. I believe that he also uses the swf for EE.
What I think is confusing is that for the sake of convenience, Eric chose to package the swf as a plugin to prevent everyone from having to manually upload the file. Under this circumstance, the swf is little more than data being served by txp. To prevent future confusion, he should probably remove that convenience and revert to distributing the swf as a separate file.
If you don’t believe me, then you should read the FAQs.
- Can I write free software that uses non-free libraries?
- What legal issues come up if I use GPL-incompatible libraries with GPL software?
Edit: I realize this topic is not about ebl_upload, but that is a very good example of how a plugin can contain non-gpl code.
Last edited by Manfre (2009-09-14 12:48:51)
Offline
Re: Staging Plugin
Manfre wrote:
Calling a generic 3rd party library from GPL code does not make that library GPL.
Nobody has claimed the contrary.
EBL_Upload consists of a generic image processing and uploader written in flash and a standard txp plugin that uses this library. I believe that he also uses the swf for EE.
In this case, the txp plugin is a “bridge” to the third party library. The bridge plugin is GPL in this case.
Offline
Re: Staging Plugin
Emphasis is mine:
If the program dynamically links plug-ins, and they make function calls
to each otherand 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.
And there’s more where that came from:
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.
While I agree that most plugins are required (if you want to distribute them) to have a GPL compatible licence, I don’t think that’s true for all TXP plugins.
Offline
Re: Staging Plugin
I have built something similar back in 2008, used it on a single project, realized that it was too niche. You can grab a copy here, fork it, continue development etc. The difference between Eric’s plugin and mine is that mine only pushes articles and it can handle multiple locations. There are a few ideas in the README and what was planned for it.
Offline