Staging Plugin

TheEric · 2009-09-14 04:04:38

artagesw wrote:

All plugins are licensed as GPL.

Not under all circumstances. E.g, if there is no shared code/hook, then it doesn’t have to follow the same licenses as Textpattern.

artagesw · 2009-09-14 04:41:10

TheEric wrote:

Not under all circumstances. E.g, if there is no shared code/hook, then it doesn’t have to follow the same licenses as Textpattern.

All the plugin needs to do is call one Textpattern API to fall under the GPL terms. I would be hard-pressed to imagine a useful plugin that never calls into Textpattern. Also, I believe that the mere fact that the plugin is designed to be loaded by Textpattern’s loading mechanism, stored into Textpattern’s database and executed by Textpattern also subjects the plugin to the requirements of the GPL.

TheEric · 2009-09-14 06:16:20

Yes, if it uses any of the Textpattern code to run, then it falls under the TXP licensing. When it doesn’t, it does not. Theoretically, one can create a plugin that merely invokes a script that doesn’t make use of any Textpattern code, and that included file would not be bound by the GPL. (e.g, Files served by Apache aren’t bound by Apache’s license.) Just running the file off one system doesn’t make it bound by the GPL. It’s bound by the GPL ONLY if they share code.

The second part is false and related to the above as well. Take for instance the linux file-system, or a mysql database. Storing a file on the file system doesn’t not make that file bound by the same gpl licensing as linux, nor does storing a binary file within a table in MySQL bind it by it’s license.

Anyway, this thread is quickly getting off track. Might I suggest we start another for any additional questions?

wet · 2009-09-14 06:28:33

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.

TheEric · 2009-09-14 06:48:37

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.

artagesw · 2009-09-14 06:55:03

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.

wet · 2009-09-14 07:00:19

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?

Bloke · 2009-09-14 08:21:56

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)

pieman · 2009-09-14 08:49:36

@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).

Manfre · 2009-09-14 12:30:38

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.

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)

artagesw · 2009-09-14 17:59:23

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.

ruud · 2009-09-14 18:44:21

If a program released under the GPL uses plug-ins, what are the requirements for the licenses of a plug-in?

Emphasis is mine:

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.

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.

Textpattern CMS

Textpattern CMS support forum

#13 2009-09-14 04:04:38

Re: Staging Plugin

#14 2009-09-14 04:41:10

Re: Staging Plugin

#15 2009-09-14 06:16:20

Re: Staging Plugin

#16 2009-09-14 06:28:33

Re: Staging Plugin

#17 2009-09-14 06:48:37

Re: Staging Plugin

#18 2009-09-14 06:55:03

Re: Staging Plugin

#19 2009-09-14 07:00:19

Re: Staging Plugin

#20 2009-09-14 08:21:56

Re: Staging Plugin

#21 2009-09-14 08:49:36

Re: Staging Plugin

#22 2009-09-14 12:30:38

Re: Staging Plugin

#23 2009-09-14 17:59:23

Re: Staging Plugin

#24 2009-09-14 18:44:21

Re: Staging Plugin

Board footer