Wrapper around pandoc should also be GPL about panflute HOT 23 CLOSED

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

from panflute.

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?

from panflute.

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

from panflute.

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

from panflute.

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)

from panflute.

from panflute.

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

from panflute.

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.

from panflute.

from panflute.

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

from panflute.

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?

from panflute.

from panflute.

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

from panflute.

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

from panflute.

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.

from panflute.

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.

from panflute.

from panflute.

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?

from panflute.

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

from panflute.

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

from panflute.

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

from panflute.

from panflute.

No problem.

Best,
S

from panflute.