Wrapper around pandoc should also be GPL

[kiwi0fruit]

There are no exceptions about that in Pandoc license and the way of linking doesn't matter (though the way of linking would have mattered if Pandoc was LGPL).

And Panflute uses some helper functions that are wrappers around Pandoc and that not really needed by most of the filters. So I suggest removing them and keeping the current license.

[kiwi0fruit]

As for myself. I did this fast hack: https://github.com/kiwi0fruit/knitty/blob/master/LICENSE

[kdheepak]

AFAIK Panflute is not distributing any part of Pandoc's source code nor is it distributing Pandoc compiled binaries or shared libraries. IANAL but my understanding is that this means the Panflute source code can have any license.

Can you clarify why you think this should also be GPL?

[kiwi0fruit]

It's actually a "gray area"... So one cannot be certain (unless he knows about precedents and actually a lawyer).

From this conversation:

So if the app your user is writing relies on PyQt, then it's potentially GPL "infected"
...
Stallman's own words (original was on CLISP but seems to have been archived, copy here say that an app is GPL if it uses GPL'd functionality, even if that functionality is optional.

And there a good SE question that redirect to the rather ambiguous FAQ:

Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide.
...
By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally (eh?) are separate programs.

And a reasonable comment:

Whether the underlying command-line program remains able to function in the absence of the GUI overlay might be relevant if the license status of the command line program were in question - but the question is about the GUI, which is completely useless without the command line program, and therefore it's true beyond a shadow of a doubt that they form a single program

[sergiocorreia]

Besides the discussion about the differences between importing a library in Python vs linking a library as in C (in which case there is no gray area), does the fact that panflute uses the MIT license prevent any issue? (It's GPL compatible)

https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses

[sergiocorreia]

Something else to note is that the wrapper is not even a Python wrapper.. it's equivalent to calling pandoc on shell and then piping results from stdout (in fact, that's literally what it does)

[kiwi0fruit]

The question is if that quotes about CLI and pipes do really matter or they are just irresponsible talk. If I understood correctly the GPL itself doesn't mention particular mechanisms of communication. If you ask me about using pipes inside another program and how it related to GPL spirit as I know it - then that I thinks it's a derivative work and should be GPL. May be I'm wrong and there were precedents that show that such way of communication should not lead to GPL. I'm not experianced in this area unfortunately (or fortunately :) May be I'm wrong even more and there are actually something about it in GPL text. But it wasn't quoted in that SE question.

[kiwi0fruit]

MIT is compatible with GPL in sence that derivative work of both MIT program and GPL program can be released under GPL license.

[kdheepak]

Thanks for all the references @kiwi0fruit. I'm curious about this since I have a couple of other projects that I anticipate I'll need to figure out the details for. I think here, as @sergiocorreia has said, since Panflute is just making a subprocess call and since Panflute is already using a GPL compatible license (compatibility is for the other way around apparently), it should be fine without any changes required. If needed we could ask John MacFarlane to weigh in as well.

[kiwi0fruit]

From practical point of view tha doesn't relly matter as nobody would sue you :-) But theoretically the people that use panflute and think that it's MIT and release some commercial product **may** have problems.

[kdheepak]

Even pandocfilters is BSD-3 [1]. Maybe the README in this repo can be updated to provide more details about the licenses of all dependencies (Pandoc, Python, etc).

[1] https://github.com/jgm/pandocfilters/blob/61edb2b002e322cca93985d41d47eb38314679fa/LICENSE

[kdheepak]

This is off topic slightly but even if someone used Panflute (and in turn used Pandoc) in a commercial application, wouldn't it be fine as long as they weren't making modifications to the source code of Pandoc?

[kiwi0fruit]

Why should not it be BSD? It only operates over some special JSON format. It doesn't use Pandoc (or may be re-uses some code - I don't know - but even in this case jgm can republish it with any license he wants).

[kdheepak]

Isn't Panflute doing the same thing as pandocfilters, operating over the JSON format using stdin and stdout?

To clarify, I brought up pandocfilters because since Panflute is operating in almost the same way as pandocfitlers, it can have the same type of license as pandocfilters (unless my understanding is incorrect. It has been a while since I looked through the source of Panflute).

[kiwi0fruit]

Yep. That part is fine. The problem may be about this function only.

[kdheepak]

I see what you mean. The function you linked uses Python's subprocess.Popen underneath. This is what the GPL license has to say about that: https://www.gnu.org/licenses/gpl-faq.html#GPLPlugins

When is a program and its plug-ins considered a single combined program?

It depends on how the main program invokes its plug-ins. If the main program uses fork and exec to invoke plug-ins, and they establish intimate communication by sharing complex data structures, or shipping complex data structures back and forth, that can make them one single combined program. A main program that uses simple fork and exec to invoke plug-ins and does not establish intimate communication between them results in the plug-ins being a separate program.

It's hard to say exactly what they mean by the language used there. For example, what exactly does "intimate communication" mean in the context of a "fork and exec"?

I've also done a cursory scan of other instances of similar use, and almost every other package I've scanned on GitHub that uses Pandoc through fork and exec seems to be using a permissive license.

[ekiim]

Couldn't this be solved with word play by stating that panflute requests a binary installed with certain established CLI Interface and output methods, not pandoc?
or requesting John MacFarlane for "permission"?

Stating pandoc as an optional dependency wouldn't fix the problem?, we are working with the AST json, that could be generated by actually anything?

And also It appears to be a de facto acceptance towards panflute by pandoc, and having pandoc wrappers to assist the functionality and not to rely on seems pretty natural, so I think this could actually get out of any apparent gray area by requesting an actual approval if necessary, that to be honest I don't think pandoc won't provide.

Hope, I help to this discussion.

[kiwi0fruit]

The quote about plug-ins mean plugins. In case of panflute it's not a plug-in. It's a built-in functionality.

[tarleb]

The underlying pandoc data structures are BSD licensed (jgm/pandoc-types); GPL seems to be overkill here. But it's an interesting question, maybe raise it on Open Source SE?

[kiwi0fruit]

But this calling Pandoc from Panflute is a powerful and convenient tool. So I guess removing it is not an option.

[sergiocorreia]

At the end of the day, the only thing that Panflute is doing is calling Pandoc through shell and processing its output. That's not different from calling ls from shell, and it's not a level of integration that the GPL refers to. Otherwise, every program out there that does shell calls would have to be GPL compatible.

If Panflute had C-level Pandoc bindings, then it might be a different situation, but even with normal Python imports, people are free to import code with a different licensing than the one you have (otherwise all hell would break loose).

[sergiocorreia]

Also, as others have pointed, Panflute has a BSD-3 license, which is GPL-compatible (so even if we were using C bindings it would be fine).

[kiwi0fruit]

Sounds convincing. I hope you are right (but I'm still doubtful). But I guess it's OK for until that would matter.

[sergiocorreia]

No problem.

Best,
S